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.
Resources
Most of the preparation for this will have been done already by the Benefits Manager (if such exists). Often this area of responsibility falls to the Project Manager. The introduction of change into an organisation is dealt with in detail in the Change Management infoKit. It will also be useful (essential if there is no Benefits Manager) to review the section of Closing a Programme in the Programme Management infoKit.
In the event that the project was a feeder project (the outcomes of which were necessary before another project could start), the Project Manager will need to spend some time with the project manager of the follow-on project, who may logically have acted as Senior User hitherto. In many such cases there will be a Programme Board co-ordinating the handover arrangements in liaison with the two Project Managers. [See also 'Preparing for Handover' in the Closing a Programme section of the Programme Management infoKit].
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 organisation, or the external funder, or similar organisations 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.
