IT Process Documentation – A Necessary Evil?

With increasing requirements of compliance and a greater need for governance at all levels, process documentation has become very important for organizations. Documentation could be in terms of product catalogues, training manuals, evidences etc or process documentation. For the purpose of this blog, let’s restrict ourselves to IT process documentation. Many an old organization has very little in terms of documented processes but have very effective process that is being well followed. On the other hand, with the IT boom, and a more tech savvy workforce, there are organizations that have the fanciest of process documentation but have failed at implementing even small parts of it. Which brings up the question, till what level should you document and what all should you document. While there is no clear definition for this some factors that could be considered are

What is the objective: This should be the most crucial factor while deciding to document any process. Is the organization documenting processes only cause the CIO has heard “process Documentation” as the new buzz word, or do they really feel the need to achieve something at the end of the exercise. The end objective could be to identify process improvements, ensure that future trainings are better conducted or simply to meet a mandatory requirement. However this needs to be known prior to undertaking the initiative. The objective will also cover the depth of the documentation as well. Is the objective to ensure that IT processes are robust across all entities for a big organization?  How much leeway will be provided for local IT teams to have their own policies while being covered in some aspects by a global policy?

In most cases, it is highly recommended to document as much as possible so that processes become more standardized leaving little scope for ambiguity and assisting in future trainings. However the scope of the documentation also needs to be clearly defined. Like mentioned earlier

Who will document: Another key factor that needs to be considered is who will ultimately be responsible for the documentation. Ideally the organization (depending on its size) can identify key resources from each of the target areas to assist in the documentation. They can also hire external consultants who can assist in the documentation. However there will have to be an internal team that can provide inputs for the process documentation to be built. Hiring external consultants will also have a cost implication and hence this also needs to be factored in. The advantage of an external consultant is that they could be well versed with standards like ITIL / COBIT and could provide key pointers to make the documentation more robust. 

Get Internal Buy In: Many IT teams may tend to look at the entire documentation as a waste of time and effort. This may be especially true in case of personnel who are already part of the process and are very well versed with it. There may be a tendency to look at the documentation as an extra burden with no value adds. It is important to get buy in from all the people who will be associated with the documentation initiative and also help them identify why it is being done. Also it will be extremely helpful to point out the benefits to them so that participation is more willing. There could also be extra incentives in terms of monetary or non monetary benefits that could be offered especially if documentation is being done by internal teams.

Organizational Culture: While this may seem to be a little out of place while referring to documentation it does play an important role. This is truer when it comes to maintenance of the process documentation built. Process documentation cannot be a onetime activity. It needs to be reviewed at periodic intervals an updated to ensure that the objectives are still being met. This is where the organization culture plays a key role. In most cases for smaller organizations documentation may not add much value and hence tends to get ignored. Issues are resolved mostly by a “tap over the shoulder” approach and tools etc are not used. This is where the top level management needs to have a firm belief in the objectives of the documentation and provide a regular impetus to the teams to use the documentation and ensure its maintenance.

The advantages of have a robust documentation are many, from meeting compliance requirements to ensuring process robustness and efficiency. What an organization wants to focus on will depend on their internal requirements.

About Author:

Amol Bhembre is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: amol.b@spluspl.com