The Association of Project Management recently published a valuable report aiming at understanding the critical success factors of handing over projects. But do we really hand over projects? We do not hand over a project, but the deliverables, knowhow and the responsibilities for benefits realisation (and risk mitigation) beyond the end of a project´s lifecycle. The report summarizes its findings as follows: „Defining handover is necessary to ensure all parties have an agreed focal point and their efforts are aligned to a common goal. Dates, priorities and responsibility allocation must be clearly communicated. Assumption of these can put handover at risk. Understanding that handover is a transition period rather than a date is paramount to smooth the change curve and close the gap between project phase and operational/business as usual.”
What does ISO 21500 say about the lifecycle of a project and the handover? It defines the lifecycle as follows „The project life cycle spans the period from the start of the project to its end. The phases are divided by decision points, which can vary depending on the organizational environment. The decision points facilitate project governance. By the end of the last phase, the project should have provided all deliverables.“. Unfortunately, ISO 21500 is silent on when and what should be handed over to whom and how. The APM Body of Knowledge 6th edition defines handover as: “The point in the life cycle where deliverables are handed over to the sponsor and users.” And PRINCE2® states: “The project should have a clear end with a correct handover of information and responsibility.”
From my point of view there are several points in time when something is handed over. For example, sales people or a project owner hand over a project with all relevant information to a project manager. During the project life cycle of a project, most likely at the milestine, deliverables are handed over to someone. And for sure, at the end of a project the deliverables (e.g. a product), knowledge (e.g. lessons learned) and responsibilities (e.g. for benefits realisation beyond the project lifecycle) need to be handed over to somebody. A project management plan should clearly define when something should be handed over and what precisely the requirements are.
APM´s report summarizes the process as follows: „Handover is a process not a date. Planning for it should be from the start of the project and it should be viewed as an incremental transfer of knowledge and operation from project team to business as usual. Incorporate a series of mini-handovers throughout the project phase (sample rooms, dry runs, simulations, data readiness tests). The benefits and deliverables must be measurable and communicable from the start. Why are we doing this project and how will we know when it is done? ‘Softer’ benefits are still measurable – such as satisfaction surveys or recruitment and retention data as long as they are benchmarked at the start and targets are set for success criteria. “What gets measured, gets managed”. Involve end users from the outset. Through stakeholder analysis, understand who will benefit from the project, who will be required to facilitate the delivery of the benefits and how the project outputs will impact their role. Then integrate them into the project schedule to ensure they are consulted and engaged before it is too late. They may not be required throughout but they should be brought it at key times to support decision-making. The more involved they are, the more they will become project champions moving into business as usual phase.“
The latter also clarifies who typically is involved in the handover of the deliverables. While in many cases the project owner is the one deliverables are handed over to (e.g. the new IT Software ready for rollout), in others (like the newly designed product in Automotive Industry being handed over to manufacturing) it´s operations that receives the end product. In most cases several stakeholder groups are involved in the handover of deliverables, the owner(s), the end users or the unit responsible for the benefits realisation.
In the case of knowhow the handover is more difficult. To whom are for example the lessons learned reported? It could also be the project owner, the head of a specialized department (e.g. PMO) or the Chief Knowledge Officer. This needs to be made clear before the start of a project so that a project manager knows, when, what, how and to whom he or she needs to handover knowhow collected during the project lifecycle. An organisational standard typically clarifies this or the project managers needs to ask during the definition phase. Also the handover of responsibilities needs to be clarified before the start of a project. The project manager of a design project may hand the responsibilities over to the manager of an R&D project, this one to a project manager in a manufacturing site and finally a project manager in sales or logistics brings the product to the market. While reading you already see the problem of many projects, as they create many interfaces and thus sources for failure, a project programme approach may have prevented this problem in the above case. A handover of responsibilities during the whole process should be minimized in order to avoid interface problems, but anyway, somewhere along the process a handover of responsibilities has to happen, maybe at certain milestones, but certainly at the end of project.
One of the issuses with project handovers is described in APM´s report: „There can be a tendency in project delivery to take a midwifery approach of passing the child on at birth and wishing the parents good luck. This places the benefits realisation very much at risk because it does not focus on preparing the client / end user for their responsibilities and change requirements in order to fulfil these benefits. Pre-handover preparation and post handover support form a key part of transition preparation.“ Therefore, the preparation and professional management of the handover process are mandatory for project success.