Success Assured®
Is most of your Product & Process Development capacity consumed (wasted) by rework?
Are you having difficulty getting your next-generation project underway because key people keep getting pulled back on to the prior project(s) to fix yet-another problem?
ABOUT THE SITUATION
Highly Optimized Processes do not mean Optimized Results!
Although every organization's Product & Process Development and Project Planning processes are different, a well-defined and well-documented phase-gate pattern like this is common (though typically with more phases & gates):
So, although we only invest 8% in the early conceptual development phases, 75% of the lifecycle costs are actually fully committed by the decisions made in those phases. 85% before you start the detailed development work.
In other words, if you want to reduce rework and optimize overall lifecycle costs, you need to change how you make decisions very early in the project.
Many companies have measured that 65-75% of their engineering capacity is consumed by rework (revising things that they thought were final). Just eliminate that alone and you have a 3X-4X productivity boost! And since that occurs late in projects, it is generally also a major project delay. So, eliminating that alone often cuts the real-world time-to-market in half!
Over the years, companies have optimized those processes and staffed them with brilliant engineers covering all the required disciplines. Despite that, consistently projects:
-
take longer than expected
-
cost more than expected
-
deliver less than expected
-
fail to meet customer requirements
-
lack the innovation expected
-
or the innovations cause other issues
-
Late process rework has been shown to cost 100X to 1000X more than what it would have cost to do it right the first time.
-
Late process rework forces compromises, undesirable trade-offs in the final result.
-
Fear of the unknown and rampant risk mitigation tend to drive out most of the innovative alternatives.
This chart is adapted from INCOSE's Systems Engineering Handbook. In the middle, it shows how the Cost to Extract Defects rises exponentially as you get later in the development process (due to the ever-increasing ripple effects of rework). The bars show how much of the lifecycle costs are spent by the end of each phase. The gray shaded area is the most interesting: it shows how much of those lifecycle costs are actually committed by decisions made in that phase.
A Related Story...
Teledyne Benthos makes TapTone brand leak detectors that you can put on your manufacturing line to detect and reject bottles with leaks.
Seeing growing demand from the aseptic diary market, Teledyne Benthos' marketing department proposed development of a new bottle leak detector that would lie between their two existing products. It needed to be able to detect smaller holes like their bigger more expensive product, ...
... but it needed to be smaller and run on faster lines like their smaller leak detector.
Making that more challenging, they needed it ready by the next trade show or they would effectively lose a year's worth of sales, and perhaps have the market captured by competitors. That trade show was just 11 months away. Theoretically, they could complete a product development cycle in 11 months, but they never planned less than 18 months, because it typically took 21-24 months before they had all the "kinks" worked out and customers satisfied such that they could move engineers off that project and onto the next.
ABOUT THE CHALLENGES
Fixing this has proven to be extremely difficult!
Note that the results reported above are consistently seen today, following decades of trying to improve those processes by introducing intermediate review points, adding Design for Six Sigma, introducing Lean, PDCA, and Value Stream Mapping, adding formal DFMEA and PFMEA steps, adopting various Quality initiatives and standards, adding in TRIZ and Design Thinking, and most recently Agile/Scrum.
Commercial results tend not to be published; but the US Government Accountability Office (GAO) reports defense industry results to Congress, and much of our phase gate processes grew out of the defense industry. In 2009, the GAO reported that the 96 major DOD programs were over budget by $296B (over $3B per program) and over schedule by an average of 22 months. They called for programs to use "a knowledge-based approach to product development that demonstrates high levels of knowledge before significant commitments are made." [GAO2009]
Despite concerted efforts to contain such cost and schedule growth since then, in 2016 (seven years later) the GAO reported the 79 major programs were over budget by $469B (over $5.9B per program) and an average of 29.5 months over schedule.[GAO2016] And they repeated their calls for knowledge-based approaches asserting "knowledge supplants risk over time."
And that trend has continued, as shown below. Although your industry's numbers may be a lot smaller, your trends are likely very similar.
Placeholder for:
-
point 1.
-
point 2.
And a final statement.
The GAO's conclusion: "Despite decades of reform efforts, these outcomes and their underlying causes have proven resistant to change and, in fact, both DOD weapon system acquisition and DOD contract management have been on our high-risk list for nearly 20 years." [GAO2010]
We suggest that identifying the need for better knowledge prior to making commitments in order to supplant risk is not enough; after all, most (if not all) the people on those 79 programs would prefer to make knowledge-based decisions to supplant risk. The problem is that the knowledge is not available when they are required to make the decisions in the front end phases of those programs.
What is needed is a fundamentally different way to operate in the fuzzy front ends of product development, and that requires more than just the desire to change...
Ron fully embraced his mentoring role, insisting that problems didn't exist if they weren't made visual on a Problem K-Brief. He actively reviewed each Problem K-Brief as it evolved, providing guidance on priorities and how to get the needed resources.
So, they began as they were taught, identifying their key knowledge gaps – and in a world plagued by "fear of the unknown", they had a lot. The began visiting customers, looking at their products and processes, asking questions, and modeling what they learned in customer interest K-Briefs.
Concurrently with that, they began mapping out their design space, identifying the key trade-off decisions they needed to make, and the testing they would need to do to close the knowledge gaps.
Ron observed, "We learned more about that machine in a few months than we'd learned in the last 4-5 years."
After 7 months of rapid learning, they had closed all the identified knowledge gaps. So, was it finally time to start detailed design? Was the remaining 4 months going to be enough time to make the critical trade show?
ABOUT OUR SOLUTION
Eliminate Rework by Establishing that "Success is Assured" Before Making Key Decisions
Set-Based is widely accepted as an enabler for delaying decisions until you can establish the knowledge to make those decisions. However, Set-Based is also a critical enabler for accelerating learning such that the knowledge is available prior to when the decisions need to be made. (And the latter is the preferable approach.)
In fact, people often assert that with Set-Based you pay more up front, but it pays off in the end. On the contrary, we argue that if you are doing Set-Based properly, it is a powerful enabler for minimizing workload while increasing concurrency, and thus accelerating learning:
-
Set-Based allows you to simplify the analyses to the worst-case, just proving that the worst case is adequate to establish that "Success is Assured".
-
Set-Based allows you to compute using the fuzzy ranges of values you might be limited to early in the process.
-
Set-Based makes visible the sensitivities and limits of the design space in a way that is easily shared across areas of expertise.
-
Set-Based enables different teams to work concurrently even when they are dependent on the other team's decisions; as they converge, they notify the other team who then can use a smaller range of values.
-
Set-Based allows you to determine and leverage the sensitivities even before you are able to work out the precise levels.
-
The earlier visibility to sensitivities allows the team to focus on the most critical decisions, and thus focus their learning where it is most needed early.
-
That early visibility also enables "eliminating the weak", which is a much more efficient decision-making and optimization process than the typical attempts to "pick the best", particularly in the face of uncertainty.
While the move from Point-Based to Set-Based is by itself incredibly valuable, it is enhanced and itself enabled by several other enablers that our software and methodologies support. One of those is the Decision-Focused Learning process that starts with the Causal Map. The Causal Map starts with the Targets and maps through the various Ideas to the fundamental Capability Limits known by the experts in the different disciplines. That then exposes the Trade-Offs that need to be understood in making the various design decisions identified in the Causal Map. The Causal Map then serves as a map of the knowledge needed prior to making those decisions, and thus guides the following learning process to most efficiently close the knowledge gaps adequately to establish that "Success is Assured" for some portion of the design space.
Just doing the above in your conceptual development phases will dramatically reduce rework. But to eliminate rework, you can leverage the output of the above process: a set-based specification that will provide ongoing guidance as the subsystem teams make more detailed design decisions, keeping the teams within the "Success is Assured" portion of the design space defined by the conceptual design phases. In doing so, that set-based specification serves as an extraordinary coordination mechanism (keeping your teams discussing what is most important), in addition to a dynamic control document.
Further, if more is learned in the detailed design work that impacts the Decision Map underlying that set-based specification, then that learning is naturally incorporated into the Decision Map as part of the ongoing maintenance of having established that "Success is Assured". Imagine how far ahead you will be on your future projects having all of that knowledge ready-to-go from the start...
Accelerating your team's learning ahead of its decision-making is not as easy as it sounds. Why? Because most of our learning mechanisms / tools in product development are designed for the later phases of product development when we have a CAD model on which we can do a variety of calculations and simulations, or even prototypes on which we can do testing. To feed those analysis mechanisms, we have to make a large number of design decisions that we shouldn't be making in the conceptual development phases where we make a tremendous number of key decisions.
This is where "Set-Based" design and analysis becomes so critical. We need to be able to do concrete analyses on systems where we have not yet made many key decisions and where there remains significant uncertainty.
Around that Decision-Focused Learning process we wrap the Cadenced Mentoring and K-Brief enablers to facilitate efficient collaboration, as depicted below.
The combination of the visual modeling tools and the Set-Based computational engine in our Success Assured® software enables efficient collaboration and rapid learning by making visible the key knowledge that all the decision-makers need to understand before committing their limited resources to an inferior path. It enables the team to rapidly focus their efforts on establishing that "Success is Assured" by their decisions.
Continuing our story...
Finally they had completed their learning and were ready to begin detailed design. With no "fear of the unknown" and complete clarity on what would work, they were able to complete the detailed design in just 4 weeks.
They were then able to easily generate first pilot builds to take to the trade show. The engineering manager was so confident in that pilot build that he challenged the marketing guys to find a flaw... any flaw. At one point the next week, they got a call interrupting a meeting, he had found a flaw: a spelling error in the manual.
In the end, the new design required no rework, and full development of the final production units completed in 14 months, more than 4 months quicker than they would have ever dared before.
And the resulting product hit the target. Initial sales following the show were 2X expected. The next year, they met their annual sales numbers by end of Q1 and ended up 3X target for that product, and 2X for all products.
Three Layers of Reusable Knowledge
Note that the reusability of your set-based specifications and the knowledge on which they were based is not just for the benefit of future projects. This project will need to be able to reuse and continuously improve that knowledge as more detailed decisions are made and the designs are refined and become more concrete, leveraging that more specific knowledge as it becomes available. The K-Briefs (the top level of reusable knowledge) tell that story; within those K-Briefs, the trade-off charts and solvers capture the cause & effect reasoning for the decisions; and the underlying Decisions and Relations capture the knowledge that enable all of that in a reusable way.
Decision Maps
A Decision Map is a collection of related Decisions and Relations that together connect the decisions you can directly control to the customer interests you want to satisfy. The Relations capture the knowledge from the different disciplines that is needed to establish that "Success is Assured" prior to decision-making.
Charts & Solvers
The Charts and Solvers capture how best to see the sensitivities and limits of the design space and how best to optimize your competing decisions within that design space to best satisfy your customers (all the stakeholders). From any Chart or Solver, you're always just one click away from the underlying Decision Map that it was computed from.
K-Briefs
The Project, Problem, and similar K-Briefs tell the story of how the Charts and Solvers are being used to make the required decisions, based on the underlying knowledge. That may include identification of gaps in that knowledge that should be closed prior to further converging those decisions.
Success Assured®
Contact Us to Schedule a Demo today!
Tell us a little about your products and your typical rework, and we'll select an example that's reasonable familiar to you.
Confidently make decisions you won't need to change...
Contact Us
If you have questions, would like a demo, or would like to schedule us to visit you, please email us at Answers@TargetedConvergence.Com. Alternatively, you may call us at 1-888-LRN-FRST (1-888-576-3778). Either way, we'll route you to the right person.
Or if you prefer, you can send email direct to:
-
Our Sales Team at Sales@TargetedConvergence.Com.
-
Our On-the-Job Coaching Team at Mentors@TargetedConvergence.Com.
-
Our Software Support Team at Support@TargetedConvergence.Com.
-
Our Website Team at Webmaster@TargetedConvergence.Com.
-
Our Accounting Team at Accounting@TargetedConvergence.Com.
-
Our Human Resources Team at HR@TargetedConvergence.Com.
After 10 years in Carrollton, we have moved a few miles south to the prestigious Las Colinas region of Irving, TX:
Targeted Convergence Corporation
320 Decker Dr #254-03
Irving, TX 75062-3999
You can visit (and Like! or Follow) us at our official pages on LinkedIn and Google Maps.
The engineers often referred to "fear of the unknown"; it lead to over-designing on the one hand, and to resisting anything innovative (or even different) on the other hand. It lead to rigidity in adhering to specifications rather than keeping the focus on satisfying the customers and meeting schedules. It plagued their process.
Fortunately, the engineering organization had been training on a new set-based development process; and the CEO, Ron Marsiglio, felt this would be a great project to try the new process on. The marketing organization pushed back hard due to the critical timing. Ron's response, "We'd never finish that fast with the standard process, so what do we have to lose?"
Want to learn a little more on the lessons learned at Teledyne Benthos that lead to them establishing that "Success is Assured", more than doubling productivity, and cutting time-to-market in half?
A full case study can be found in our book Ready, Set, Dominate: Implement Toyota's Set-Based Learning for Developing Products and Nobody Can Catch You!
Want to see an example that's a lot more complex than the Teledyne TapTone Leak Detector?
No problem -- Part 2 of our new book Success is Assured walks step-by-step through a collaboration between the US Navy, an unmanned aircraft supplier, a jet engine supplier, and an IR detector supplier, using our software to build maps and charts.
To Learn More...
And our story continues...
Once on their way to becoming the dominant player in the aseptic dairy market, they went after another: aerosol cans. Seemingly quite a bit different, but much of the knowledge they had built was applicable. Given the knowledge reuse, they were able to cut development time down to under 9 months.
Three years later, their standard reliable development cycle is 9 months (vs. 18 months planned and 21-24 actual); and market dominance is the norm.
"Before we designed to the best of the group's ability; now it's the best of the company's ability!" – Robert Chevalier, Engineering Manager, Teledyne Benthos
In fact, they decided they learned so much from their initial customer visits, they decided to return with a visual model of what they now had in mind, and ask some more questions. (This was much to marketing's objection as they felt there was not enough time for that!)
But the additional learning was tremendously valuable (a few examples are in the picture to the left). Had they gotten that feedback after detailed design, some of those changes would have required a lot of rework. As it was, all of that feedback was trivial to incorporate.