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 is 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 is the searching on the internet, the investment of time into thinking, sketching, and maybe even making paper mache prototypes.

After thinking, exploring, and maybe some experimentation, at some point, the decision is made to pursue the idea as a product.  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 is a software product, you might go through that cycle in a day.  If it is an industrial product, it can take months to go around the cycle.

With each rotation around the development cycle, we review where things are going to learn more, and hopefully better 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 is a structured 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 we infer cost - because we don't "want" to make the change.  We have a lot of effort into something and change means discarding at least some of what is done.  A graphical representation of the generally accepted Cost vs. Time with respect to Design Freedom is in this image.

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.  Now we can look at a different perspective.

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 small 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.

An Example:

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.

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?  As mentioned, the earlier improvements are made, the less impact on total project cost.  So, in our graph, the blip moves left, and becomes smaller in magnitude.

And that begs the question:  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.  Allowing time for this is often a luxury that engineers are not given - which is unfortunate, because it has huge effects on quality and total project cost.

This just puts emphasis on the reasons to learn and focus early in a project.  It also puts emphasis on the need to have skilled and knowledgeable engineers on the project early - so they can anticipate the direction and hopefully reduce the need for an engineering change request.  Well, reduce the number and significance of them.

These, are the root of the keys to doing the design cycles and the engineering change request better.  And, that is the topic of our NEXT "Engineer's Perspective" article:  Approaching the GREEN Line.