Benefits-Led Change Initiatives
The above title is a great way to describe a project. This definition emphasises the rationale for any project – to realise benefits that hopefully exceed the costs involved and thus add value, where:
VALUE = BENEFITS – COSTS
PMBOK (Project Management Body of Knowledge) describes a project as “a temporary endeavour undertaken to produce a unique product, service or result” with no mention of benefits. The PRINCE2 definition of a project also makes no mention of benefits. Yet benefits are the reason for a project and not just a happy consequence. Benefits are the fundamental project driver.
Project benefits emerge mostly after project completion. Obtaining some sort of benefit, whether financial, economic, social or otherwise is the reason for undertaking a project. If no worthwhile benefit is identified, we should not embark on the project.
While projects are undertaken to add value through benefits, understandably project managers are preoccupied with producing deliverables. Traditionally, it is the project sponsor who is responsible for achieving the business case benefits once the deliverable is in service.
Of course, project delivery is a very important step to achieving benefits. Completing our projects on time, within budget and to expected standards of quality sets the platform for ongoing success, but ultimately it is the realisation of expected, and sometimes unexpected benefits, that determine project success.
This division of responsibilities between project sponsor and project manager has its equivalent in our government, whereby outcomes are the beneficial results that our government wants to achieve and outputs are the deliverables (products and services) that our government departments are engaged in producing.
Outputs may or may not achieve outcomes. This disconnect is a result of the 1980s public service reforms and perpetuated over subsequent decades. Ministers of the Crown are deemed to be exclusively accountable for outcomes and our public service is exclusively accountable for outputs. The principle behind this split is that managers should be held accountable only for things they can control. Outcomes, while supremely important, are seen as more difficult to control because they are affected by many external factors that better reside in the political arena.
This similar division of responsibility between the sponsor and the project manager is understandable, since:
- * Project managers’ success is usually measured in terms of project objectives (scope, time, cost and quality) and not whether deliverables yield all the intended benefits.
- * Most organisations have no formal process for managing project benefits. Like their project managers, the organisation is preoccupied with producing the deliverable. Benefits are largely left to chance.
- * Most benefits arise during the deliverable or product lifecycle, often some time after we project managers have moved on to other endeavours – usually new projects.
However, there is an argument that we project managers should assume greater responsibility for benefit delivery. As a minimum, project managers should include strategies for benefit tracking and realisation in our project implementation plans, appreciating benefits might be tangible or intangible, where:
- * Tangible benefits are those that can be stated in quantitative terms and include benefits that can be expressed in dollars, such as the dollar savings achieved through staff redundancies, and non-financial, but measurable benefits directly attributable to the project, such as improved levels of customer satisfaction and fewer stress-related staff absences.
- * Intangible benefits, which are difficult to measure or quantify, yet still represent a positive return on the project investment, such as happier staff and an improved public image.
Direct benefits such as improved staff morale may contribute to creating indirect benefits, such as improved productivity. However, some would argue that these linkages, often identified by benefits mapping, may be too tenuous to legitimately include indirect benefits in our project business case.
Nevertheless, I suggest that all benefit could be considered, providing we also consider all costs, direct and indirect, and include a realistic assessment of their probabilities. For example, if an indirect benefit has an estimated 70% likelihood of occurring, assuming a primary benefit of similar likelihood first occurs, the secondary benefit would then only have an estimated 49% likelihood of occurring.
Such probability predictions are usually difficult and particularly so for pioneering projects about which we have no history. Since benefits are not certainties, best case and worst case benefit scenarios may need to be developed and risk management techniques employed to help safeguard potential benefits.
There are several reasons why project benefits may not be realised, fully realised or sustained, including:
- * Unsatisfactory business cases that do not properly identify or describe benefits, underestimate or discount risks, and/or over-state benefits sometimes to help ensure projects are approved or are given unwarranted funding priority. Such business cases have probably not been subject to robust and independent scrutiny. The business case should be unbiased and include evidence for and against the proposition, with credible alternatives included wherever appropriate. A benefits identification workshop with key stakeholders might be held during project conception and periodically thereafter.
- * Poor benefit definition. Such anticipated benefits, if identified, are described in only vague terms with plenty of adjectives and adverbs that make their objective measurement difficult.
- * Over-emphasis on deliverables, without thinking much, or at all, about the benefits that the deliverables should create. Sometimes this is the consequence of lethargic sponsors and overly-deliverable-driven project managers. An important job for the project manager is to plan for benefits realisation and keep that plan updated as circumstances change.
- * No plan or mechanism in place to regularly review business case viability or review and manage resultant benefits. Little or no planning is undertaken for benefit tracking and harvesting.
- * Deliverable users not properly trained in the use of the new product or service, have no or little buy-in and/or are reluctant to make the change often due to a fear of the unknown. Suitable change management practices need to be identified and implemented, including any training needed for the successful use of the new products or services.
- * Project sponsors and champions leave the organisation or become preoccupied with other responsibilities and/or the more exciting prospect of starting new projects.
- * External factors (eg, politics, economics, social factors, new technology, new legislation and competition) change after product launch to diminish or cancel anticipated benefits. Such external impacts are more likely when benefits are to be realised over a period of years rather than days.
A white paper on the subject is attached here.
And if you wish to read about some local IT projects and the realisation of their benefits, please check out www.oag.govt.nz/2012/realising-benefits.