Good Practice: Taking a benefits realisation approach for projects can help ensure that the benefits identified at the start of a project get realised at the end.
Frequently a team is disbanded soon after delivery on projects. This approach can result in the solution withering away and dying over time, particularly if it has fallen on stony ground. This outcome can be especially true for a project that involves a change in working practices or revised business processes.
On a recent large project, after the usual development and implementation stages, we retained the project team for a third stage called benefits realisation. We designed this stage to ensure that the roots of the new business process and the supporting IT system would grow deep and deliver real business value.
You should only consider a project completed on delivery of the benefits to the business and not immediately after project delivery. This approach will ensure a swift resolution to implementation problems and the delivery benefits envisioned at the start of the project come to fruition.
To gain benefits, you must have some change. In their book 'The Information Paradox,' John Thorp and DMR's Centre for Strategic Leadership say that:
It is a central tenet of the Benefits Realisation Approach that benefits come only with change and, equally, change must be sustained by benefits. People must change how they think, manage and act in order to implement the Benefits Realisation Approach.
Changing how people think, work and manage is no easy task. Still, without it, your project is in danger of joining a long list of successful project deliveries that never realised their expected benefit or result.
Question 19: Will the deliverables and benefits of your project survive?