Understanding the network of root causes of low-quality and slow decision-making on Engineering Change Management.

Engineering Change Management (ECM) is perhaps one of the most complex processes of the product lifecycle. Most companies above a certain size employ IT systems to manage this complexity, and support the IT system workflow with decision-making processes of various types, such as “Change Control Boards”. Despite increased management effort and IT system operating costs, they find themselves often solving the same problems twice, expediting changes causing chaos in teams’ load balancing and projects’ timelines, and–perhaps, worst of all–often find engineering change requests that are never resolved.

For this equipment supplier I was asked to improve a legacy ECM process that had been established years ago and was often being circumvented, despite the implementation of an IT system. The key to doing so was to go beyond single, simple and incorrect explanations for ECM problems, such as “lack of discipline” or “slow process”.

As is often the case in such “wicked problems” arising from complexity, instead of the ECM process itself and exclusively, the findings of this workshop-heavy project were a network of different root causes: some of them related to the process, others to the IT system itself, others to the documentation, and others to behaviors that had been established years ago and were treated as “normal”. Beyond that, past attempts at resolving ECM problems had failed by taking a systems and process-oriented view to ECM that only caused extra effort and bureaucratic decision boards. The stakeholders’ trust in the organization being able to improve ECM had thus reached an all-time low.

By understanding the ECM process as well as the historical background, the recommendations of the project led to a problem-specific modular roadmap of short, self-contained projects to deliver small and visible wins.