During the recent assessment of an organization, the topic of CM popped up as a reoccurring theme when it came to problems being experienced throughout the organization. The one thing that became exceedingly clear was that everyone’s definition for CM was very different. One of the prime roles for any business architect is to make sure they are looking holistically across the organization and that everyone is working from the same vocabulary. This is not the first time I am running into the topic of “CM” as a source of chaos.
What needed to be done was to expand on each flavor of “CM” until everyone could identify the specific “CM” business function they were discussing. The first major hurdle was to separate configuration management CM from change management CM. Configuration management is a maintained list of items that make up a configuration controlled system, platform, or product. Change management is a process for handling change. Change management however, is not just one process. Many different aspects of the organization require very different change management processes.
Configuration management can be as simple as maintaining a parts list. When I order a product, I expect it to have a certain set of parts contained in the product. Configuration management can become very complex to the point where every item needs to be identified by very specific attributes such as version number, manufacturer or serial number. As configuration management becomes more complex, the need for a configuration management tool with a database will become a necessity. One thing I want when out, is that the process for changing the configuration is configuration change management not configuration management.
As I mentioned earlier, change management is not one process. Almost every capability will have its own associated change management processes. Which should be obvious, is that the needs of configuration change management are much different than the needs of organizational change management. Many organizations want to assign one person to be responsible for CM. I personally don’t believe that could even be possible based on the levels within the organization where CM occurs.
Change management, expressed as a value stream, is really fairly simple and can be reused for almost all change management processes. Step one-propose a change. Step two-approve the change. Step three-make the change. Step four-evaluate the impact. You can’t ask for something much simpler. Now reality-the processes of change management that relate to each stage of the value stream as needed by the capability.
Those working in the world of initiatives and projects automatically think of change management in terms of project management and draw their process from resources like the PMBOK. Changes are evaluated in terms of cost, schedule and resources that impact the delivery of the project. The decision-makers for the changes are stakeholders in each individual project. The project manager ultimately will be accountable for the effect of this type of change.
Operations and sustainment have their own change management processes. These changes are more commonly referred to engineering change requests or business process change requests. There is no “project” or project manager. The decision-maker is usually an operations or sustainment manager. Changes are evaluated in terms of solving existing problems, improving quality, or increasing profitability. Typically, the change management processes would be based on ITIL or Six Sigma. Some of these changes can be implemented by one or two people while others may require a full-blown project. So while it is part of operations, it uses the service change management process. However, if elevated to a project and additional changes are made after the project is instantiated, it will need to use the project’s change management process.
The most complex process is organizational change management. This could be the result of a merger or acquisition. Organizational change management could be a total change in the way the organization does business or affect a line of business. Organizational change management can be the most disruptive process for everybody. These changes are evaluated in terms of the vision and mission of the company. This is a top down change that should involve the entire organization or at least some major parts. The change management process used is based on processes like Lewin’s model or Kotter’s 8-step process. The decision-maker should be the CEO.
The point of all of this is that if CM refers to Change Management, it’s not a single business function, involves different approval processes, has very different levels of communication required and impacts a variety of scopes within the organization. Speaking of approval process, there are as many varieties for approval as change management itself. That’s where the acronym CCB crops up and again this is not a well-defined thing. CCB could be a Configuration Control Board or it could be a Change Control Board. It depends on the context and the organization. There’s also the CAB or Change Advisory Board. A CAB is different from a CCB in that the CAB does not have the final authority to approve a change.
This all brings me back to the business architect’s value to the organization. Identifying mismatches and documenting appropriate vocabulary will resolve many communication issues. If I had to rank organizational issues, communications would have to be in the top three reported issues in almost every organization I have helped. By far the leading root-cause I’ve discovered leads back to poorly understood vocabulary. There’s an assumption that when two people communicate, they are talking within the same context. This table was created as the vocabulary to be used within the specific organization I was working with and all of these were considered to be “CM” by the person relating their needs to me.
The important part is not to have industry definitions but to have organizational definitions that everyone within the organization can understand and use. That’s where a business architect can provide immediate and very visible results. Table 1 is the agreed upon listing of all change management and configuration management terms used by the entire organization.
Table 1- Example Vocabulary for Entire Organization
|
Change Management Vocabulary |
||
|
Term |
Context |
Definition |
|
Version Control |
Software/Documents |
A process of controlling the contents of an item under development. In software, it tends to be at the file level. Developers check out and check in a file that represents a component of the overall package. The controlled item may or may not become part of a released application. Version Control allows the developer or author to roll back to a previous version should revisions be necessary or present a version as a draft or release candidate. |
|
Configuration Management |
Systems/Products |
Configuration management is not a process but an accounting of the configuration items, also known as CIs that make up a system or product. The configurations can be a combination of hardware, firmware, and software. In terms of software, it includes the Version or Build Number that makes up the current system or product, in terms of hardware; it should be the make and model of the hardware including any revision numbers. In some instances, such as aircraft it may even include hardware serial numbers. The main concept is to be able to account for each item in a delivered system or product at any given period in time. |
|
Configuration Change Management |
Systems/Products |
Configuration Change Management is the process for creating multiple configurations of a system or product. Each change to a configuration must maintain a method for identifying which configuration is in place for each system or product. Configuration Change Management provides an auditable trail that relates each system or product to the current configuration and access to the history that determines previous configurations and when the configuration was changed. |
|
Project Change Management |
Project Portfolio/ Project Management |
Project Change Management is the process for managing change during a project’s lifecycle up to deployment and closeout. Project Change Management deals with the aspects of change to scope, cost and schedule of the in-flight projects. The changes that are a part of project change management involve the project manager, project team, sponsor and stakeholders. |
|
Engineering Change Management |
Operations/ Sustainment |
Engineering Change Management is the process for managing change of a deployed application, product or service to correct problems, add additional capability or take advantage of a new opportunity. Where projects are temporal with a definite beginning and end, sustainment relates to the ongoing operational aspects. Engineering Change Management has a governance board to oversee the changes and make a determination to implement the change via the sustainment activity or spawn a project and a new project team. |
|
Business Process Change Management |
Operations |
Generally, these are changes to the way people were doing things, whatever those things were. This is the area where Six Sigma and Lean are the common tools for identifying and implementing the changes. |
|
Policy Change Management |
Governance |
Typically involves compliance and or legal review. Predicated on new laws or changes to existing policies. |
|
Organizational Change Management |
Strategy, Goals, Mission |
Sometimes also called reorganization. These changes are frequently exercised during mergers and acquisitions, C-Level leadership changes or major changes in the industry – typically caused by outside influences. |
When everyone in the organization can understand what another group within the organization is talking about, communication happens. With a vocabulary in hand and distributed throughout the organization, confusion gives way to a better understanding. For the organization I was working with, they quickly focused on weaknesses in configuration change management as the source of numerous problems and quickly put in place a solution. While your organization’s definitions may not reflect other’s definitions, the key is that everyone in your organization understand your definition.
