“The concept is great and it’s working! There are some ‘minor’ issues, but we’ll solve them by the next iteration. We have a mock-up working 95% and the rest is just out-of-tolerance issues– which is normal in the prototype stage.”
How many of you have heard this before? Only to learn in a few months later in production the project is delayed due to technical issues with a component or functionality that isn’t behaving the way it should. We often face production issues that could be avoided by more thoroughly testing concepts. The objective of this article is to create awareness of the resources committed when signing off a concept, and how these decisions are made based on weak foundations.
We know from both theory and experience that approximately 70% of all cost is encountered in the concept phase. The graph below (pic.1) shows that much of the product life cycle cost was accurately defined early in the process, when the consequences of this decision may not have been investigated.
Take for example when a business case is built on a prototype/mock-up with partial functionality. If the prototype quality or functionality tests return random outcomes, then the rationale for the business case becomes proportionally weak. If at this point, we move forward to the next phase we risk not delivering on our commitment.
This leads to the conclusion that higher-quality initial concepts result in not only more accurate cost analysis but also better chances of meeting the timeline and predicted cost. However, innovative concepts or appealing designs are sometimes embraced too eagerly without considering potential issues they may carry. But what are the consequences of these oversights?
Pushing a concept that has an unresolved fault through to production will eventually lead to both increased cost and delay- assuming the issue can be fixed. The development team may also discover, contrary to the plan, that there isn’t enough space for every component and a complete restructuring is required. I have witnessed both of these scenarios and, I must admit, also been part of them.
There are many studies describing how to manage the transition from concept to production. However, in practice, there is a lack of understanding and acknowledgment in this area. Often, I’ve seen that the concept work is underestimated and understaffed. The resulting outcomes are very late, and not sufficiently developed and thought through.
Companies usually have a process for review before a gate can be passed. This requires a team to look over the work that was completed in the previous phase. Such reviews are structured and provide an output. The result is a better understanding of potential issues when introducing a concept to production.
In my experience, topics raised during such reviews are based on the participants’ knowledge and feelings more than actual documented information. Experience is good, and in many cases underestimated, but often crucial data is lacking. Usually, a decision is made regardless of a lack of data, to move the concept into production and now the cost is committed.
What can we do to improve this? Considering what we know about this process, the decision to move forward from the concept phase should be made as late as possible. Spending more time testing and optimizing concepts ensures the next stages run smoothly. We should make efforts towards improving the understanding of the impact deciding to clear a concept gate has. This is crucial for making quality decisions. An approach that values these early stages would allow us to reduce the risk of potential problems (pic.2).
To do so, we need to spot possible problems beforehand. This is made possible by achieving a deep understanding of a product’s requirements and functionality as well as production capabilities. Following this thought, the decision-makers need to determine not only if the product has the technical and cost base to move forward, but also the right team to complete the product. This is a big challenge with even bigger consequences if not executed correctly.
Just imagine a company invests 10% of the cost on a loop back at validation during the initial phases? What if instead, we tested a few alternatives and gained more confidence before kicking off? Detecting even one critical issue before the initiation of the project will give us a huge advantage. If we continue jumping into solutions without performing due diligence testing and trying to fight our way through, we will never improve the process.
Even a simple analysis of basic interfaces (i.e. sensitivity of mechanisms, length of snap hooks, space for electronics, etc.) can give us insights about our chances of success. Product knowledge should be at a level that ensures functionality. This requires that the team involved has the knowledge, capability, and authority not only to point out potential issues but also to offer possible solutions to eliminate or avoid them.
I recently had a concept open for more than a year due to a “game-changing” requirement from the customer. The only way to gain enough knowledge to incorporate this new feature was to test. We finally closed the concept after finding a technical solution that met the requirement from the customer. Thanks to a thorough concept phase, the development was done very quickly with no loop backs.
Keeping the concept open for such a long time allowed us to have several iterations in the design phase which solved multiple minor issues. It also let us completely reconfigure how the product looked without involving other departments like quality, procurement, and process. We focused on getting the concept right and ensuring that the design was compliant with the expectations of the customer and at the same time eliminated the majority of administrative work.
We recognize that this change will be difficult. There are many good development projects out there with a high degree of success and no loop backs. But these projects usually have some level of repetition to them. To achieve the same level of certainty with less familiar concepts and solutions or less experienced reviewers, there is a need for a more data-driven approach to product analysis, along with the demand from management for more objective certainty when clearing project gates.