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.
One of the most common mistakes in such projects is that nobody declares that it is a project, even though:
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.
The first step is for you and your project team to agree on the following points:
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.
“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”.
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.
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.
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.
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.
BPMN
A system of symbols to graphically represent business processes. The “Business Process Model and Notation” is mainly used in business informatics and process management. The system was developed by IBM from 2001 onwards.
eEPK
The Event Driven Process Chain () is a modelling language to graphically represent the business processes of an organisation. The extended form () adds the representation of information objects that provide or store data to the very simple system.
UML
The “Unified Modeling Language” is the best known system for graphically representing procedures and processes, especially in computer science. The very complex and extensive language is also described by the International Organisation for Standardisation in the standard ISO/IEC 19505.
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.
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.
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.