How to initialise and control your IT documentation projects

Documentation projects pose new challenges for both those responsible for and those involved in the project. On one hand, the IT asset management should be improved, while on the other hand, the effort for IT documentation needs to be reduced. Processes also have to be changed significantly, although this is often forgotten. In this article we would like to provide you with recommendations about how to implement your documentation project, so that this can be done successfully and without incurring any delays.

Errors in documentation projects

One of the most common mistakes in such projects is that nobody declares that it is a project, even though:

• new processes need to be created
• existing processes need to be adapted
• existing data needs to be migrated
• additional systems need to be connected

There is also a considerable degree of automation that should be achieved.

Agile documentation projects always result in the same problematic conclusion. Every employee documents individually, as they think is “right”. As a result, information that is urgently needed for various processes is often missing. One of the greatest problems is that often nobody feels responsible for the documentation. This results in documentation being either created very late or, in the worst case scenario, not at all. In the long run, this means you will have documentation that you simply cannot trust because it is incomplete. You should take steps to counteract this in good time.

Our tip: Make it a project and treat it as such.

As-is analysis and definition of objectives

The first step is for you and your project team to agree on the following points:

• What is the current status of your IT documentation?
• What do you want to achieve with this project?
• Is it about improving the quality of documentation?
• In the future, would you like your employees to be relieved?
• Do you want to reduce the documentation effort by automatically transferring data to the IT documentation?
• Would you like to be able to link systems to contracts, persons and organisations in the future and to show the relationships/dependencies?

All these questions must be clarified in advance, otherwise you won’t even be able to assess the scope of your project.

In the best way possible, describe exactly what you want to achieve with this project and discuss it with your project team. This creates complete transparency. At the same time it also increases how accepting the participants will be of the project, because they are involved from the very beginning.

For the project, it is not only important to think about where you want to take your documentation, but more importantly, where you are at the moment. Therefore you need to get an overview of your current IT infrastructure.

• How, and more significantly, where is documentation currently being carried out?
• Is the focus on Excel tables, text files, Wiki systems or are other tools/isolated applications involved?
• If so, what possibilities do they offer for exporting data?

Formulate a precise definition of objectives

“We want complete IT documentation”. This is the wish of almost every person in a management position. Of course, at first this sounds good and completely understandable. This is however not an adequate definition of the objectives. If you ask your colleagues and employees what complete IT documentation means, you will get many different answers.

A clear standard of documentation must be defined. First of all, when will the IT documentation be complete? Secondly, what information must it contain?

These questions should be formulated as goals. The most important thing to remember is to communicate these goals to your project team in advance! Nobody likes to be presented with a “fait accompli”. You are well advised to work with your team to determine which information is really helpful in the day-to-day business. Where are the current bottlenecks, who is currently over- or underchallenged and how can you counteract this in the future?

It is advisable to further break down this goal. Proceed according to areas, e.g. server, software or clients. Formulate further goals such as “reducing documentation effort”, “relieving employees” or “improving communication”.

Formulate your goals and requirements SMART

We tend to want to define everything as specifically as possible. However, above all, goals and requirements must be: precise and understandable. For this purpose we recommend the use of the SMART formula. SMART stands for: specific, measurable, achievable, realistic and timely. But what does that really mean?

S for specific

Formulate goals concretely and precisely. “I want to document my server room” is not a precise definition of your goals. A much more specific formulation is: “I would like to record all IT components in my server room no.2 in a central IT documentation by 31.12.2020. This documentation should include rack number, manufacturer, serial number, processor model and frequency, hard disk space, main memory and software equipment including patch level”. This is the level of specificity you should aim for.

M for measurable

Anything that can be expressed in a number is usually measurable. Followingly, if you can measure it, you can also achieve it. The goal “I want to reduce the documentation effort” is not measurable. However, if you formulate it more precisely, you will have a measurable goal: “I would like to reduce the documentation effort in Q3 by 25%.

A for achievable

Even the best goals are not worth the effort if they don’t bring you any benefit. How attractive a goal is for you is synonymous with a real advantage for your company. When you remember that you have already achieved your goal, then you feel inner enthusiasm, which makes this an attractive goal.

R for realistic

Very often employees have such high benchmarks for the objectives they want to achieve, that they seem impossible to reach. This is the complete opposite of helpful. Not only do you put the motivation of those involved in the project at risk, but you also endanger the project in concrete terms. Formulate goals that can realistically be achieved. Factors such as time and resources should really be taken into consideration.

T for timely

Establish an exact time by which you should achieve your goal. This deadline has a practical use: You can see how far you have progressed in the project. And you will be able to estimate how far away you are from reaching your goal. Resist the temptation not to set an end date. You will lose an important measuring and control instrument.

SMART is hard, but still smart

Yes, this clear definition will take more time than simply doing it in an agile way. But, if you think you are saving yourself this step, remember that things will however turn out as they always do: everyone documents as they see fit and you can never achieve your goal of a uniform quality standard in this way. In addition, you can control your project much better if you can compare the progress of the project with your definition at any time.

Processes and requirements

To achieve your goals, you also need to identify the appropriate requirements. Goals determine what is to be achieved. Requirements describe what is necessary to achieve these goals. In order to make a success of this, you should clearly communicate with those involved in the project.

For this purpose, it is often helpful to take a closer look at the existing processes.

• What information is required in the event of a fault or during the rollout of a new system?
• Which persons or departments are currently involved in this process?
• Do these persons or departments need certain information or even have to provide it for IT documentation?

If you have not yet visualised your processes, it can be helpful to model them with the help of BPMN, eEPK or UML. This will enable you to adapt and streamline your processes to i-doit.

To reduce the amount of documentation as much as possible, you must limit your documentation to the information you need for your processes. Remember: all the information that you document beyond this must also be maintained continuously.

Define responsibilities for work packages and processes

Inevitably, different competences are necessary to achieve the objectives. By communicating with your project participants in the breakdown of your goals and requirements, you will already have established initial responsibilities. Nevertheless, you should always keep an eye on the workload of your employees. Just because an employee has extensive competences, their motivation can deteriorate considerably if they “have to” take over too many areas. Make sure that your employees are evenly spread and encourage them to support you.

Plan to achieve your goal

In order to reach your goal in a structured way, you can divide your project into 5 phases. Determine the current status of your IT documentation and define your goals. Describe the SMART requirements that serve to help achieve your goals. Be practical: What needs to be done to achieve these goals. Define the responsibilities for your goals and requirements. Use the respective competencies and keep an eye on the project progress and the workload of your project staff. Plan and design your processes in such a way that they are automated as far as possible and therefore relieve your employees as much as possible.

IT documentation can now do much more than just fill in lists and forms. Smart tools and suitable processes enable manual documentation to be kept to an absolute minimum.

Our tip for success, once again: make your documentation project a real “project” and implement it in a structured way.