Change Implementation is Much More than Change Control
In this month’s CMsights we speak with Lisa Fenwick, Vice President of Product Development for CMstat, to better understand what exactly is Change Implementation Planning and Verification. It’s a timely topic because many product and project managers are justifiably confused by the overlapping terms change control, change management, change implementation, and configuration management. “Aren’t they all the same?” we are often asked. Read on to find out how they are different.
Lisa, the management of change has always been a fundamental part of product management and a core function of configuration management, so why is it getting more attention now than ever before?
It’s no secret that managing changes to products, systems, and processes has become increasingly more challenging and thus visible in recent years. There are many reasons. These include the growing complexity of products, more product variants, longer in-service lives, different global markets, compressed NPD cycles, competitive pressures, regulatory compliance and ITAR restrictions to name just a few. And as we have seen during COVID, ever-so fragile supply chains. All these are occurring with the relentless drumbeat from executive offices to improve efficiency, profitability, and now sustainability of not just product lines but the entire business enterprise.
I also think that many organizations if not entire industries were rather lucky over the years. They could compensate for the lack of strong change management processes, or having a comprehensive configuration management (CM) framework, because they had the luxury of calendar time, ample budgets, high margins, few technology disruptions, patient customers, or an over-reliance on quality processes to catch mistakes. Inefficient or nonexistent processes could easily hide behind their other successes and reputation. It’s certainly not that way anymore. As a result, the imperative for implementing ‘best practices’ CM is now well understood throughout many industries, not just Aerospace & Defense where it originated. Consider the recent example from a certain large social media provider who admitted a global shutdown was due to a “configuration change” mistake during an upgrade of their many apps.
The digital transformation journey has made many things possible that were previously unfeasible. But it has also laid bare the deficiencies of those organizations with low process maturity levels. For laggards, many ad-hoc processes of their business needed to be discarded then redefined before they could be repeated, automated, and finally optimized. The good news is that change implementation as part of an overall configuration management plan is a process maturity opportunity with a high ROI potential.
I’d also add that many companies who have previously implemented CM are now ready to take the next steps to standardize and mature their CM processes across all products, programs and suppliers. They realize that with the pace of innovation, resting on status-quo accomplishments will not keep them equal with their peers but they will begin to fall behind.
Can we start with a definition of the term “Change Implementation Planning and Verification”?
First of all, and I should have mentioned this at the onset, notice that there is not a comma between Implementation and Planning. We are talking about the planning and verification of change implementation, not the planning and verification of changes. It’s not a minor distinction, but an important one. Let me elaborate.
Much time is often given to the rigorous definition of a proposed change and its justification. This is especially so when compared to the level of effort for the description of its implementation and metrics for its verification. That’s not surprising because most changes come out of engineering where their responsibility is often limited to detailing and justifying the change, including business decision parameters, and undertaking an effectivity assessment or impact analysis. But engineering rarely has the final authority to actually implement a change, much less verify it was done correctly, and even less likely to have motivation to audit the change process afterwards or learn from mistakes.
So with that context, and at the risk of introducing yet another acronym, let me just call Change Implementation Planning and Verification “CIPV”. CIPV is best thought of as a workflow process that crosses through multiple organizations to assure that the changes defined and approved are implemented in the design data AND the product or process. The CIPV process must provide verification of both the accuracy of the end result and that all updates to product data and status are captured correctly.
Metrics resulting from these tasks can lead to continuous improvement and are as valuable an output of the change process as the actual change. Metrics can reveal engineering product development efficiency, accuracy in estimating recurring and non-recurring costs of changes, efficacy of product data communications, proficiency levels of change reviewers and change control board (CCB) members, and a host of other enterprise performance characteristics.
The planning of change implementation has historically been short-circuited due in part to siloed functions within organizations resulting in a lack of communication, poorly defined responsibilities, and failure to have an experienced CM professional orchestrating the change process end-to-end. This often results in the change request and approval process exhausting the organization, with the clock running, even before it was implemented. As a result, the time left to focus on opportunities for process review and improvement is nonexistent. That is one of the most valuable benefits of moving from a simple change control mindset to one of change implementation process.
What do program managers, project leads, or product portfolio executives often not understand about CIPV?
Some often think that having a change form is the same as change control and that change implementation is automatically assured. Others think that if you are doing change control you must certainly be executing configuration management. We addressed this in a previous CMsights article How is Configuration Management Different from Change Management.
It surprises me that after several decades of widespread use of PLM-enabling solutions we still find performance gaps between what change is specified versus what is planned for and finally what is actually implemented. Change management is not a button within PDM software to push as it is not complete until the change is verified! And that is what many engineering-centric PDM and even enterprise PLM solutions fail to track and report upon.
What do program managers, project leads, or product portfolio executives often not understand about CIPV?
Oversight of change management and change implementation should not be the purview of engineering. I can’t emphasize this enough when I consult with CMstat customers, even when in a room full of engineers and their engineering managers. But in my defense, I say this as an always-at-heart mechanical engineer who first learned about configuration management from another engineer!
The challenges and risks in performing – or not performing – CM span across the enterprise beyond engineering to include R&D, test, quality, procurement, logistics, manufacturing, and field service. To support this wide reach, I find that in the most mature organizations the responsibility of CIPV, as does overall CM, rests within the Quality Assurance team. And as a result, it often has executive-level oversight, sponsorship, and authority. This was also addressed in a previous CMsights article Configuration Management is Quality Management.
From a practical standpoint, the Configuration Manager is often the one who also educates and trains of the rest of the organization on the CIPV process. Not every project or product line is fortunate enough to have a configuration manager assigned to it or even their own CCB. I have observed that the best configuration managers are really more like symphony conductors. They have provided, if not written, the sheet music all the sections must play to. Their job is to keep them all in harmony and on tempo, knowing they themselves cannot play all of the instruments.
As example, we once had a consulting client who had successfully improved the speed of engineering change approvals. But they did so without much regard to planning for implementation of the changes. By adding a change planning function, they were able to properly prioritize and allocate appropriate resources. This allowed stakeholders to have input early in the change process as well as the ability to more efficiently designate resources. Furthermore, there was no process within the team responsible for implementation to know which changes were urgent as everything became urgent. And without a CCB there was no opportunity to mitigate potential risks posed by implementing changes in the incorrect order. The final flaw was that with no executive oversight changes often degenerated into a blame game.
You said that Change Control and Change Implementation is part of but subservient to Configuration Management, and not the other way around. Can you explain more?
It’s true that different industries have created and evolved their own definitions, standards, and practices for change control, change management, change implementation, and configuration management. That’s one of the reasons there is still so much confusion.
As example, in the software industry they focus mostly on version change control of code. Many think that is CM, but in reality there are many principles of CM left out of this overly simplistic view. Yet, that is rapidly changing as the interdependency of software and hardware converges to enable faster new product releases and updates to existing product lines. There was an insightful presentation at the last CMPIC CM Trends (https://cmpic.com/index.html) event on this very topic by David Clark who spoke about “What are Software CM’s Responsibilities?” and why version control and change tracking is just the start to comprehensive CM.
So CIPV is a big part of CM, if not for many organizations the most significant, but there are other equally important elements. These include detailed planning for all aspects of managing product and associated data, safeguarding product data, complete product identification and structuring of configuration items, providing roles-based access and metrics reporting, processing product information for release, periodic evaluation of processes and procedures for continuous improvement and efficacy. And it helps by revisiting the core functions of Configuration Management as illustrated below. Change Control is just one of the pillars. CM Planning of implementation spans them all.
What functionality is important within a CM software solution to support change implementation planning and verification?
As discussed so far, engineering-driven change control should not happen without also managing change implementation. The processes, data, and digital threads that are used extend far beyond those of ECRs and ECOs or data revisions and versions. Unfortunately, many PDM and PLM implementations still treat configuration management as if it was a rather simple exercise in creating and distributing engineering change control forms and supporting data.
Orchestrating change is a vital function of Configuration Management. The planning of change implementation is a project in itself. Assigning tasks, initiating workflows, tracking action items, scheduling milestones, collecting performance data, and reporting metrics, are all part of the project. Within an enterprise there can be dozens if not hundreds running at the same time along parallel or intertwined paths.
And remember that the management of change is a circular process, not linear. As example, data from the end of the process, the verification stage, must be fed back to engineering, software developers, logistics, and management so the organization can learn from successes as well as mistakes that are only discovered during verification and audit. Functionality that manages this iterative circular process is important to see in any CM software solution you are considering.
Can you give us an example of this from CMstat’s EPOCH CM solution?
It’s not as easy to illustrate all the details in an interview, instead of during a live demonstration, as the devil is indeed hiding in those details that others often fly right over. But I can recommend that when examining the capabilities of any CM software, including our own EPOCH CM, you should ask to see its capabilities demonstrated when applied to not just a simple change order but to a complete end-to-end process. One that starts with a change request from outside of engineering and crosses the boundaries of multiple roles who will not be CM experts nor routine users of any PDM or PLM or even CM software. As example, a maintenance engineer in the field researching a series of changes as part of a project to refurbish deployed equipment by serial number. He or she is starting with a baseline configuration that looks nothing like that of the product when shipped by the OEM, and of course they likely have no access to the original PDM data even if it was still accurate.
You can see the start of this process in a recent CMstat video blog HERE where we demonstrate the workflow for changes to an As-Built configuration. The change can impact the complete product structure that for deployed assets may be far more than an EBOM parts list. The As-Configured dataset can include hardware components, but also software/firmware, documentation, substitute parts, compliance certifications, change records, service orders, performance testing data, and now digital twin models. Any of these can change over the life of a system requiring tracking and traceability of all associated relationships and effectivities. How the scheduling and statusing of implementation tasks and data capture are performed and made visible in the change records over that extended history is an important capability to see demonstrated.
We address other important CM capabilities on our website HERE and the software functionality required to deliver these capabilities HERE.
There’s been much discussion at industry conferences and in blogs about the role of Model-Based Systems Engineering (MBSE) along with the use of Digital Twin (DT) models. How do you see this impacting the evolution of configuration management and the execution of change implementation?
Yes, that is another timely question worthy of a separate session all its own. In many ways, it will create more uses and challenges that will ultimately raise the visibility and value of CM within an organization. It’s hard enough to implement CM across a single product line, but when you have system-of-systems, including real and virtual models of digital twins used for in-service performance-life monitoring, the role of CM will be greatly elevated when done properly, and highly exposed when not.
The level of process visibility and traceability required to attain the goals of MBSE is not achievable without a mature level of pervasive comprehensive CM. There’s a fair amount of debate if legacy PLM and engineering-centric CM tools are up to the challenge to support the model-based data-driven enterprise. Jos Voskuil wrote about this in a recent blog I also recommend reading (https://virtualdutchman.com/2021/09/12/to-road-to-model-based-and-connected-plm-part-5/). Also check out INCOSE (https://www.incose.org/) then look for more discussion about this topic from CMstat in a future CMsights article.
A final question for now, where can one go to learn more?
Each of the CM training organizations like CMPIC (https://www.cmpic.com/), NDIA (https://www.ndia.org/education/certifications/configuration-and-data-management-certification), and the Institute for Process Excellence (https://ipxhq.com/) offers a bounty of resources and classes. The basics of change implementation is typically covered as part of the core principles training. As example, for CMPIC it is part of the agenda of the Configuration Management Principles and Implementation Certification classes (https://www.cmpic.com/configuration-management-certification-training-classes.htm).
For those intrepid enough, you can dive directly into the SAE EIA-649 standards (https://www.sae.org/standards/content/eia649c/). For better appreciation of the history, the Mil-HDBK-61 Military Handbook on Configuration Management Guidance (https://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=202239) originally published in 1997 was the first to address planning and implementation in detail for DoD contractors.
And there are a few books that cover this topic as well. The 2nd edition of “Configuration Management Theory and Application for Engineers, Managers, and Practitioners” (https://www.routledge.com/Configuration-Management-Second-Edition-Theory-and-Application-for-Engineers/Quigley-Robertson/p/book/9780367137250) by Jon Quigley and Kim Robertson is notable for its breadth and depth of real world examples. Another one I have on my bookshelf is EIAHB-649 which is the implementation handbook in the 649 series of standards.
Finally, the CMsights archives on the CMstat website have a number of article and papers which you can register to receive updates by following CMstat on LinkedIn.
If you have a specific question not answered by these resources, I invite readers to connect with me on LinkedIn or email me at lfenwick@cmstat.com.
Thank you Lisa Fenwick!
Receive CMsights
Subscribe to CMsights News for the latest updates from CMstat on Configuration Management, Data Management, EPOCH CM, and EPOCH DM.
Request a Demo
See how EPOCH CM and EPOCH DM support industry standards and best practices in Configuration Management and Data Management.
