How to close your project effectively
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:
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 itemized check-lists) to ensure that all loose ends are tied up but planning for this phase must commence much earlier on.
Actions you must take while closing your project:
1- Handing Over The Project: The end of the project is also the start of routine use of the outcomes. The handover to staff who will carry out normal operations must also be planned so that those staff feel ownership of the project outcomes and are ready to champion them.
2- Lessons Learned: All projects should document their lessons learned. In considering what types of lessons may be learned projects tend to fall into two types:
the project that is expected to achieve an outcome – the achievement being the reason the project is started
the project that is started to enable the organization, or the external funder, or similar organizations to learn – a feasibility project, proof of concept, or a project where a methodology is being tested
The success of the first type of project is dependent upon the outcome being achieved. If it is forecast that the outcome cannot be achieved to an acceptable quality there is little point in continuing to expend resource on it.
The success of the second type of project is the learning that comes out of it. If the end outcome cannot be achieved the project can still be a success if it shows why the outcome cannot be achieved or, that the outcome cannot be achieved in the way that the project was attempting to achieve it. It is also a success if the lessons learned along the way enable others to avoid similar pitfalls or mistakes. The success of such a project is more dependent on the quality of knowledge management and dissemination than on final outcome or product. If such a project achieves the desired outcome that it was testing then that is a bonus.
Such projects require particular attention and focus on the learning aspect. When things go wrong there is a natural tendency to focus on why. When things go well, there is less of an imperative to identify and record why it is going well.
A ‘Lessons Learned’ report gathers all information that may be useful to other projects. It documents what went well and what went badly and why. It describes methods used to estimate, to plan, to manage and control the project and how effective/efficient they were. It contains any recommendations for future projects to either take up, or avoid, ways of working and should contain some measurement of how much effort was required to produce the various products or process changes.
The Issues and Risk logs will be of immense value in producing this report. A further technique is to interview various stakeholders and members of the Project Team, Project Board and User Group to ask for their opinions.
Notes (Place Your Notes Here)