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

Thursday, 24 September 2015

Project Lessons Learnt - remembering the past to influence the future

In this post I want to discuss the topic of Lessons Learnt within Projects. In football (soccer), if a goalkeeper lets a goal in through his legs, best that he learns from this for the next match. Or as the philosopher George Santayana said, "Those who cannot remember the past are condemned to repeat it".
Projects - Those who cannot remember the past are condemned to repeat it
I want to break down this topic into 3 areas:
  • Organisational Lessons Learnt (learnings from other Projects)
  • Project Team Lessons Learnt
  • Personal Lessons Learnt

Organisational Lessons Learnt

The principle here is that while initiating a new project, the Project Manager refers to a database of previous lessons learnt in the organisation for points to build into the plan or risks to consider.

I have come across this concept a couple of times as a consultant Project Manager but have struggled to gain useful insights from the database as:
  • it is difficult to find relevant lessons
  • the lessons are not written in a way to assist a new recipient
I don't have any particularly magic answers here but if I can find a similar project in the database (e.g. dealing with the same technology stack) and the Project Manager is still in the organisation, I will make contact and have a discussion about the previous project(s) and learning points as I am more likely to get some useful insights.

Project Team Lessons Learnt

PRINCE2 speaks of having a lessons learnt log and formally updated this at various points in the Project life cycle. My approach is to have a blank notepad file with a link on my desktop which allows me to quickly update with some pointers / thoughts as I come across them during the project.

During the project close-down phase you should organise a lessons learnt meeting but I recommend that in advance of this meeting you issue out a preparation sheet for some private contemplation by each participant in advance of the meeting. My approach is to:
  • list some key information about the project performance in terms of progress against plan etc
  • have life-cycle sections for focusing thought (for example in a waterfall system development project this might be analysis, design, development, SIT, UAT, implementation etc). I always have additional sections for management and teamwork.
  • ask the team member to list a maximum of 3 positive and 3 negative lessons per life-cycle section i.e. things that went well that should be repeated and things that went less well that we should do differently next time. 
Sometimes lessons learnt meetings can be very cathartic to get rid of team angst but in terms of capturing something which can be practically applied in the next project, pretty useless. I always try and focus the meeting on what could a new project team pick up and apply from this project and the preparation sheets can help focus the meeting appropriately. Gather up the sheets and your own notes (having a separate scribe can be useful) and try and distil this into something which can usefully be applied.

The meeting can also identify some consensus on individuals who have gone beyond their normal role is helping the deliver the project. This information can be used from a simple thank you to something more substantive whether a reward handed out at the project celebration event or input into the organisational HR processes.

Personal Lessons Learnt

Whether part of your team lessons learnt or separately, you should consider what went well and what you would do differently as a Project Manager next time. Try and get some honest feedback from the team and stakeholders on your performance and how people perceived you because it is often different from what you might think. While it can be challenging to implement changes at an organisational and/or project team level it is a lot easier to implement changes at a personal level so make sure you do! 

Thursday, 10 September 2015

Improving your circulation to achieve better Quality

No, I'm not proposing that you take more exercise (although this isn't a bad idea as per my post on handling stress)!! This is concerning the Quality processes for documents created by your Project. As I previously discussed, the most common but least effective quality method for documents is "review by circulation" where the author sends out a document in an email to a list of reviewers / approvers. Hopefully the document is fully reviewed by a number of people, comments are addressed and appropriate people sign off the document to confirm it is "fit for purpose". I have observed some very poor practices with regard to this review technique so here are my suggestions for getting the very best out of it although for key documents you may want to utilise better methods.
Review by Circulation Quality method - Bad and Good

Pick your reviewers and approvers carefully

I call this Quality Planning and was introduced in my previous post on the subjectSo consider who should review the document and why, who should signoff the document and why? Very often insufficient thought is given, the author just picks some random people sometimes only based on "status" within the Organisation or Project and here is where poor quality starts.

Let me take an example from the world of IT system development. Often some sort of Functional Specification is produced to define the system behaviour. Who should review and/or approve such a document to ensure it is fit for purpose for development to commence? Here are my suggestions but rather than get too focused on the example, I hope it demonstrates the thought processes in general terms
  • is there a need for a peer review before it is formally issued out for review? This will very much depend on the skills and experience of the author.
  • does the customer agree with this specification? Therefore a key approver should be someone senior on the Project Board who represents the user base. Often this person is named the Senior User, see my post on Project ownership. However, the Senior User should name the people he/she wants to be happy with the document within the user community - these will be reviewers
  • can we develop from this specification, is it unambiguous? To address these points someone senior in the Development team should review or maybe approve with named additional reviewers as suggested
  • will the IT tools available allow this specification to be met? Does the document support organisational design principles? Some Architectural review / approval is required
  • will we be able to test against the specification? Test team leads (for various test phases) to at least review
Of course, PRINCE2 says you should be producing a Production Description (PD) for this document which defines several things including quality process. But as per my post of the subject, I think you can get away without this in many cases as long as the rationale for the PD is handled elsewhere.

All reviewers and approvers should be named in the Document Control section of the document whether Word, Excel, Powerpoint or some other authoring software.

Plan! - give time for review, updating and final approval

Most document reviewing by circulation is unplanned additional work for the reviewer that they need to fit in between other work. So you should recognise this and give a reasonable time to properly review. What is "reasonable" will in part be controlled by the size of the document, to state the obvious, 100 pages needs far more time than 5 pages!

My rule of thumb is a minimum of 10 working days to get from the issue of a good first draft (peer reviewed before issue if author is inexperienced) to achieving a baselined (fully signed off) document. This can be broken down into something like:
  • issue good first draft requesting responses by end of Day 5
  • remind people when responses are expected around end of Day 3. You might drop into the email that you will be recording who hasn't responded!
  • 2 days to address comments, have side discussions if necessary = Day 7
  • issue final draft for signoff with responses to review comments = end of Day 7 requesting signoff by end of Day 10
  • chase down approvals as necessary

Be very clear in your email and set a deadline

Emails need to be very clear, have a read on my post regarding emails within Projects in general.

So I suggest
  • put some directive text at the start of the subject line - something like "PLEASE REVIEW: Project X Functional Specification 1st draft - comments by Friday 10 Apr 2015"
  • ideally have a link to the document in your Project File rather than attach the document but ensure that the reviewers have access to the respository
  • introduce the document context and the need for review comments
  • set out the plan (briefly!) to get to a fully signed off document and thus the importance of the deadline for initial responses state in bold and say that if responses aren't received in this timescale, your responses cannot be incorporated in the draft issued for signoff and that this will represent a risk to the Project

Send out a review comment template with your document and be rigorous in updating and sending out

I recommend issuing out a simple spreadsheet based review comment template with the document and request that all comments are returned using the template - see example below. 

Example Review by Circulation Comment spreadsheet
Review by Circulation Comment Template with author responses

The various comments can be combined into a master comment tracker spreadsheet. The comment tracker is then used by the author to methodically work through the comments and make a decision whether or not to modify the document as requested and the tracker can be updated accordingly. This tracker is then sent back either individually to reviewers or I prefer to send out to everyone as part of issuing the document for signoff. 

Track Reviews - "Name and Shame" strategy

The people who have supplied review comments are noted in the document and also the people who have not provided any response. Although this is good to note, even better for know that this will happen so that it encourages responses. 

Use Tracked Changes in the document after first issue

Once you have issued out a first draft for formal review, please track any changes in the document if this is possible. This will minimise the effort for reviewers and approvers to see that their review points have been addressed.

Chase down the Approvals

Be prepared to chase down approvals. Some people are busy, some people have too many emails, some people don't want to commit and some people think that by not signing off they can change their minds in the future. Every day past the planned date for baselining the document is a risk to the Project so chase down the approvals. You may even need to threaten to throw a punch!


If you have a really critical document pick a more effective quality process such as a Walkthrough review. But there will be a number of documents in your Project that you will choose to use the "Review by Circulation" quality method for. In such cases, careful planning and the use of specific techniques will give you the best quality document baselined on time.

Twitter Delicious Facebook Digg Stumbleupon Favorites More