Take Control of Your ECO Process

Product design changes are inevitable. In fact, they are an essential part of the product lifecycle. Changes to a product design are triggered and implemented mostly (but certainly not only) during design, prototyping and test iterations in response to a new market requirement, a cost take-out campaign, changes in cost or availability of a critical component, issues discovered in manufacturing or even in field repair, and myriad other reasons.

Engineering Change Orders

Industry uses different terms and acronyms to identify the design change process: engineering change order (ECO), engineering change request (ECR) and engineering change notice (ECN). Your company may prefer yet another term. Yet, one thing that large product organizations have in common: they take a highly formal and structured approach to managing design and manufacturing process changes.

Design changes may be necessary in response to, say, a new market requirement. A typical ECO process identifies the reason for the change in the product design or manufacturing process, details of the design or process change, and potentially other information such as cost impact analysis.

This sounds great until you take a hard look at actual ECOs.

Many ECOs are Preventable

The figure below shows a breakdown by root cause of ECOs at a large industrial equipment manufacturer. Careful review of the classification of ECOs in this chart reveals that many ECOs are preventable. A few examples of avoidable design mistakes that resulted in an ECO:

  • A design feature that does not match the capabilities of a preferred supplier, for example, special manufacturing process or machinery.
  • Drawing errors.
  • A design that cannot be manufactured to meet quality targets, for example, because of inadequate wall thickness or incorrect draft angle in plastic molding.
  • A design exceeds the part’s cost target.


Detailed analysis of these ECOs reveals a multitude of factors that contribute to the high rate of preventable ECOs—in my research I have seen it as high as 80%—and the waste they create. But fundamentally, most, if not all, of these factors can be rolled up into a single general root cause: engineering organizations do not capture and use knowledge, experience, and best practices effectively. Under pressure to accelerate the pace of getting new products to the market and the emphasis on agile development methodologies, engineering teams may decide to skip the formalities and not document ECOs fully and in a manner that newly acquired experience, knowledge, and best practices can be reused in future designs.

As I commented in another blog post:

Organizations that do not retain detailed change history are bound to repeat design and manufacturing errors, going through unnecessary design iterations and manufacturing rework.

When is the Best Time to Implement an ECO?

Common wisdom, especially if you have a quality engineering bent, is to implement an ECO as soon as possible. While this is very rational decision if an ECO is to address a safely issue, there may be reasons to hold off and not implement other classes of ECOs right away.

When an ECO is issued for a product that is already in volume production, the design change may result in scrapping work in process, part obsolescence, disposal of “bad” inventory, or rescinding a supplier contract. On the other hand, not executing that ECO will result in continued product failures, service calls and warranty expenses.

But with the understanding of these differing views, business owners can make a rational business decision: should the ECO be implemented sooner in order to prevent failures and the associated costs and damage to the brand image? Or, perhaps, should the ECO be delayed in order to minimize direct losses in inventory and work in progress?


The ECO process is an essential product lifecycle activity and should be managed as such.

  • The root cause, the corrective actions, and other information such as cost impact analysis need to be incorporated into the PDM system so that design and manufacturing errors are not repeated. In particular, recording the design intent behind every design and process changes can accelerate design time, reduce design iterations, and promote quality.
  • In the same vein, a centralized view of cross-product ECOs can facilitate faster and efficient root cause analysis of design and quality issues.
  • Managing ECOs inside the PDM software also helps implementing any number of derivative activities such as updating work instructions, supplier communication, and compliance verification.
  • Finally, PDM, together with ERP, are ideally suited to provide the additional context necessary to perform a detailed impact analysis and prioritize ECOs.

As a parting thought, here is one use of ECOs with which I do not entirely agree. I worked with a manufacturer of high-tech equipment that fully embraced the ECO formality and integrated it methodically and painstakingly into the product development process. The engineering team tracked the rate of new ECOs to determine what they believed was an indicator of “design maturity”: when the number of new ECOs fell below a certain threshold, the design was deemed ready to enter volume production.

In my opinion this strategy represents the exact opposite of a PDM-centric knowledge-based development, where design and knowledge reuse are use to reduce the rate of design errors at the root instead of going through the iterative ECO process. But that’s a topic for another post.


guide to CAD file managementThe Next Generation of PDM  

More teams are using Cloud, Analytics, Mobile, and Social tools to speed up product development. Independent analyst firm, Consilia Vektor, explains how this changes Product Data Management (PDM) as you know it and how this can help your team work smarter.

guide to CAD file management




  • Mauricio Souza

    Hello Mr. Barkai,
    I was trying to understand your graphic, but there is something I couldn’t get it. You described 7 issues that affects the quantity of ECO’s, but there are more 2 items on the graphic (which correspond to almost 50%) that are not described. Who are these two guys? Best Regards!

    • Hi Mauricio. Thanks so much for noticing (you must be an engineer…) and letting me know. The chart’s legend got truncated; we will upload the correct chart. In the interim, the largest items, in descending order are: Assembly, Costing and issues discovered early during testing & simulations.
      Thanks again,

      • Mauricio Souza

        Hi Joe,
        Yes, I’m an engineer :-)
        Thanks for you list, and I’m going to wait for the new chart.

  • John

    Mauricio, I noticed the same thing, and your comment caused me to scratch my head one more time. I’m guessing the other half of the change orders are in the “unpreventable” category. In my experience (large, complex defense programs), changing customer requirements was sometimes a big driver. It’s management’s job to control the amount of change activity generated at the program level.

    • Mauricio Souza

      I agree. In my company, I have a huge number of ECO’s, and I’m trying to understand why they appear. The first thing I got it: We need to improve our drawings, to avoid an ECO. A training seems to be a good idea to me. Second: our ECO flow on PDM is great, but it is very, very complex – so, the drawings move a lot before the ECO is done; this means that we spend a huge time on them.
      In my case, mistakes and errors found in drawings, simulations and prototypes are bigger than any other cause. But in fact, we usually don’t have many time to take some decisions, ie, we choose to be fast and cheap… and accuracy pays the price. Maybe it’s time to spend more to increase our accuracy.

      • Mauricio, thanks for your comments. Many organizations somehow “choose to be fast and cheap… and accuracy pays the price.” Often, perhaps because the issues are discovered downstream (resulting in unnecessary ECOs) there is an implicit assumption that this is how the process should work.
        I also agree with your observation: “maybe it’s time to spend more to increase our accuracy.” Classifying root causes of ECOs and selecting those with greater impact might be a way to convince the organization to change. I had a conversation yesterday with an aerospace company; they estimate the cost of handling an ECO at $2,000 (plus, of course, the actual fix, potential loss in WIP, etc.) Should be an easy argument…

      • Mauricio Souza

        Hi Joe,
        Right now I had a meeting with my Director, and I showed him everything we have discussed here. He agreed with me that we need to improve our drawings and right now I have a new task: develop a flowchart of new drawings. We are going to have a routine (a check-list) similar that a pilot has before taking off a plane. Before sending the drawing to the factory, we are going to analyse it following all these “rules”. Let’s see what happens :-)
        He asked me to make some reports and charts showing how many time we spend on the ECO’s today, and make the same analysis after this new flowchart. I’m going to check the hours spent and use your criteria: price. As you said, it’s going to be an easy argument.
        All this discussing makes me feel better. Last week, I can tell you that I was a little bit sad and worried, because of our quantity of ECO’s. But now I see that this problem is not an exclusivity of my factory – everyone has. The most important is to realize that it exists, analyse the causes and improve them.
        Thank you for all the information and support!

      • Hi Mauricio,
        Glad to hear about the momentum you have created with the company. Suggestion: although analysis of ECOs will definitely show many opportunities for time and money savings, manpower utilization improvement, etc., there will always be many borderline cases that will draw a “yes but” reaction. I suggest that you set an improvement goal that is not too aggressive and therefore believable and attainable. With so many preventable ECOs even a modest reduction will deliver significant benefits.
        Let me know if I can help in any way (feel free to email directly).

  • three_d_dave

    ECOs represent the same thing every time – something that wasn’t known at the time documentation was released. What is broken down is some of the reasons things weren’t known mixed with the places the oversight was discovered.

    Eliminating ECOs is an asymmetric effort – certainly when a problem is
    identified there is a cost that can be associated with remedial efforts,
    but there is an infinite cost to preventing all possible sources of
    problems in an effort to prevent them all. Many times management only sees the realized costs as real and believes the prevention costs don’t exist and therefore doesn’t budget for prevention.

    The key to knowing much of this ahead of release is more extensive simulation or other evaluations based on information gathered from fabricators and material suppliers. Many vendors won’t divulge the requisite information; most don’t have a means in place to even capture it or see it as a competition secret.

    Some are unavoidable at the engineering end – many times ‘opening up’ a tolerance to accept out-of-spec parts is followed by the manufacturer shifting to a more poorly controlled process and then generating parts outside the newly relaxed requirement. Spot material prices fluctuate. Supplier backlogs increase and decrease, affecting process availability.

    My own method uses a Wiki to capture all the information about an item; its current configuration, past configurations, reasons for changes, analyses, meeting notes, design intent narrative; many of the things PDM/PLM doesn’t put in one place, but scatters in little bits of records all over the place and in files, documents, folders, emails, and verbal communications.

    Of them all, the design intent narrative is the most important and least likely to be done. Most managers just want something done, but don’t put any time into thinking what the ideal result should be, not enough thinking to write even one paragraph. This lack of effort is duplicated by the engineers, checkers, manufacturing, procurement, Test, QA/QC and so on, so at the end no one has a short statement about what any part or any assembly should act like that all the participants can agree is met or not met.

    There is a saying that one watch tells the time, two watches cause confusion. The reality is that two watches are required to understand how the two timepieces can diverge from the desired condition. The design intent narrative in conjunction with the drawing forms that pair.

    • Hi Dave,
      Thanks for sharing your perspective. The point you make about relaxing tolerances is especially interesting because not only does it lead to unexpected ECOs, but also, if not corrected, will result in increased
      no-fault-found (NFF). See http://joebarkai.com/method-reduce-no-fault-found-rates/.
      BTW, in your organization, how to you encourage designers to contribute to the Wiki as they discover new facts and failures? How do you ensure that they consult it during design iterations?