Any Remaining tasks for the team?
Check if there are any remaining tasks for the team, for example:
- Are transition to BAU operations activities needed and if so, have they happened? If not, they need to.
- You should have a lessons learnt session and prepare the lessons learnt output either as part of separate to the Project Closure Report
- Are there points which need to be addressed which it is not practical to keep the Project going for? If so, owners need to be found to take these forward (see Closure Report below)
Roll-off Team
In many Projects your team cost money booked against the Project Budget so as you enter the Closure phase you may have already rolled off a number of the team (with maybe some call on their time for lessons learnt sessions etc). So you should look to finish the roll-off plan including you as Project Manager. Forecast the last week you will charge costs to the Project and thus you can finalise your Project spend against Budget. For other roll-off considerations see this postClosure Report
The measurement of the success of the Project has two dimensions and the Closure Report is, in part, an assessment of the Project Team dimension ("Project Performance"). The sections I would expect to see in a Closure Report are:- Background, key objectives and summary of Business Case (links to documents with more detail).
- Summary of Project Approach adopted.
- Key Products delivered including purpose, version status and links to location in the Project File.
- Team Member details (the BAU team may want to confirm a point of detail at some time in the future).
- Performance - Time. Table showing key milestones (ideally those published in the Project Definition augmented by any added during the Project), the Baseline date and the Actual date achieved with comments as appropriate. Normally there is one or several primary milestones defined in the Project Definition objective, these should be highlighted (e.g. in IT Projects it might be Production System Release Date(s)).
- Performance - Scope. Was the baseline Scope delivered or was some of the scope removed or potentially additional scope delivered (identified via Change Control)?
- Performance - Quality. Quality metrics should support any statements, for example in IT Projects this might be the number of Post go live "warranty incidents" which needed resolving.
- Performance - Costs. Comparison of actual costs spent versus the baseline in the Project Definition.
- Performance - Benefit Case. Has the benefit case changed at all through the Project life-cycle?
- Change Management - was what the effect of Change Requests during the Project life-cycle (link to Change Log)
- Risk Summary - are there any open risks to be monitored by BAU Operations?
- Issue Summary - are there any open issues to be resolved by BAU Operations?
- Post Project activities - this is an important section stating activities which need to be completed post Project closure and who owns these actions. Ideally this list will be policed by some residual body such as a PMO. An examples might be Benefit Realisation steps / checkpoints .
- Summary of key lessons learnt with a link to the full report
What about the Benefit Realisation?
The other dimension of Project success is reaching the target benefits and these typically are realised post closure of the Project. Hopefully it is clear who is accountable for these and when they will be reported (and who will this report go to). See my post of Benefit Realisation
Project Celebration
Hopefully you have had a successful Project and have a happy Sponsor. Ideally there is sufficient Project budget (or raid a BAU budget) to allow for a celebration event for the Project team. Discuss this with your Sponsor to agree the format, formal or informal, does the Sponsor want to make a speech etc?
1 Comments
Excellent key points - I will keep a copy of this
ReplyDelete