End Of Project Checklist

Coordinate final delivery of the system to the customer and shutting the project down.

While this checklists covers activities that take place towards the end of a proejct, you should run through this checklist while planning the project, to ensure these activities appear in the schedule.


Most commercial projects end with the deployment of a system to users. An otherwise successful project can be let down badly by a poor deployment.

  • Deployment Plan Complete

    There is a written, detailed plan for deployment.

    This plan should include dates and times for all elements of deployment including: final acceptance testing and roll out to production hardware.

  • Deployment Plan Can Slip If Software Late

    The deployment plan can be put back if the software development is late for whatever reason. If the deployment plan cannot be moved, then there is sufficient slack time between the end of development and the start of deployment.

    If deployment cannot slip and there is no slack time in the schedule, then the project has a major risk that must be brought to the attention of senior managment.

  • Users have sufficient Training

    Users of the new or improved system will be equipped to use it.

    Training is often forgotten until far too late, it is important that users of your system will have all of the training and support they need to effectively use the new system. This task ranges from the trivial - perhaps just sitting with the users for an afternoon - to the truly staggering - training several thousand users scattered across the country.

Post Project Review (PPR)

The Post Project Review identifies areas where the organisation can improve its performance on subsequent projects.

  • Post Project Review Held

    A Post Project Review was held with the aim of identifying areas where the organisation's performance could be improved on subsequent projects.

    The timing of the PPR can be difficult, especially in large projects that need to 'wind-down' over a long period. If necessary, schedule a separate review for each group within the team: management, business analysts, developers, testers and so on.

  • PPR covered Trouble Spots

    The Post Project Review agenda covered all areas where the project had already been identified as lacking.

    A PPR which simply involves slapping each other on the back, saying what a wonderful job we all did is fun, but it doesn't improve anything. When setting the agenda for the PPR, consider all of the comments that have been made throughout the project about things that were lacking and feed it into the review.

    For example, if the developers moaned and whined through the entire development phase about the compiler, make sure the PPR uncovers and documents the aspects of the compiler that were lacking.

  • PPR Followed Up

    Action items from the Post Project Review are followed up by the organisation.

    The purpose of the PPR is to identify areas where there were problems, rather than attempt to provide solutions. After the PPR, these problem areas need to be explored and corrective action plans developed and implemented.

    This can be quite difficult, as after the project is finished the team members are assigned to other projects with new demands on their time. Ensure that the PPR was not in vain by communicating the results of the PPR widely. People working on other projects will then be able to use the experiences summarised in the PPR when preparting to do work on their own projects.

Development Environment Wrap-Up

  • Source Code and Documentation Stored in Permanent Form

    The project source code and documentation - requirements, design, testing and so forth - is stored in a permanent form.

    For out-sourced projects, source code and documentation is typically a deliverable expected by the customer. Even for internal projects, it is a good idea to make a permanent backup of all the hard work done by project team members for future reference.

    Anything stored on hard disk is liable to be erased over time to free up space for other work. Backup tapes are often recycled after a period of time, meaning that they cannot be relied upon either. Therefore to make a permanent record, allocate a set of special backup tapes to make multiple copies of the project source code, or, better still, cut three or four CD-ROMs.

  • Enough Information Provided for Project Restart

    Enough information is available that a new project team could develop extensions to the project product with minimal interruption.

    The importance of this item will vary greatly. If the product of this project will continue to be developed by the same team, then it may not be necessary to produce extra documentation at all - the knowledge will be carried forward to new projects by the team.

    However, in a different situation, say if the project were out-sourced to a services company, or there was a long break before the project source code were to be used again, then it becomes more important. In this situation, there must be written procedures for common development tasks and extensive design notes in order to allow any reasonably skilled development team to pick up where the previous team left off.

© 2003-2006 Alan Green