Are you planning for Quality with your Project documents?

Most projects have a myriad of documents produced both Management and Specialist (Technical). If you don't plan and execute proper quality processes for these documents, your project will not have a secure platform for success. A draft document hasn't been reviewed and agreed as fit for purpose so may not be correct and subject to change at any time. In contrast, if the document has been reviewed and approved as being fit for purpose it is a firm foundation to execute the project towards a successful conclusion.

Apologies in advance, this post is longer than my normal length which just goes to show that achieving good quality fully approved documents isn't easy!!

I have previously spoken about planning and estimating as key activities to undertake and the PRINCE2 Product based Planning technique is a good place to commence with your planning. I then recommend that you produce a Quality Plan for all Products produced by the Project and build those quality processes into your schedule. In this post I am focusing on documents but the same principles apply for non document products.

Terminology - "Draft issued", "Approved", "Baselined" document status

Let us start by defining some terms I will use....

• Draft issued - the document has been drafted and been submitted into the quality assurance process in line with the Quality Plan
• Approved - approval evidence received from all approvers for a document
• Baselined - document version is designated as a baseline version. It should only be changed as a result of a Change Request or a true error i.e.  Off-specification. 

Now you are probably thinking what is the difference between "Approved" and "Baselined". Normally you achieved Approved to achieve Baselined but not always! I reserve the right to Baseline a document which isn't fully approved. I tackle Project Management tips around the challenge of not achieving document signoffs in good time here.

Quality Plan

So you have identified your PRINCE2 Management and Specialist products, Product Breakdown Structure and Product Flow Diagram (if necessary). In line with your schedule you can populate your Quality Plan which I tend to maintain in a spreadsheet. Below is an extract of some columns from an old project in 2004.

The key fields of the Quality Plan document (not all shown in the extract):

1. Product name (Product = Document)
2. Product Status - one of the following "Not started", "Being Drafted", "Draft Issued" (for review), "Partially Approved", "Baselined"
3. Product Version - 0.1, 0.2 etc are drafts, 1.0, 2.0 are baselines (so in the example above the PID was on a second baseline)
4. Author - this person is responsible for putting together the document, issuing for review, updating from review, obtaining approval evidence, reporting status to the Project Manager
5. Purpose of Product / Comments on status
6. Quality Process (see below)
7. Approvers - either a list of approvers and why (the thinking behind who needs to assure quality). Ideally an approver will be part of the review process. Sometimes I will ask a senior manager to approve based on reviews undertaken by a number of staff who report into the senior manager. I'm not keen on "approval based on status in organisation" unless it aids quality in some way!!!
8. A series of dates which there wasn't room to represent in the example. These are Draft Issued Plan / Draft Issued Forecast / Draft Issued Actual / Issued Days Late (calculated from either Forecast or Actual) and the same repeated for Approved

Quality Process - Review by Circulation

This is the most often used but is the weakest document quality process. It is weak because for the reviewer / approver it is typically adhoc work beyond the planned activities to be "fitted in" and human nature means that many people will de-prioritise this or ignore it due to volume of email traffic  or skimp in the review when up against a deadline. 

So you, like me, will probably use this a lot but please acknowledge it's shortcomings (and pick which documents you really need something better) and at least put in effort to chase for comments. Negative Option reviewing (i.e. no reply = "it must be OK") is a classic failing and one to be avoided.

Some suggestions to get the best out of this quality process are:

1. Ensure the document author takes ownership for achieving these suggested points
2. Pick your reviewers carefully - who will add value to the quality process versus those you are just effectively notifying about a document?
3. When a document is sent for formal review (rather than some pre-review with a trusted peer reviewer), please include all reviewers and approvers in the email. Be clear in bold and early in the email on the expected time-scales for review and feedback. Be sensible, don't send a 100 page document and ask for feedback the next day (see scheduling)
4. Explain how you want feedback. Are you happy for email, updates / comments actually in a copy of the document forwarded back or do you want to send out a template for comments which means everyone's comments are in the same format? I personally like the latter approach and have a template where the reviewer designates a severity to each comment from critical to cosmetic
5. When processing the feedback, make changes to the document with tracked changes against the draft version sent out. If you don't make the change suggested, you need to dialogue with the reviewer as to why (for completeness, the feedback template has a "actioned" column which can be marked and the feedback returned to each reviewer)
6. Note in the document (within the table of reviewers) who has reviewed and who hasn't.
7. You may need to chase for feedback from those you expect to sign-off 
8. Once all feedback has been assessed and processed, the revised document (with tracked changes) can be issued for sign-off by the approvers. Once again, the author will need to set a target date for approval evidence to be received
9. Typically the author will then need to chase for these approvals. At some point the author may need to escalate to the Project Manager to chase for approvals as a second line. Some people don't like to make the "commitment" of signing off documents, some are sneaky and feel that a draft document allows them to make future changes. Don't let this happen. I will use every attempt to solicit an approval (or a reasonable reason why the approval can't be given) but there have been occasions where I have said "tough, we are base-lining the document without your approval"

You might also want to read a separate post where I have covered some other tips to improve the "review by circulation" quality method.

Quality Process - Walkthrough Review

Walkthrough Reviews come in various shapes, sizes and processes, here I will deal in generalities. The bottom line is that a Walkthrough Review should typically give a better quality review than Review by Circulation. If you want to read more on the subject, I have used the Fagan Review process within IT Projects.

In simple terms the author issues the document in advance but the reviewers gather in a room and the author walks through the document and people feed in comments and discuss. I would say in general terms the review is better because:

• reviewers are locked away and forced to spend the time to review (if they haven't done in advance which is the ideal)
• discussion between reviewers can help bounce thoughts around to get to a better conclusion which can then be documented

Schedule aspects of Planning for Quality

You need to factor in these Quality Assurance processes into your schedule. In simple terms I have a two step plan with a couple of milestones in the schedule:

• Task 1 - the time for the author to get to a GOOD draft of the document which is ready to be Quality Assured. If the author isn't confident and wants a peer review first, this needs to be built into the estimate
• Milestone 1 - Draft issued (when the email has been sent with the link to the document being reviewed, this milestone has been met)
• Task 2 - Quality Assurance process (what ever it is in line with the Quality Plan). This includes dealing with the feedback, issuing a second draft for signoff and chasing down the approval emails. The author may not be working full time in this period but I never tend to plan less than 10 days elapsed here. If you are using Walkthrough Reviews, encourage the author to get the meetings in people's diaries well ahead of time
• Milestone 2 - Document baselined - all sign emails received and embedded in the document

These milestones can then be baselined and through monitoring, provide a useful means of measuring progress especially in a Waterfall type project life-cycle.

Conclusion

As part of your Planning and Estimating activities ensure you produce a Quality Plan for your documents (and other PRINCE2 products), considering how you will Quality Assure them before Baselining them. This effort which is non trivial needs to be built into your Project schedule.