Posted by Michael Tapp on 1 December 2009 | 0 Comments
When you're going through the process of analysing, designing and building an IT solution of any consequence, documentation is always required. We need it for a number of reasons including:
Communication: To allow more than one person to understand the problem and work towards a solution.
IP Retention: So the decisions that have been made and the knowledge gathered or created can be "remembered".
Measurement: So metrics can be extrapolated for the purposes of measuring effort, cost etc.
Auditability: So that past decisions can be described, most often for contractual purposes.
There are other reasons as well, but by far the most important reason is communication.
What usually happens is that "documentation" is equated with "document". The result is that the information collected, collated and organised into requirements, designs, tests and so on becomes split into documents. Documents have been the primary method of formal communication for the delivery of IT solutions since IT first emerged. The question I'm asking though is, is there a better way?
I think there is. I would like to suggest that writing a document as the primary method of providing formal communication for an IT solution has a number of shortcomings. I'm not trying to suggest that documents are somehow bad - they have their place. However, what I am suggesting is that by starting with a document as the primary method of documentation, you miss huge opportunities to make your documentation much more useful and relevant.
Of course writing a document is easy. You open a word processor and start writing, anyone can do it. It's easy to put together a template with headings and styles, get people to follow the template, maybe paste in the occasional diagram. Eventually you'll complete your document, (some) people will read it and perhaps take some of it in, maybe they'll sign it off. You've done your job of creating "documentation" and everyone can point to the document and say "look we've documented our work".
The question is, after more than 50 years of people implementing IT solutions, is this really the best way for information to be captured and shared?
I'll be exploring these issues further over a series of blogs where I'll be asking the question - is there a better way to document and manage the knowledge created during the implementation of an IT solution? What do you think? I welcome your questions, comments and suggestions.
Tags:
project management,
application development,
IP retention,
documentation
