What is a configuration management plan?

Without clear goals, responsibilities and structure, the project will most likely end in delays and misplanning. The project needs to be narrowed down. The content, goals, roles and milestones should be prepared in a way that everyone can understand and brought together in one document: The Configuration Management Plan (CMP).

Core advantages through the use of a CMP:

• All open questions and definitions are clarified before implementation
• It allows the planning phase to be optimally designed
• You have a clear definition of what is to be achieved
• Project document for start-up and operation
• Planning and targeted completion of your project

The CMP should therefore basically answer the following questions:

• Which Assets and information needs to be documented?
• What are the goals to be achieved? What improvements should be made compared to the current situation?
• Who has which role and function in the project and beyond?
• How and what is documented? Do new processes have to be created or existing ones adapted?
• Which milestones in the project have been set and by when do they have to be completed?

As you can see, many questions and requirements must be identified and clarified before the planning phase. Otherwise they will come up during implementation at the latest and delay the further course of the project. The CMP is therefore the documentation of the documentation: your project file. This is where you anchor all the use cases that are to be covered.

Structured to the goal

Determine roles and functions – Who ?

Documentation needs organisation to support it. So you should create organisational framework conditions. As a rule, documentation does not write itself. You need different roles and functions for both the introduction and the later operation. You need defined responsibilities. Determine who is responsible for which area of the documentation. This is the only way to ensure accountability during the introduction and also in later operation.

Processes must be defined for operation and maintenance. These will later ensure that information not only initially finds its way into the documentation, but is also continuously maintained. Define here how you can ensure that information about changes in your IT landscape does not seep away. This data must flow into the documentation via processes. Assign people and responsibilities to these processes.

Be aware: this will incur expenses and you will have to provide the corresponding resources.

In the CMP we define the project team for the introduction and also for the later operation. As a rule, the documentation workload is higher in the introduction phase than in later operation. This must be separated and taken into account accordingly.

The project team should be involved in the project as early as possible and be involved in defining the objectives. The stakeholders know what the important requirements are for the solution and are thus involved in the decision-making process at an early stage. This increases the acceptance of the project. When introducing a new solution that is to be used by everyone later, it is important that all users feel “picked up”!

Recording and maintaining systems and information – How?

At the beginning of the project, you should determine how the collection of information should take place. Here you define important basics that you need for the implementation.

Important standards are, for example:

Definition of a naming scheme

When naming objects, care should be taken to ensure that there is no ambiguity. Do you want to include floors in buildings in the documentation and have several buildings in the company? Then it is not helpful if every first floor of the different buildings is called “Floor 1”. A name like “G01E01”, on the other hand, says much more.

The development of one or more schemes is useful. Please note: the definition should be completed in the planning phase.

Inventory

If you do not yet use an inventory tool, the CMP should define how the inventory process should work:

• Locating the units
• Inventory process
• Information to be printed on a label
• Persons responsible for the individual (or all) tasks
• Inclusion in the documentation

Create clear guidelines. This lays the foundation for a uniform and complete data situation.

Life cycle

Also determine when data will find its way into the documentation in the future. This can already happen in the planning phase, in the ordering process or even during commissioning. Just as important is the answer to the question of how to deal with the documentation data if, for example, equipment is taken out of service. Think about this at an early stage. What must the information flow look like in order to implement your requirements? How should the life cycle of your documentation data be implemented?

Determine the scope of the documentation – What?

Sift through and define information

As a rule, you do not start from scratch. You already have existing sources of information that you can sift through, evaluate and use within the project.

What documentation is already available?

Assess the quality of the existing data and whether it is useful. What about accuracy and timeliness? If the data is outdated or inaccurate, refrain from taking it over directly.

Is the information in the correct format?

Different spellings, incomplete lists or unstructured data must be revised, adapted and made importable before being transferred to the documentation. Here you should make sure that your naming scheme is applied.

Integrate third-party applications

Define possible external data sources. For example, if you already use an asset tool that contains current inventory data, you should define whether and how you want to use this information. From manual transfer to integration via an interface, there are many ways to design the information flow.

Simple Excel lists can be imported and replaced. Systems that hold asset data can still be used via existing interfaces. If you are replacing systems through the project, the CMP is about data transfer. If, on the other hand, these systems are to continue to be used, it is a matter of defining the interfaces and the flow direction of the information. If several systems hold the same data in parallel, then you should determine which is the leading system. This then becomes the source to supply the other systems with data.

What should be documented?

Determine in detail which object types are needed and which categories should be used for them. When defining the scope of the documentation, you should always pay close attention to your objectives and use cases. Goals and use cases tell you exactly what information you need. Based on your prioritisation, start with the important topics, then the “nice to have”.

Here, at the latest, you determine exactly how the objects are to be defined. Which information fields in the categories should be filled with which data? Where does this information come from? Is there a process that ensures manual filling or is an interface used that provides data automatically?

Last but not least, you should also estimate the effort required for the initial procurement of the information and its long-term maintenance. The documentation should generate as little effort as possible during operation and have a high benefit. This ensures acceptance by the users and a successful introduction.

Set milestones

Now you have defined all the objectives, prioritised them and compared them with use cases. You know what and how you want to document. Now is the time to draw up a precise project schedule with milestones.

Take small and manageable steps here. Ensure the necessary commitments with defined goals and fixed deadlines. Each work package should be assigned to a responsible person. Regularly check the progress of the project and maintain open communication with those involved.

Configuration Management Plan for successful projects