What is the Cost Of Change?
Sure, we can change that. No problem. Engineering Change Request(s) are common through development (and often well beyond), but what is the REAL cost? Of course, change and improvement are good — that’s what design and development are all about. However, there are costs. So, how can you minimize the costs in making changes?
Implications Of The Timeline
The product development process starts with a bright idea. Beginning at that moment, changes to the initial idea begin. At first, dreaming has no monetary cost, but only a little time. Then there’s the searching on the internet, the investment of time into thinking, sketching, and maybe making paper mache prototypes.
After thinking, exploring, and maybe some experimentation, at some point, the decision is made to pursue the idea. Typically this is where time begins to have meaning, and costs become real.
The product development process (very simplified) looks something like this graphic. It starts with ideation, then goes into the development cycle of Design > Prototype > Test. The form of that cycle depends greatly on the product. If it’s a software product, you might go through that cycle in a day. If it’s an industrial product, it can take months to go around the cycle.
With each rotation around the development cycle, we learn more, and hopefully refine the product. These refinements, or changes — which improve the product — all have some kind of cost. The magnitude depends on when the engineering change request occurs.
Note: For the sake of argument, we use the term “Engineering Change Request” very liberally. It’s a structure event in some companies, and in others it means only changes after production begins. For this article, it means anything that moves the design in a different direction — big or small.
Costs in an Engineering Change Request
The cost of each change increases because we have more time, money and energy invested. Sometimes the cost is not actual, but inferred — because we don’t “want” to make the change. We’ve put a lot of effort into something and change means discarding at least some of what we’ve done. A graphical representation of the generally accepted Cost vs. Time with respect to Design Freedom is this image.
Generally Accepted Inverse Relationship of Project Cost & Design Freedom
I argue there is not a “Design Freedom” curve, but only a shift in the “Costs” curve with each Engineering Change Request. We are, after all, free to make changes any time. The impact, or cost, of such changes (implicit or explicit) in money, time, reputation, opportunity, etc., are really the issue. For grins, we can show a little shift in the Design Freedom curve as a nod to project inertia, however. Let’s look at a different perspective.
A Wider Perspective Of Cost & Change Relationships
In truth, the effect of activities in the earlier stages are amplified in the later stages. This includes design changes, enhancements, Pivots and just getting distracted on things. An Engineering Change Request fits this too. As in the graph, a little difference in the design at the beginning certainly causes differences in the outcome. — This is not to say that an Engineering Change Request is bad, quite to the contrary. Changes that improve your product or improve your ability to sell the product, or reduce the cost of production, or enhance the customer experience are almost always worth doing. The trick is to identify them as early as possible so the cost impact of the changes are minimal.
In the graph above, the goal is to achieve the GREEN line of optimization. Please note: the GREEN line and the BLUE line can represent a similar value in actual dollars when the difference in costs are primarily time. If the BLUE line represents a product that takes 8 months more to come to market, then the difference is really the opportunity costs of product not sold in the 8 months.
Company A has a great idea for a product improvement. They progress through the design phases in a normal sort of way (RED curve). If they continue along the normal path (Light BLUE curve) in the graphic below we see the potential result. However, during the design cycle, Engineer Q gets some key feedback from the manufacturer and sees an opportunity for cost savings in production. The Engineering Change Request implements, then development proceeds along the RED curve. A big part of the cost “blip” for the new idea is time. Remember, the bottom axis is not a timeline, nor are the steps in symmetric increments.
Illustrated Engineering Change Request Effect
As noted, Company A had a significant cost involved in the Engineering Change Request, but as shown, it is more than offset by the overall decrease in cost over time. So, what would have happened if the cost saving idea had happened much earlier in the design process? How can we help to find those items earlier?
Building on Our Knowledge
Of course, learning is part of the design process. Mostly, we only find the cool changes to optimize the product and decrease cost as we ponder, explore, and experiment with design. These, are the root of the keys to doing the design cycles and the engineering change request better. And, that’s the topic of our NEXT “Engineer’s Perspective” post: Approaching the GREEN Line.