The project team handed over new, automated processes, trained staff and associated documentation. They hanged around for 30 days to support the new system and were then released as quickly as possible as the project was already over budget.
IT operations were furious as the system was not stable at the end of the first month and did not meet their 'handover to production' criteria. But they were left 'holding the baby'.
If the handover criteria are measurable, then they are within your control to deliver
The organization was even more furious as their workload had increased, rather than decreased as planned, and additional (untrained) staff had to be recruited in to continue operations and serving customers.
There was no formal 'project handover', rather a rapid project team dismantlement.
The project team thought they had done a good job. The project was on time, slightly over budget but delivered a working system (albeit not quite stable yet).
While the business was thankful for the system, it was not thankful for the increased workload, new exception conditions for which there were no processes, or the loss of all systems and training expertise with the dismantling of the project team, and so on.
The key question is, "When is a project finished?" The answer should be, "When it has been measured as meeting all of the organization's pre-agreed completion measures." This answer shifts the measurement of conclusion to the organization, not the project team. But, if the handover criteria are measurable, then they are within your control to deliver.
What tends to happen too often is that:
- the project team fails to define clear, measurable business outcomes, but instead defines systems or project deliverables as the end states
- the organization does not understand the inherent gap that ensues between the project's deliverables and the organization's requirements to deliver their outcomes and benefits
- the agreed project deliverables are then delivered but the organization now sees the gap and doesn't want to agree that the project has finished as they will have to fill the gap and are, usually, ill-equipped to do so
- the project team disbands leaving the organization feeling cheated and another project is seen to have 'failed'.
Agreeing with the organization the 'handover criteria' early in the project has been standard project practice for some time. But the wrong criteria are often used because the project is only planned to deliver its outputs and deliverables and not the business desired outcomes and benefits.
When the change in planning perspective to the outcomes and benefits is made, the handover discussion focuses on where, on the list of benefits delivery activities, will the project end and the organization take full accountability? There is now no gap between the project's outputs and the organization's outcomes and benefits.
Now, when the project delivers to the agreed outputs, the organization has a game plan (via benefits delivery plans) to take the project forward to deliver all of the outcomes and benefits. The project is seen as successful.
While the temptation on the project side is to minimize the activities the project is held accountable for, you need to remember the point of the project is not just to finish but to enable the realization of the desired business outcomes and benefits. Where you draw the line between the project and the organization for handover purposes should be determined by what plan best assures the overall successful delivery of the outcomes and benefits.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.