ECOs Aren’t Dead, But They Are Slow and Stupid

In engineering, change is fundamental; product design is a highly iterative process. While change is necessary, it can also be quite costly. Most reasonable estimates place the cost of a single Engineering Change Order (ECO) in the thousands of dollars just in the design stage, with quickly compounding cost for changes later in the lifecycle. Ouch.

Managing change with ECOs can sometimes be a struggle between two divergent goals: the need to accelerate time to market and the requirement to methodically characterize and document every product change. Integrity versus speed is the central conflict in any given change process, and often the catalyst when a process breaks down.


Controlling the Cost of Change

Effectively managing the cost of engineering change involves a two-pronged strategy:

  1. Preventing Avoidable Change: Understanding why change is happening at all, based on prior experience. Involving causal analysis and remediation, the goal here is to prevent certain undesirable and entirely avoidable ECOs from ever happening. This saves money by either reducing the total change volume or pulling changes earlier into the lifecycle, where they are certainly cheaper. But not all changes are both predictable and avoidable.
  2. Improving the Change Process Itself: Streamlining the process by which ECO's are generated and incorporated into the product design, and how those changes are vetted and documented. Technology can play a big role here.

Joe Barkai did a fine job discussing the first strategic component in Take Control of Your ECO Process, so we'll focus on the second part on the change process itself. Perhaps we should say ECOs are dead. Just kidding. But it may indeed be time for ECOs as you know them to change. Here's why.

Process Tradition

Most engineering change processes are rooted in very formal and traditional frameworks. ECOs can be traced back to Configuration Management (CM) practices that literally come from a time well before CAD (much less PDM/PLM) where manual drawings ruled the earth. Engineering data was neither readily portable nor widely accessible. These effective but complex practices were established in the larger, older manufacturing companies that became the first natural customers to afford PDM/PLM..

As a result, these processes live on and are perceived as absolutes. They remain relatively intact, buoyed by large company process culture despite the opportunity to evolve. It's the equivalent of having an old textbook thrown at you. If we go by the book, Admiral, hours would seem like days. And for some companies that is very much the case – some change processes have been known to take months, even years.

New Challenger Approaching

For a nimble SMB, a change process that takes months or years is death, but just kicking established CM wisdom to the curb could be even more dangerous. What to do? There are these things that have popped up since the genesis of CM methodology – we call them computers. But even more importantly, the ubiquity of design information in the cloud fundamentally redefines the problem and provides a unique opportunity to improve change processes. Especially when it comes to the capability for anyone to both view and compare various versions of design information quickly and easily with or without access to CAD tools.

The World's Upside Down

One possible snatch-the-grasshopper-from-my-hand epiphany is we have reached a point in CAD authoring where it is easier to actually execute a fully incorporated change than it is to traditionally propose an unincorporated one. So the older methodology of [identify-propose-authorize-implement] may need to be turned quite literally on its head - i.e. simply incorporate the change then decide whether to authorize it using comparison tools.

If the change is no good, then it's simply set aside. It might seem radical, but it's very much akin to the transformation in the software world from stage-gate or conventional waterfall development to agile methodologies. The difference today being that technology can be leveraged to allow intact history to intrinsically remain even in unusually compact change processes.

Next time, I'll speak to more specific examples of incorporated and unincorporated change, how traditional ECO documentation has been handled and some places they could go to from there. In the meantime, share your short-term frustrations with change process agility in the comments below.



buyers-guide-for-pdmThe Buyer's Guide for PDM 

Every class of technology undergoes an era of innovation and disruption. For PDM systems, we’re in such an era today. Lifecycle Insights' Principal Analyst Chad Jackson put together the perfect buyer's guide to help you weigh your options.

guide to CAD file management





  • Mauricio Souza

    ECO’s arent dead… but they should be :-)

    In our company, ECO’s are really slow and burocratic. The necessity on making a document (or more) to record the ECO, the necessity to change tools and drawings, to separate old parts from the new ones on the factory… Yeah, it’s quite difficult to manage them.

    The ECO’s are so slow that many times we also skip some steps to implant them, and then we make the burocratic part at a second time. The problem is: we are making this too many times, and right now we are have more people to “correct” the ECO’s…

    The main challenge seems to start the disign the more accurate as possible, to prevent the ECO’s to appear. Quite difficult, but seems the best way to go.

  • This is such an important and fundamental issue, surely most PLM systems have gotten an agile workflow in place to handle ECO’s elegantly… Right?

  • e_is_real_i_isnt

    The ECO ‘problem’ is that it should serve several needs, and in skipping those needs, can seem relatively complicated or irrelevant.

    Before the initial release of a document a large number of factors need to be considered – how the part fits with other parts, that the materials are useable, that suitable manufacturing processes are available, and so on.

    When a change to released documentation is required, there needs to be as much consideration for all the original factors. The ECO is to tell all those involved not only what changed, but why it changed, and to give the participants the information needed to evaluate if the change is a good one to make. When the reason on an ECO is a weak one, like “manufacturability improvement,” the rug is pulled from beneath all participants.

    What should be the case, nowadays, is to have both the ECO and incorporation floated at the same time. This gives participants an idea as to what is changing, why it is changing, and make sure that the expected incorporation matches the actual incorporation.