First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Monday, 24 November 2014

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!!
Quality Assured Documents give a more secure Project platform
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, often because there is a tricky customer who thinks that by not signing off documents he/she can change his mind at any stage. Sorry, I'm not having that!! Of course such an action creates a Risk but better that than lack of progress or certainty on downstream document production. Of course, before taking such a course of action I will have chased a number of times for sign-off or a reason why it can't be signed off. I'm afraid that is just a fact of life, you are unlikely to get sign-off emails without some chasing. So plan for it!

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.
Example Project Document Quality Plan
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
Walk-through for the finest Quality

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.

Monday, 10 November 2014

Every Assumption is a Risk so Manage them!

As you undertake Planning and Estimating you are likely to need to make some assumptions and on occasions, you may need to make a lot of assumptions. Every Assumption should be considered a Risk (that it is incorrect) so you should be active in logging them and closing them down as soon as possible during the Project life-cycle. As I have previously said, Attack the Risks before the Risks attack you!
Every Project Assumption is a Risk

Log your Assumptions as you undertake Planning

As you plan you should document any assumptions you need to make to complete the plan. These can be significant assumptions fundamental to the plan being adopted or quite low level detailed ones.

You should have an Assumption Log, I typically have a separate sheet within an Excel RAIDs workbook. It should be located in the central Project File e.g. on SharePointHere is an extract from a closed Project within a Programme structure (so I introduced a Programme wide log with a Project column).


Project Assumptions Log

Validating your Assumptions

You should validate your Assumptions firstly with your Project team and especially for more fundamental ones, with your Sponsor / Project Board through your Project definition document.

I show any fundamental Assumptions within the body of the definition document and I often put the rest in an Appendix.

Every Assumption is a Risk

Every Assumption could be incorrect and thus affect the Plan. Therefore every Assumption is a Risk. I will log significant ones as specific entries in the Risk Log. As an illustration, here is the detail of the Risk I raised against Assumption #22 for the 11g Project shown above:
  • Description - Jmeter POC is not successful and scripts are not delivered as planned (Ass 22)
  • Impact - Delay if need to evaluate a different tool
  • Management - Accept. Contingency is manual testing, keep going with Jmeter with known deficiencies or stop & evaluate another tool
For the lower level assumptions, I typically have a catch all Risk along the lines of Assumption not specifically raised as a Risk is found to be incorrect

Monitor and close Assumptions and associated Risks as soon as possible

As I have stated in a previous post, Attack the Risks before the Risks attack you!. So look to confirm your Assumptions as soon as possible during the Project life-cycle and through regular review of your RAIDs, close off Assumptions and Risks entries as appropriate.

Conclusion

To produce a Plan is likely to require one or many Assumptions. Any Assumption represents a Risk to the Project as it may be incorrect. Therefore Assumptions should be logged, validated and actively managed until all are closed.

Twitter Delicious Facebook Digg Stumbleupon Favorites More