A CMDB project is usually more extensive than most professionals and managers assume at first. In addition to determining the scope of the documentation, it is necessary to clearly define which goals you want to achieve. How should documentation be done in the future? Which processes need to be adapted or newly developed?
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:
The CMP should therefore basically answer the following questions:
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.
It is useful to question your motivation at the beginning of the project:
Central IT documentation should primarily minimise delays in processes and improve the quality of the data. So those areas are particularly decisive in which – according to the current status – information has to be searched for frequently or colleagues have to be consulted.
The reasons for delays can be completely different. The required information is not found, direct access to systems is not possible or information is unsorted on various network drives. Sometimes the information is only in the heads of individual specialists. This information must also be collected centrally in a solution that is available to all.
The goals of the project primarily result from the problems you want to solve through the documentation. These problems should be questioned exactly at the beginning of the project. From these, define your use cases and their solutions. Also set a priority for all your goals. In this way, you will later determine the order in which they can be implemented. Important problems first, “nice to have” later.
The principle is: “All the information in a documentation generates a benefit”.
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”!
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:
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?
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.
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.
Without the definitions in the CMP, your staff will probably document as they see fit. However, the goal must be a uniform standard that everyone can follow. In addition to specifying which information is documented, you should also specify “how”. Clearly defined processes give those involved in the project additional confidence in dealing with the software.
Our experience has shown one thing: Every minute invested in the definition and planning of a project is saved in the implementation.
Configuration Management Plan – doITbetter Whitepaper
Before you start with your IT documentation, you should plan carefully. Every minute you invest in this phase will be recovered several times over during the project. But what is the best way to proceed? And why is careful planning important? Find out in this whitepaper.