Project Management Book

"If at first you don't succeed remove all evidence you ever tried."

Chapter 13 - Stage and Project End

And now, the end is near... and no doubt you did it your way. But could others learn from your travelling of each and every highway?

There are three ends to be neatly wrapped up:


At the end of each project stage

Let's see if you have been paying attention: when you produce a deliverable such as a user functions design document how do you know who has to sign it off?

At the start of the stage you agreed who would sign off the stage deliverables and you documented that in the stage agreement. People reviewing and signing things off should be subject to the same project disciplines as any member of the project team: if they agree to sign off within two weeks of publication, the project manager should make sure they do. Also, if they agreed at the start of the stage they'd sign something off it's more likely they will be involved during the stage and as a result one hopes there will be fewer problems and surprises at the end.


Team lessons learned meeting

Sometimes known as a team post mortem, hold a team lessons learned meeting at the end of each stage. Typically this is done the week after the 'real work' of the stage has finished, in the tidy up period. It may only be a 2 hour meeting but put it in as a task in each person's plan otherwise it may not happen.

Some say the project manager should not attend. We want the team to confess their sins - the project manager's presence might inhibit that - so the team leader may be the right person to run the meeting. The whole team should be represented or preferably present. Ask them to come prepared to articulate what went wrong and how similar problems could be avoided next time. But also have them think about what they did really well and how we might ensure those successes are repeated next time.

The chairman will need to be careful that the meeting does not become a witch hunt - spending 2 hours vilifying an absent third party may be fun but doesn't really help. It's all about what we can do better next time. Emerge from the meeting with an action plan lest the good intentions evaporate.

An example. The team conclude that a lot of time was wasted during the design stage because they didn't have a clear idea at the outset how the UFD document would be structured. Someone is actioned to put together a template detailing what should go into each UFD chapter in future projects.

If the project manager isn't present at the meeting the team leader would run through the conclusions with him.

It is important to do this at the end of each project stage: if you leave it and only do it once at the very end of the whole project you will long since have forgotten what happened in the early stages.

Some advocate you shouldn't even leave it unil the end of the stage: have a lessons learned log that is continually updated as you go along as well as having the post mortem meeting at the end of the stage.


Share experience

Your natural generosity of spirit might incline you, as project manager, to share your experience with other project managers simply by going and talking to them or by making a presentation at the next project managers' forum (if you have such things).

However, project managers sometimes won't do this, and there are a couple of reasons why. The project went extremely smoothly because the project manager applied what, to him, are very obvious, common sense disciplines - so obvious, in fact, there's no point in talking about them. But of course to a novice those things aren't at all obvious. At the other extreme, the project was such a painful experience the project manager doesn't even want to think about it, let alone go around talking about it.

Either way valuable experience doesn't get shared. Which is why there is often a rule in place that at the end of each stage key data and lessons learned must be captured in a stage end report.


Stage end report

The stage end report records:

And for example the information could be recorded on a template something like this:


Stage End Report (Page 1)

Project Name:

Stage:

Project Number:

Risk Assessment:

PROJECT TYPE

 

( )  Normal Lifecycle

( )  Rapid Application Development

( )  Package Modification

( )  Maintenance Release

( )  Other:

 

TECHNOLOGY

 

( )  Java

( )  VB

( )  C++

( )  Package:

( )  Other:

 

Number of Individuals Involved:

IT TEAM:                   IT OTHER:                   USERS:

Project Manager:

Dept:

Project User Manager:

Dept:

Project IT Manager:

Dept:

Project Leader:

Dept:

Project Sponsor:

Dept:

Brief Description of Stage:

 

 

 

 

 

 

 

 

Which SER is this? (First/Interim/Last/Cancelled/Overall)

Overall: User Satisfaction (1.0 low - 5.0 high)



...next



Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk


Home   Sitemap   Contact Us   Project Management Articles   Project Management Book