« Managing Older Stakeholders
How to Capture Lessons Learned »

Closing a Project - Introduction

April 21, 2010 | Author: PM Hut | Filed under: Project Closure

Closing a Project - Introduction (#37 in the Hut Introduction to Project Management)
By JISC infoNet

A project has a beginning (Project Start-up) a middle (the iterative loop of Planning, Managing, Controlling, Reporting and Re-planning) and an end (Project Closure). This may be stating the obvious but we can probably all think of projects that have either gone on since time immemorial or simply faded away. Without senior management involvement there is no one to pull the plug on resources. Such projects enter a downward spiral in that they are seen to be a farce and soon everyone apart from the Project Manager (who feels they must carry on because they haven’t been told to bring the project to a close) stops engaging with it or taking an active part. Turning up to a meeting that no one else attends is not the way to find out a project has finished…

The project should be formally closed to ensure that:

  • The users/customers have formally accepted all outcomes
  • Operational procedures are in place
  • The handover to operational staff has been completed
  • Documentation and reference material is in place
  • Any further actions and recommendations are documented and disseminated
  • The results are disseminated to relevant people
  • There are no loose ends

Project closure can be a very hectic time when reporting is on a daily (or even more frequent) basis and the manager is working at a much lower level of detail than previously (probably with itemised check-lists) to ensure that all loose ends are tied up but planning for this phase must commence much earlier on.

It can be tempting to skimp on final documentation, particularly if the project is already late or overspent. However projects that are late or overspent are prime examples of situations where you need to record exactly what did happen to inform the planning of future projects. Planning in time for proper recording and evaluation also helps the project team to feel that their efforts will be of lasting value.

In this final phase the Project Manager will be juggling the monitoring of fine detail with a review of the strategic objectives to ensure the project does actually achieve the desired outcomes. This will involve close collaboration with the Project Board and any Programme Board and/or Benefits Manager.

The Project Manager should produce confirmation from the Senior User or User Group that the final product or outcome of the project meets the acceptance criteria. There should be a list of follow-on actions - suggested improvements or change requests that have not been implemented during the project. The Lessons Learned log needs to be reviewed and turned into a report.

The Project Board/Sponsor needs to review the outcome of the project, particularly where there is no separate Benefits Manager in place. If this is the case the Project Board needs to ensure (probably by having delegated this to the Project Manager) that the necessary operational and maintenance environment is in place for the final product of the project.

The Project Board needs to ensure that the project’s documentation is complete and that it is archived in a manner so that anyone needing to refer to it can have access. This is particularly important for audit purposes and, as discussed previously, where the project was a feasibility or proof of concept and documentation will be essential for follow-on projects.

The Project Board should ensure that an appropriate group takes responsibility for the future implementation of the follow-on actions.

The Project Board should confirm that the project is ready to be closed and then announce its closure formally. Any staffing resource contracted for the term of the project needs to be released, either from the organisation or returned to normal duties.

The Project Board should ensure agreement that resource or involvement of staff (on the supplier side) is available to deal with any snagging issues that may arise in the early use of the product. There should be a realistic and agreed end date to this snagging period to ensure that future operational issues do not turn into a costly elongated project.

Also, similarly, the Project Board should ensure that there is an agreement by project board members, user group members and the project team to be involved in a post-project review, once use of the product is at a stage where comparative measurements can be taken to prove realisation of benefits.

Mixed Feelings?

Project Closure can be a time of mixed feelings for the Project Team. Hopefully they will feel satisfaction at a job well done but you need to ensure they aren’t:

  • Worried about what the future will hold or
  • So eager to get on with the next project that they leave things unfinished or
  • Elongating the project because they don’t want to leave it

The exit strategy for the project staff must be clear so that they feel adequately supported whether they are going on to new projects, returning to routine jobs or leaving the organisation.

JISC infoNet aims to be the UK’s leading advisory service for managers in the post-compulsory education sector promoting the effective strategic planning, implementation and management of information and learning technology.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Wednesday, April 21st, 2010 and is filed under Project Closure. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories