Lessons Learned Implementing Configuration Management
Our latest CMsights post begins a series on the most common lessons that CMstat has seen our software customers and consulting clients learn over the years from implementing configuration management (CM). These include lessons learned – both easy and hard – applicable to a small project, complete product line, major program, or entire enterprise.
As we reviewed our records spanning over decades, one lesson was more prevalent than the others. Not surprising it had the greatest consequences when not fully absorbed. Furthermore, it was valid whether experienced in the aerospace and defense, marine and naval, transportation and mobility, or other high-tech industries.
That lesson is the failure of either the assigned project lead responsible for CM, and/or their management chain, to realize that while they may need CM, they were not yet adequately prepared to implement it without further advance work and training!
One of the most valuable services we have performed for a potential software customer or consulting client was to tell them to stop; don’t proceed further, even with us, until they were organizationally ready for CM. Rarely were the reasons for this surprising recommendation due to technology or software considerations, but instead were related to management expectations, business culture, organizational politics, and training.
A few of the scenarios we have witnessed include the following:
Management thinking of CM as an engineering software tool instead of an overarching business, product line, and quality management strategy.
A company believes they are ready to proceed because a PLM / PDM software vendor told them their solution has CM capabilities ready to be “switched on” and it is as simple as training users in the software.
Likewise, the engineering department has sent a product engineer off to be trained as a CM expert. Upon returning expect that person to have CM deployed within a few weeks’ time working mostly on their own without disrupting or breaking anything.
Anticipating that CM can be implemented within a single department or project silo without affecting existing personnel, processes or products. Yet, if little was changed, then likely the CM deployment was insufficient!
A decision to proceed was made from the bottom-up without upper management fully understanding or buying into the decision, much less funding the effort or providing oversight.
The IT department, or one of their service providers, claimed that they could develop custom code on top of an existing application to provide all the CM functionality that users need.
Existing processes, problems, performance gaps, and maturity levels were not fully understood nor documented with metrics and KPI. (Read more about CM maturity levels here.)
Managers thought configuration management was the same as change control or document version control. (Read more about this difference between CM and CC here.)
There was a plan for implementing CM software, but not a CM Plan which is most definitely not the same. (Learn more about CM Plans here.)
Stakeholders had different goals and expectations from CM once implemented. An example is thinking of CM as mostly a departmental or engineering function instead of an enterprise-wide quality management mandate.
Read more of the most common misunderstandings we have heard over the years about configuration management in our Configuration Management Guide for A&D Program Managers.
So how does one assess if their organization is adequately prepared, aligned, trained, educated (which is different than trained) and motivated to take on a CM project, whether it be for a single project, product line, or an enterprise including its supply chain and service partners?
Some years ago, CMstat developed a checklist of a qualifying questions that we ask early on in a prospective client engagement. These are just a few of the questions we may ask as each one often has a indentured tree of follow-up questions.
What executive office would say they own ultimate responsibility for CM?
What problems and pains are you trying to remedy with CM?
Are the consequences and costs of those deficiencies documented and accepted by all?
Is CM thought to be mostly about change control, or an extension to it?
How is CM and CC currently being performed and by whom?
Have Configuration Items or the Product Structure been adequately identified and agreed to?
Does the organization have an understanding of the breadth of CM as defined within the five 5 pillars of Configuration Planning, Identification, Change Management, Status Accounting, Verification and Audit?
What level are existing workflows and processes at: ad-hoc, defined, repeatable, automated, or optimized?
Do process stakeholders understand “why” they are performing their current tasks? Do they try to subvert or shortcut these existing processes?
What audits are being performed? What metrics are being collected? Who reviews them?
Are the risks of not executing best practices within CM clear and understood by all?
Who if anyone lists CM functions as part of their job description?
Has anyone within your organization attended CM training and been certified, including in standards-based best practices, that is independent of the software solution?
Does your organization have an established training system and a dedicated trainer given the ample time that will be required to develop site specific CM course content?
Does a CM Plan exist or if not, why not? If it was developed in-house, have you had it reviewed and validated by an independent third party?
More often than not, an organization new to CM will not have accurate or complete answers that are satisfactory to themselves, much less us. If so, we then recommend that they ask their colleagues the same questions or invite us in to do so as part of a CM maturity assessment, CM requirements definition, or CM Plan development.
In our next “Lessons Learned” we will share an interview with a customer who speaks of their experience in getting their management to appreciate the importance of training and certification for those who are expected to lead the CM project. We will also unpack some of the responses we have heard from managers who were not familiar enough with CM to understand their own responsibilities in providing oversight, support, and appropriate levels of funding.
Until then, tell us what do you believe are the most frequent obstacles when implementing CM. Visit then follow CMstat’s new LinkedIn page to share your expert opinion or see what others think.
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.
