Your Reliability Engineering Professional Development Site
Think of the “wasted energy” involved with products that require rework, redesigns, or fail to meet customer needs. In addition, a great deal of time and effort is often put into products after they have been developed to make them more profitable.
The goal of this article series is to help organizations proactively focus on maximizing customer value of products, and minimizing cost of operations during the product development process. Readers will also improve their understanding of problem solving and process improvement tools and methodologies. Some articles will provide high-level perspective while others will deep-dive into specifics.
While product development is not always perfect, companies can emphasize teamwork, establish a framework for innovation & problem solving, and eliminate waste. Meanwhile, employees can develop transferable, marketable skillsets with their knowledge of problem solving tools and methodologies. This article series will also help contribute to these objectives.
Sign up for the “Product Development and Process Improvement” email list to receive weekly articles.
[display_form id=38]
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 my previous article, we established some high-level objectives for lean product development as follows:
In my last article the high level goal of lean product development was established as follows:
Develop products that maximize customer value and minimize product cost, in the least amount of time, and at the least amount of product development cost.
Let’s analyze this goal statement and establish some high-level objectives. [Read more…]
Lean product development might mean different things to different organizations, but let’s start with the 5 principles of lean manufacturing and see how it can be applied to the product development process. [Read more…]
One of several reasons for emphasizing product requirements includes enabling modeling and simulations of designs, as well as ensuring adequate verification and validation testing.
Recall the fundamental framing of a requirement as:
Note the framing (within the requirement) of a mathematical and/or experimental relationship where “Y” is the output as a function of “(x)” as the input….Y = f(x) or as a function of multiple inputs Y = f (x1, x2, x3…xn). Let’s expand on this for a moment:
While previous articles focused on requirements writing, another element of products requirements is design constraints.
A design constraint might not be a requirement in the purest sense, but must be accommodated in product requirements (and, ideally, identified as such). Design constraints almost always make their way into product requirements.
Let’s use a simple example whereby a specific housing material is specified (a polyester thermoplastic elastomer).
The requirement might simply be: “The housing material shall be made of a polyester thermoplastic elastomer”. The PRD is then provided to the designer, essentially telling him he must use this material.
Managing requirements for complex systems can be challenging, however, establishing a hierarchical framework of key questions (answered at each layer of the hierarchy) can be quite helpful.
While some regulatory authorities (such as the FAA) may require various layers of documentation and traceability, this article isn’t necessarily advocating a bureaucratic development process. The process can be scaled based on the complexity of your system, your ability to model it’s (system) design performance and/or based on the amount of product development risk the organization is willing to assume. [Read more…]