Improving Your Project Documentation
Documentation will always be part of life for Project Managers, sometimes more than you’d like.
But how can you make sure it is useful and ultimately delivering value for your project? There are a few basics which, if you get right, will help guide you on the way to project success.
Documentation. Often a dirty word in the modern Project delivery environment, which loves to extol the virtues of approaches such as Lean and Agile. Those approaches can be extremely useful; if used appropriately, however when planning large and complex Projects then documentation will always be part of life. That documentation could be management work products created only to aid the delivery of the project (Project Brief, Communications Plan, Exception Plans etc) or an actual deliverable of the Project (Test Plan, Software Release Note, User Training Materials etc) The key is to produce effective documentation that actually adds value, and to avoid the creation of shelfware.
But how to achieve this? Below I’ve given an overview of key considerations when producing any sort of documentation as part of your Project.
Product Based Planning Approach
Firstly, adopt a “Product Based Planning” approach for your documentation, meaning identify up front and establishing it as a product of the project like any other. As such, abandon the negative label of “documentation” and instead refer to them as “Work Products.” During your initiation/startup phase, you should be aware of every single document that needs to be delivered during your Project, who for and why.
Before you try to produce any document, you should first be defining and agreeing on a description of what the work product is. This will make sure you set off down the right path, and don’t waste time creating something different from what users imagined – or that doesn’t help anyone, and truly does become shelfware. Define what format it will take, what content it will have, what information will it provide – and what it will not provide. By producing product descriptions, they can also be used as a benchmark set of “Verification Criteria” to review the Work Product against when it is produced by the Project at a later date. Ideally, your organisation will define standard work products as part of your tailored lifecycle approach, and define standard templates which automatically direct authors to meet the product description almost by default – reducing the chance for issues later.
Configuration Management Control
Your Work Product will likely go through many versions before it is finalised, and then may change yet again at a later date. The mechanism of this change needs to be understood and defined in advance because uncontrolled change could potentially have a disastrous effect on the project. If the design of a bridge was changed, but the construction team not informed, or the material order not updated, then the project will soon hit major issues. The key consideration here is to identify and define the required level of configuration control depending on the nature of the work product. For simple items which don‘t require any level of formal control (think emails etc.), we clearly shouldn’t waste time or effort, however for more important work products we should look to bring in version numbering as a minimum, recording when versions have changed and what the associated content change was. Beyond that, we would look to record who updated and approved the version changes, a communication process to inform stakeholders of changes, and in the most critical of cases a formal change control process. In this case, any change to the work product needs to be formally requested via a Change Request (CR, sometimes a Request For Change – RFC) submitted to a Change Control Board (CCB). Your organisation should define standard levels of configuration control, and then define what level of control each work product requires; do this by creating a Project or Organisational level Configuration Management Plan.
Quality Review and Approval
There’s no point the project expending effort on a work product if it doesn’t meet its original aim; that is if it is not of a required level of quality. At the planning stage, work out who needs to review and approve each work product using a peer-review process. The approach and associated logistics to work product reviews should be planned in a Project Quality Plan, covering things such as the process for the reviews, what tool will be used, timescales for reviews, etc. The draft document will be circulated to the reviewers for comment, and then once the initial review phase is complete, the author will review all comments and update the document as they see fit, and respond to each comment (were they accepted or rejected?) The document will then be circulated for a shorter second review period for reviewers to confirm that their comments have been addressed, or that they agree why they might not have; if there is further disagreement then the author and reviewer should follow up to resolve. Once the review is complete, and reviewers are happy, the final step is for them to confirm their final approval of the work product. This is especially important for key approvers who are the relevant authority or subject matter expert for your organisation – it may be a department head or regulatory body.