ECOs are stupid II: The price of unincorporated change

The venerable Engineering Change Order (ECO) has certainly had its day in the opulent halls of classical change management, but thanks to technology, ECOs might very well be on the path to extinction. Last time we mentioned that ECOs are slow and stupid, we emphasized that reducing overall ECO cost involves more than just reducing avoidable change. The second half of that battle involves the change process itself, evolving it to be both more agile and effective. Protip: It’s all about addressing the weaknesses of unincorporated change.

ec2ec020916746582f693df4f6f50bfa

Double hot turbo

The whole “unincorporated change” thing

But just what is this unincorporated change thing, anyway? The traditional engineering change process details new changes on separate documentation including the rationale behind the change. The ECO follows its own lifecycle and stands as a permanent attachment to the design record until the changes are fully incorporated into the original design documentation at a later date. Until that future incorporation, the ECO stands in conjunction with the original design to represent the changed design record. It’s official documentation, yet is still a separate attachment, hence the term “unincorporated.”

OK, so that’s just fabulous – why is unincorporated change necessary, why can’t you just make the change directly to the design?

How we got stuck with the limitations of the past

The concept of an unincorporated change was a necessary compromise in the past because of limitations in changing design data, especially in the era of manual drawings and early CAD, when drawing views didn’t just update with a click or two. Understanding the difference from one version of a design to another chiefly involved intense staring for prolonged periods of time until the change was understood and/or blindness occurred. To minimize eye strain, ECOs often highlighted the changes specifically, sometimes with designation of WAS/NOW views side by side on the form. As in now-now, not then, which, ironically, would be incorporated soon.

That was then and this is now

So if design changes today can be applied with a click of a button, why does the original ECO approach persist? Perception is that the ECO is a faster process, even though –technically– such a change should be subject to the very same approvals to enact as a normal drawing revision. But often the spirit of ECO “fastness” prevails and many companies internally foster a bit of a double standard when it comes to change approval. Especially if the change is marked “hot” (one of the most abused modifiers in engineering history) with some bright colors or some menacing stamp, and then everything’s suddenly fair game in ramming the change through the system. But hey, you got the change out, right?

Unincorporated change has a price

What few realize is that unincorporated change suffers from several problems that offset any release turnaround advantage:

Reincorporation inefficiency:

When an ECO change is finally reincorporated, chances are whoever is tasked with that job is not familiar with the change and may interpret it incorrectly (especially if several changes were stacked together), introducing error. This is especially troublesome with changes which cancel other changes. ECOs can’t be dependent on other ECOs. They must stand alone. So a redo of a redo cancels the original.

But you also don’t want to cancel an ECO that cancels another ECO for reasons concerning your own sanity and sound configuration control. The confusion involved can be overwhelming, and is the reason most change processes also reasonably limit the number of unincorporated changes that can be attached to any one particular design.

Interpretation cost:

The most damaging penalty of unincorporated change is the interpretation cost of that attached change throughout the life of that particular design. Anyone who has seen a drawing with unincorporated changes stapled to it and highlighting or red marks everywhere (or the digital equivalent thereof) are quite familiar with that cost.

The problem is that interpretation cost occurs each and every time someone has to look at the design. Not just the engineer, but everyone. Even if the ECO is fully electronic, you have to go fetch and view that record separately; you have to open two things and not one.

Obscured design intent:

A key advantage to the ECO is recording rationale for design intent, i.e. understanding why the change occurred. The trouble is, in most cases this information becomes obscured upon incorporation. The typical revision history on the new version might read “incorporated ECO X”.

So if you come in after the fact, and wonder why the revision happened to begin with, guess what you have to dig up that ECO. And while a good management system will allow you to find the link and then open it separately. It’s not cohesive. It’s old school.

Time to simplify, man

There’s value and compactness in introducing change directly into a full revision and relying on the expanding repertoire of comparison technologies to quickly understand differences between subsequent models and layouts, or even an entire history all at once. In more complex workflows, however, this can get tripped up a bit when you have multiple out of sequence changes, but that’s something we will talk about another time – which is how the linearity of engineering change is about to go away.

While you think about that, I have drawn up this new ECO for you to sign which cancels the one I showed you yesterday. This one is double-hot-turbo-EX-alpha-plus-with-a-cherry-on-top-and-a-side-of-fries. If you could sign it in the next five minutes without staring at it to the point of blindness, I’d really appreciate it.

 


 

  • Hi Ed,

    Not sure I follow you 100%. What about changes that are necessary for a single customer and where it would cost too much to impact manufacturing. And 2 versions of the product later, you believe that it would be a real asset to incorporate this feature?

    I’m just visualising the network graph from a github repo and it seems legit sometime not to incorporate changes directly

    • Yoann, great comment! Technically, by the tenets of classical configuration control changes for a particular customer should be broken into it’s own product line, and/or handled by effectivity. But let’s imagine that such a thing is too complicated for most folks, and think about a modern intepretation. It’s great that you mention GitHub, because I’m going to talk specifically about this next.

  • Sean

    Looking at the first installment and this latest article I am not so sure about all of this. First, if you are incorporating document controls in your early stage design when everything is fluid, for any product, in any industry, you are doing it wrong. It doesn’t need to be there and only serves as an impediment when change is absolutely necessary to get through these early stages of development. Once you have a design that is “verified and validated”, and you are ready to make some of “it”, and if whatever “it” is will go to the customer/public, then you need to lock it down. This is where the ECO comes into play and is crucial. You have your design review where you present evidence that the design is ready and everyone signs off of the real “first” release of all controlled documents. From here on out, they are “controlled” documents, and need an ECO to be changed. Change to controlled documents is supposed to be a bureaucratic pain by its own design. You need accountability to make changes from here on out. To accomplish that you need to present evidence as to why the design is changing or deviating from the original validated release. To do this properly, the right people need to see this change and approve it. Otherwise, you will get a bunch of people going rouge and making changes that might affect the larger scheme of things which the person making the change is are unaware of. And after all, change is only as good as the people making it. These document controls are part of a bigger design control scheme that is needed in many regulated industries like medical and aerospace. Nobody likes regulation but it is needed. Especially when working on large and complex systems with imperfect humans making changes to them! Could it be streamlined with better electronic platforms? Surely. Should it go away? No way.

  • Bob Guthrie

    Thanks for the interesting articles.

    I’ve been working on the same government program for about 18 years. It’s a complex system with multiple stakeholders and an inconsistent funding history. At this point in time virtually all of the equipment is built and we have thousands of drawings, tech manuals, test procedures, etc. We expect to finish testing sometime this year, but we will have over 500 “liabilities” to the various documents. They call them liabilities because we are not funded to incorporate the changes.

    We have a shared Web site with all of the documents. But in order to see the final design you must locate the the latest revision and the letter that forwarded the comments and assigned the status of “approved with liabilities.” I think this is what you would call unincorporated changes. Some documents are actually approved as redlines, and some approved redlines have additional liabilities. It’s kinda crazy…

    My goal is to maintain a hard copy drawing book with redlines that reflect all of the official comments (liabilities). I’m working on a plan to have these updated redlines scanned and posted to the Web site, but I will probably need additional funding. At some point the documents will all be turned over to the government in their current state. Sometimes I wonder if these changes will ever be incorporated?