I find it ironic that, as an engineer on a job hunt, the “conventional wisdom” is that I should use social media to establish myself as a subject expert. And I am amused – bemused, really – at looking back at the things I’ve done on my blog and in twitter (@davidhuntpe)… pretty much not a shred of engineering in there.
Time to change that, and add engineering to my topic list. So I’m going to talk about Engineering Change Orders (or Notices) – henceforth referred to as ECOs.
Every company does them. And every drawing I’ve seen has an ECO block where the revision is listed, the date, and a description of the change. Often it’s a simple “Hole diameter 3.13 inch was 0.25 inch.” Or something was added, or a material was changed, or a weld callout altered. And so on. And there’s something missing: Why.
One can look at a drawing and the revision history and see what happened with each revision. A good engineer with an understanding of the product can reverse engineer some of the details. But even that is a guess about the context of why the change took place.
My habit in doing ECOs is to attempt to capture in the ECO description something of the context. To take that hole diameter example, my ECO comment would be “Hole diameter 3.13 was 0.25; lower pressure drop & increase flow.”
Even this, however, doesn’t necessarily contain enough information. For example, was there a problem? Were there experiments done to validate this change, and what were the results? What were the discussions or rationale behind choosing this as the change to make? So I’ll propose going one step further.
Almost every product data management (PDM) system that handles drawings, CAD files, etc., has the capacity to hold other documents, like Word files. So I’m proposing the idea: have a revision-controlled document – with the same name or number as the component or assembly as well as the same revision level – that gets carried along with the CAD models, drawings, etc., and in which there is space for text, pictures, test results, and other supporting information to capture the WHY of the ECO. The addition of this information should be, as I said, rev-controlled, and needs to be another check-mark box on the ECO that signers must approve.
“Tribal knowledge” is the term for the aggregated background information that is contained in the minds of the people, but not written down anywhere. It’s what makes long-term employees so valuable in an organization. And for products that are long-standing with life spans exceeding the tenure of the people as they churn in and out, capturing the Why of changes is critical to an organization that learns from its mistakes – and a crucial part of continuous improvement. New employees desperately need to know this context of how a product evolved; this context is missing in the standard practices out there currently.
Help your new employees understand this context. Help your organization become one that learns as an institution.
Capture the Why of decisions, and keep them along with the information about the parts themselves. And, more broadly, of decisions in general.
Differentiate yourself as a company that learns.
As my late father one said: “Informal companies put out fires, but are unprepared to deal with them again.” Part of preparation – part of improvement – is knowing why things were changed so that mistakes are not remade.
Why do it? Why not?
© 2013, David Hunt, PE
David Hunt, PE... Mechanical Engineer on the loose! 
It should be worthwhile to do as it can be linked to the drawing. It should help with questions surrounding why did we do that when in another context the change seems misguided. Doubt it will help organizational learning as that would require going back and looking at how the change could have been anticipated, or why it did not work, but that activity should be restricted to those changes that did not work out or resulted in a large cost increase. As most companies do a poor job of even checking if a project delivered the results it should have it is hard to see too many going back and looking at change orders. That said, being able to sort change orders by cost would make that review process much easier.
Reblogged this on The Arts mechanical and commented:
There can’t be to much information in an ECO. The information isn’t for now, it’s for ten years from now when the same sort of issue comes up again and nobody remembers why it happened the first. Companies have a habit of handling their legacy financial stuff very well, even though after tax time, none of that really matters and handling the engineering documentation process poorly, even though the impact of that can have effects that last decades.
Some engineering organizations have an “Engineering Change Request” or “ECR” that is issued first and is linked to an ECN in the Product Lifecycle Management software. The ECR explains *what* the problem is, gets authorized by various stakeholders, and then the ECN is issued to describe the fix.