How do i start documenting?#

Often people consult us with the following questions or similar considerations:

If I don’t have any IT documentation yet: What is the best way to start?
With how many details do I begin?
Which area do I cover first: Clients and servers? Buildings and rooms? The network?
How many categories do I have to cover to get a good overview?
…

Anyone who deals with the subject of IT documentation in depth will recognize quickly that here as well as elsewhere the following applies: The first step is always the hardest. In this article we would like to map out what the reasons for these questions are and how we can answer them in an optimal way.

Take a look at our whitepapers as well.

Know your Requirements#

It is not by chance that people deal with the subject of IT documentation. It doesn’t work on its own and doesn’t serve as an end in itself. Either the request to establish IT documentation in the IT organization is made by the IT department itself, by more senior levels, by the management or from the outside (compliance). Before you deal with tools like i-doit the following issues should be clarified: What targets do you want to achieve or support with the IT documentation? Have the administrators lost track of the infrastructure? Does the management want to specify (IT) services to be offered to in-house departments and/ or to customers? Are there laws, standards or guidelines which stipulate that there has to be IT documentation?

There are various approaches: Top down describes that the requirements are broken down in a process from top to bottom. This also applies to the documentation: Before you elaborate on details of single IT components you map out the bigger picture. Bottom up is the counterpart: Based on a detailed infrastructure you can model services, assign maintenance contracts or create disaster recovery plans. But to some extent the requirements come from all sides at the same time. So before you document even one IP address or read out a server specification, you should channel these requirements and bring them into well-considered structures.

Know your Users#

One of the most important questions is: Who works with the IT documentation? Who benefits from the documentation? Both in small and in large IT organizations it makes sense to set up a documentation team which jointly deals with all questions arising around the subject. Often there is a documentation manager in the team who coordinates all processes concerning the IT documentation. Additionally, there usually is a person from the managerial level who operates as a sponsor and supplies resources (time and money) in order to bring the introduction of IT documentation to successful fruition. Moreover, there are various other persons who actively help to shape the IT documentation or passively use it for their own purposes.

Know your Existing Documentation#

Seldom is it the case that you really start from scratch. At a rough estimate approximately 100 percent of our customers use the rival product of i-doit called Excel. Lists of IP addresses, lists of rooms and contacts, rack plans … we have seen it all documented in a two-dimensional form. Perhaps you also have other specialized tools which create the current ITSM landscape. Do you want them to be replaced by i-doit? Can collected data be reused? Are there exports or interfaces? In this context, data integration is an important keyword.

But in each case you have to come to a decision: Do you have to enter the data manually or can they be processed automatically?

Know your IT#

Let’s start with a quote:

You only see what you know.

Does this sound familiar? You are right; this is a quote by Johann Wolfgang von Goethe. In connection with this article it means that administration and management will find it difficult to keep an overview of the IT infrastructure without a documentation which is in sufficient detail and up-to-date.

In this context, the aim is to bridge the gap between richness of detail and abstraction. When you have to decide whether new information should be included in the IT documentation or not, ask yourself the following question: What would be the advantages if those details were laid down in black and white, maintained and made available for others? Documentation which is too detailed bears the risk of becoming too much for the reader and seems to be unusable. Does every cable in the computer center have to be recorded with details about length and color? Or is it sufficient to record the port connections between active network components?

Many of our customers start with the listing of locations (buildings, rooms, racks) to map server and network infrastructures. Then the next various steps follow quickly: software and services, clients and workstations, passive components (patch panels and cables).

Ergo: Each project has a defined beginning and a defined end. In between there can and should be milestones which are achievable in practice. Of course, the same applies to the introduction of IT documentation. Which items are given a high priority; which items have a low priority?

Know your Processes#

IT documentation is only sustainable when it is always kept up to date and deeply rooted in the working processes of your employees. Only information which is up-to-date is useful. In any case you should avoid outdated or wrong information. Before you “flip the switch” and implement your IT documentation in live operation, you should identify all processes where IT documentation is relevant. An example: When i-doit is incorporated into the complete life cycle of an IT component, starting with planning, purchasing, putting into operation until disposal, it has crucial consequences for many processes (and other tools). In this connection we speak of a “leading system”.

Take your Time#

You don’t start with IT documentation tomorrow and expect to be ready the day after. It takes time to answer the questions of who documents when, what and how. In smaller organizations it can be faster than in larger ones until the IT documentation can go live. Several weeks or months are rather the rule than the exception. You should pay attention to the well-known magical triangle from the area of project management. Here the key points are cost, quality and time. Within the triangle is the project. Now the project manager can decide which two of the three corners of the triangle he wants to reach. To reach all three corners of the triangle at the same time is often very hard or even impossible. We suggest not striving for the 100 per cent mark at the beginning but instead only for 80 per cent with special attention to a high-quality.

Document your Documentation#

There’s no way around it to write down the things which are important for IT documentation: How is the design of the IT documentation? Which processes are defined? Therefore, it is a good idea to maintain a Wiki with the very same information beside i-doit. Fortunately, a Wiki or document management system is already present in most of the cases and thus can be used for this purpose.

Think Outside the Box#

Those who seek inspiration or want to draw on a reservoir of experiences don’t need to look further. Beside regional user meetings and nationwide user conferences we offer many contact points where you can exchange views and experiences concerning i-doit and IT documentation.

And when a strong (service) partner is required, we and our partners offer workshops and packages etc. which are ideally suited for the starting phase with i–doit.

Bottom Line#

"So where do I start now?" It’s not quite easy to answer this question. Otherwise we could have spared you with elaborating on this subject.

In fact the answer depends on many factors which have to be observed. Every IT organization and infrastructure is different and is subject to a good degree of dynamic. Therefor we can’t give you a general answer. It is and will always remain an individual task to implement IT documentation. Feel free to contact us! We’re happy to help you!