A large part of working on software projects at Fortune 1000 companies is the documentation mountain that can sometimes arise. This can be a necessity in order to provide information for future support staff and accountability, or it can be a time intensive and largely senseless endeavor. Often times, as with many things, it can be both.
In my recent experience working on a medium-sized project for a fortune 1000 company I encountered that the IT documentation that needed to be generated was almost exclusively viewed with disdain. To some extent this is to be expected, since individuals ranging from software developers to business analysts and project managers often feel that their time can be used more effectively. Frequently that is indeed the case, as much of the IT documentation is “checking a box” on a document that will never again be viewed. However, it is not all a matter of going through the motions in order to just reach the next stage of your project—the fact that teams view documentation in this way is largely a failure of the IT governance organization.
At the most recent organization I worked with there were over 95 potential IT documents that could’ve been generated, we were able to do roughly half that amount. However, even our relatively low number of documents—at an average of 4-5 hours a piece (creation only)— turns into a full month of effort in terms of work hours and even more when you factor in having documents reviewed and signatures obtained.
Generally this is the result of IT organizations and their governance structure being built in a piecemeal manner, gradually stacking documentation on top of documentation as the organization notices more and more errors passing through. As a result, even well-meaning teams struggle to cope with the constant and seemingly endless array of documents that must be generated. Instead of letting an IT bureaucracy burgeon rampantly, IT organizations should attempt to quantify the impact of every new document or think critically about the necessity of a document and whether it will truly solve the issue at hand.
It will always be tempting to say, “Oh well the reason we weren’t aware of this earlier is because it wasn’t documented”, when in reality the issue may have easily gotten through regardless. Controlling bureaucracy is never an easy task, but, for the sanity of employees and IT governance staff, it is necessary. The healthiest step forward for organizations struggling with rapid growth in documentation is to acknowledge that not every mistake can or will be caught.
