It was in 1975 that the concept of a “paperless office” was first conceived, and thirty-plus years later most of us are starting to make real strides towards this.  But moving towards being paperless doesn’t mean that we move away from documentation.  In fact, it seems the opposite!  

Through our work, most of us are drowned in documentation on a daily basis – we receive drafts, initial release versions, updates, amendments … at some stage we hopefully receive a “final” copy, but soon discover that the final is replaced with version 1.1 and the documents just keep on rolling in…

With all these documents flooding our inbox, its easy to skip a few in the hope that you can save precious hours (or work more efficiently).  My general response to this is:  Be careful!

All software professionals know that the cost of rework is exponentially higher than implementing the correct solution the first time round, and documentation forms an important step in the design process to ensure that the correct solution is built.  

Now, documentation doesn’t necessarily come in the form of Word documents of PDF’s – it encompasses all forms from presentations to screen shots, diagrams, whiteboard sessions, email conversations, IM’s, and the plethora of other available communication tools – all of them as important as the next.  And they all have one thing in common: They are trying to convey a message.  This message is important, and you should apply your mind to all these messages.  There are too many experiences where a document isn’t correctly reviewed, a solution is delivered based on the document, and issues are discovered only once something has been built.  This is too late.

All projects & tasks, irrespective of size, need some form of documentation to support the work, and the documentation needs to be reviewed before anything is built.  If the task is small, an email or a IM conversation will suffice.

Some steps to keep in mind when reviewing documents:

• Have a clear idea of the final outcome – you’ll need this so that you can validate whether everything has been covered in the documentation
• Keep an eye on document versions & dates – you should always review the latest document (which is sometimes easy to overlook)
• Collate everything – as the different artefacts and versions pile up, start a collection so that you have a full history of how things progressed over time
• Lookout for changes – decipher the changes and review the changes; there’s no need to review everything if only one small portion has changed
• Keeps notes as you review – it’s easy to loose track of thought processes, so make simple notes, structure them logically, and provide feedback (where applicable) to the owner & stakeholders.