Your Reliability Engineering Professional Development Site
Previous articles have covered a proposed waterfall product development phase/gate process. This article will compare and contrast waterfall with Agile product development, especially with respect to the front-end of the process.
Let’s start with a proposed waterfall product development phase/gate process. (The process below implies a hardware product, however, it can be considered any waterfall process for now.)
Tasks (or action items) are a fundamental building block of an ongoing work-effort or project schedule. While we tend to think of completed actions as deliverables, a project schedule can also be considered a project deliverable….and the value of well-written task (within the schedule or otherwise) is often overlooked.
Generally, a task begins with a verb (some action to be performed) to achieve a milestone or outcome to some desired level of completion. (Recall a previous related article where we discussed the “definition of done”.)
All projects or programs have a formal or informal resource management process, with the goal of completing projects on time, within budget and with good project quality.
In order to meet this goal, the resource management objectives are:
In a previous article we compared and contrasted the role & responsibility for a scrum master vs. project manager/core team leader (CTL/PM).
In this article, we’ll take a closer look at the scrum product owner role and compare it with the product development team’s “opportunity champion”.
In a previous article, we explored agile product development with a focus on early product validation.
In this article, we’ll compare and contrast the role & responsibility for scrum masters vs. project managers/core team leaders.
Let’s start with (all) the basic scrum roles:
Many companies pursue a product development strategy that provides a product (or service) which meets customer needs sooner (rather than later), and then makes adjustments after the product has been fielded.
Pursuing this approach means accepting the associated risks. What if a critical to quality or critical to reliability characteristic fails to meet customer needs? A product could fail miserably by eliminating important product development work scope and accelerating time-to-market. By the time an adjustment or “pivot” can be made it may be too late, or too costly to correct.
In my previous article, we reviewed the project approval committee, and emphasized approval to start projects and/or approve projects in-process.
With any type of project oversight, presentations or project schedules are often reviewed.
“Definition of done” is the agreed-upon evidence of completion of a process, activity or milestone and usually includes a project deliverable. Some examples of deliverables might include the project plan, project schedule, documents (requirements document, plans, and reports), analysis, and designs (drawings). Other considerations can be built-into “definition of done” including compliance, acceptance/sign-off, exceptions and best practices.
Committees may be known as a project review or steering committee; however, consider the following (proposed) objectives as follows:
In my last article, we reviewed a proposed Product Life Cycle process, which starts with a “Define” phase. In the “Define” phase, we are defining the project as well as the product.
We previously discussed the ‘technical leg’ of this process with the market analysis, identifying customer needs, product requirements, verification and validation, etc. [Read more…]
In my previous article we covered the advantages of a phase and gate structure for new product development. Now we can discuss some proposed phase names for a new product development or product life cycle (PLC) process.
An organization may have an existing PLC process ‘baked-in’ to their culture and process documentation. Accordingly, there’s a wide range of PLC phase names, all of which are likely acceptable and based on solid reasoning.
In previous articles we defined an element of lean as a phase and gate structure for new product development. This assumes a waterfall approach to the project (versus agile product development).
A new product life cycle phase gate structure might entail, for example: “Definition, Concept, Design, Verification, Qualification, Production and End-of-Life”. (Your organization might decide on different phase names.)
There’s an apparent contradiction in using a waterfall project approach and calling it lean project management, however. A goal of any lean process is to work toward ‘single piece’ or continuous flow: agile product development is more like ‘single piece flow’ of information, versus waterfall which is more like ‘batch processing’ of information.
My last article covered a scalable model for lean product development depending on the number of projects and technical objectives.
Let’s start with the foundational elements from this model:
In my previous article we established the lean product development goal statement as:
We then derived high-level objectives as follows:
In recent articles I framed the structure of a market analysis to ensure we understand customer needs and value, product requirements are “the what” the design provides (to ensure customer needs are met); the design is “the how” the product requirements will be met.
Product requirements are determined by answering the following question: “What shall the (product) design provide (output) @ input conditions? (Input conditions are functional inputs provided by the user, or environmental conditions.)
A complex product may have several outputs that interface with a system, however, and/or several inputs may be needed in order to enable the product to perform it’s intended function. System integration is therefore required.
Let’s assume your product is a subsystem. The questions become:
How do we establish optimum system performance? We would expect the customer (system designer) would model system performance and provide functional inputs, outputs and specification limits (for your subsystem) in order to achieve optimum system performance.
Accordingly, subsystem integrators should understand system performance well-enough to help system designers with overall system design optimization…at the very least, understand gaps in requirements and associated system/subsystem development risks. The subsystem requirements document therefore is a key deliverable, reviewed in detail and approved by the customer.
An integrated approach to ensuring customer needs and value should be embedded in the product life cycle process, and can save your company (and your customers) millions of dollars in product development costs.
Wouldn’t it be great if we could require the stock market to provide us 15% increases in our portfolio every year…or if we could simply require a sunny day for a picnic?
You might be familiar with the term ‘market requirements’ or a ‘market requirements document’ as a deliverable in the definition phase of a product life cycle process. To understand why market requirements don’t really exist, we must first provide the definition of a requirement. [Read more…]