Closing a project (part 1)

Posted by Elizabeth Harrin

People shaking handsThe key to closing down a project successfully is to plan in closure from the beginning.  So what should you be planning during the early stages of the project to give yourself the best possible chance of a successful close?

Think about support

What plans are you going to put in place for supporting the deliverables of your project?  For example, if you are delivering a new software system, what is your approach for support for users going forward?  Add the support tasks to Seavus Project Planner or whatever scheduling tool you are using, as part of a final project phase called ‘Closure’.


  • What support function will pick up the ongoing maintenance and queries?
  • What user guides or manuals produced as part of the project will be handed over to the support function?
  • What other project activities will you be doing throughout the life of the project that would create useful information for the support function?

Involve the support people early

Once you have identified who will be the recipient of the deliverables, start involving them in the project.  It is a lot easier to pick up the support for something you know a little bit about – and the support team will be much more willing to accept the handover if they have been involved throughout the project.


  • How will you involve the support team?
  • What role will they play in the project?
  • What time commitment do you need from the support people between now and the time that the project is officially handed over?

Organise your documentation

A lot of your project paperwork will be handed to the support team, so make sure you have plans to keep it up to date and organised.  Plan in regular review sessions.  Put in place a good configuration management system so you always have access to the latest documents.  This will mean that you can easily find the latest, most recent copies of documents at the point that you need to package these up for the support team.


  • How will you organise and archive your project documents?
  • Are there any other text-based project artefacts like a wiki that would be useful to handover to support?
  • How will you identify what documents would be useful for the support team?  Will you tag wiki entries with ‘support’ or ‘handover’ to make them easier to find later on?

What does ‘closed’ look like?

Start thinking about what ‘closed’ looks like early in the project.  There are some straightforward things that equal ‘closed’ such as making sure all tasks are completed, all issues are resolved, all risks have been mitigated or accepted and closed.  But what else, specific to your project, will mean that the project is closed?


  • When will you issue a final project communication about project closure?
  • Who will the final project communication come from?
  • How will you help the project team transition to new projects?
  • What will you do if you can’t close all actions, risks and issues?  Who will pick up anything outstanding?

Finally, consider how long the closure phase will last.  Don’t underestimate the amount of work required to wrap up a project adequately and hand it over to support.  Admittedly, the work will tail off, so you can start picking up other projects during the closure phase.

If you are already close to the end of your project and you haven’t started to think about closing it down yet, don’t despair!  Next week I’ll be looking at what you can do now to make project closure go smoothly.

Tags: , , , , , ,

Post comment