Securing Benefits

Posted on 26th June, by JimYoung in Blog. Comments Off on Securing Benefits

Although “securing benefits” may sound more like health insurance or something obtained from NZ Work and Income, rather than anything to do with PM, every project is an investment with the purpose of obtaining benefits. However, most organisations have no formal process for securing project benefits, yet benefits are not just another project component, but are the reason for the project – the fundamental project drivers that are articulated in the project business case.

Have you ever delivered a “successful” project, only to find out later the product was seldom or never used?  In my opinion benefits is currently the most ignored area of PM except perhaps at the start of a project when some eager sponsors might highlight or even exaggerate the anticipated benefits and downplay the costs to help get their projects approved. While the project benefit and cost estimation is of pivotal importance during project “go – no go” decisions, once the project is underway most PMs and project teams are focused on deliverables, timelines and budgets, which can lead to compromised quality and less than optimum benefits. Also, many organisations have no formal process in place to manage and realise benefits, no one responsible for their achievement, and consider the project finished when the project products are produced.

Traditionally, it is the project sponsor who ensures that business case benefits accrue once the project product is in service, which also concerns monitoring and controlling the operational costs during the product’s life cycle. While completing our projects on time, within budget and to expected standards of quality sets the platform for ongoing success, ultimately it is the realisation of expected, and sometimes unexpected benefits, that determine project success. This division of responsibilities between project sponsor and PM has its equivalent in NZ government. 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 PM is understandable, since:

  1. PM success, rewards and recognition is usually measured in terms of project objectives (scope, time, cost and quality) and not whether deliverables yield all the intended benefits.
  2. Many organisations have no formal process for managing project benefits.  Like their PMs, the organisation is preoccupied with producing the products. Benefits are largely left to chance.
  3. Benefits arise after the project life and during the product lifecycle when PMs are likely to be preoccupied with on-going and new projects.

Nevertheless, it is becoming more common to assess the success of a project in terms of the benefits the product achieves, rather than simply evaluating the success in terms of the traditional measures of quality, time, cost and scope. Also, there is growing agreement that we PMs must assume some greater responsibility for benefit delivery. As a minimum we should include measures for benefit tracking and realisation in our project implementation plans. Such responsibility for benefits management encourages us to stay focused on why the project was initiated in the first place. Of course, project delivery is an 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, and of course such benefits should outweigh the costs of achieving them.

Benefits realisation is about ensuring our project delivers the forecasted benefits identified in our business case. It’s about ensuring that the hard work and investment we put into the project gives the greatest possible return. However, projects tend to change over their lives, and even small shifts can produce different results. That’s why it’s important to focus on the project’s benefits, and not just on our project’s timely completion.

Project benefits may be classified into many categories – hard benefits (eg, dollars saved),  soft benefits (eg, enhanced morale), sustained or recurring benefits (eg, process improvements), one-time benefits (eg, sale of surplus stock), and productivity benefits (eg, reduced effort to complete a task).


Before we explore this topic further, we need to understand the relationship between the project goal, objectives, processes, outputs, outcomes and benefits, where:

  1. Project goal is a single unambiguous target to achieve something of value.
  2. Project objectives are measurable parameters or constraints of scope, time, cost, quality and risk, in keeping with which us PMs must navigate and build our creations.
  3. Processes transform one or more inputs into one or more outputs by the application of tools and techniques, applied to PM processes used to manage the work of the project.
  4. Outputs or deliverables are created by the PM process and may be any of the project’s products (tangible or intangible). Outputs remain at project completion, are transferred to a third-party (customer or performing organisation), and enable business changes that create desired outcomes. An output has no intrinsic value because it is the change that brings value not the output itself. The project’s outputs are used by our customers or our organisation’s line management to create desired outcomes.
  5. Outcomes are the results of the change caused by integrating the new outputs into the operations of our organisation. Such changes need to be managed to ensure that planned benefits result.
  6. Benefits are measurable improvements resulting from outcomes that are perceived as advantages by one or more stakeholders, such as a reduction in costs of sales by at least 10% and an increase in sales by at least 15% per annum. It is critical that change initiatives are successfully embedded in order to deliver the benefits. Thus, benefits add value through improvements that result from outcomes and may be easy or difficult to quantify and sometimes non-quantifiable (qualitative), monetary or non-monetary, direct or indirect, anticipated or unforeseen, one-time or recurring, immediate or long-term. Also, benefits are not necessarily assured – they possess uncertainty and have different likelihoods of being achieved. And benefits identified at the commencement of the project may change during the project life and/or during the product life. Thus, business case benefits need to be regularly reviewed and updated.


  Benefits may be grouped into one of the following categories:

  1. Direct monetary benefits (tangible) are those benefits that can be quantified and valued in financial terms, such as cost savings, revenue generation, and cost reductions. Examples are: “To increase revenue by 30% over the next 12 months” and “To reduce costs by 15% within 12 months after product launch.”
  2. Direct non-monetary benefits (tangible) are those benefits that can be quantified but are difficult or impossible to value in financial terms, such as fewer customer complaints, productivity gains, greater accuracy, lower staff turnover, reduced lead times, and increased response times. Examples are: “To reduce rework by 50% within two months.” “ To reduce customer complaints each month by 80% with effect 1 June.” “ To retain current customers and gain 20% new customers over the next year.” “ To add a minimum of 20 new customers each month for the next year.”
  3. Indirect benefits (intangible) can be identified, but cannot be easily quantified, such as enhanced end-user satisfaction, better access to information, improved organisational image, improved customer service, and better morale. Examples are: “To improve customer and staff satisfaction, morale and motivation.” “To improve the business image.” “To comply with legislation.” “To promote the company’s trade brand.” “To enhance the users’ experience.” “To improve working conditions.” “To increase press coverage.”
  4. Dis-benefits are negative consequences from the intended change. We should ensure that the expected dis-benefits represent a price worth paying to obtain the positive benefits.


However, some would argue that indirect benefits may be too tenuous to legitimately include in our project business case and if a benefit can’t be measured numerically it shouldn’t be claimed. Nevertheless, any benefits might be considered, providing we also consider the associated costs, 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 (ie, 70% x 70% = 49%). Such probability predictions are usually difficult and particularly so for pioneering projects about which we have no history.

Since benefits are not certainties, best and worst case benefit scenarios may be developed and risk management techniques employed to help safeguard potential benefits. Risks associated with identified dis-benefits should be mitigated. If managed pro-actively some dis-benefits can be turned into opportunities or even new benefits. However, dis-benefits are not the same as risks. Risks are uncertain events that may or may not occur, whereas dis-benefits are actual consequences. Dis-benefits should be analysed as part of the project business case, to ensure that they do not outweigh expected benefits.


Benefits might also be measured in terms of the “triple bottom line” where they are categorised as:

  1. Economic or financial benefits determined through such techniques as cost-benefit analysis, net present value, internal rate of return, and economic value added calculations.
  2. Social and community benefits that encompass health and safety, cultural, sustainability, welfare and environmental impact factors.
  3. Corporate benefits such as revenue, profitability, innovation, growth, market share, shareholder value, community perception, and ethical and probity considerations.

Thus, a benefit is a measurable improvement that results from an outcome, which is seen to be an advantage by a project stakeholder. “A benefits-lead change initiative” is therefore a very relevant and concise way to describe a project. But if benefits are not measured, or are not measurable, then there may be insufficient evidence to justify our project. This definition emphasises the rationale for any project – to realise benefits that hopefully, sooner rather than later, considerably exceed the costs involved and thus add value, where:


This formula is ridiculously simple and if applied more frequently and more exactingly would go a long way to preventing disaster projects that happen worldwide too often.  If we can’t show value why do the project? Financial benefits such as cost savings and increased revenues are readily quantifiable. However, non-financial benefits such as a reduction in hospital emergency wait times, an improvement in educational outcomes, or compliance with government legislation may be more difficult to quantify, but could be measured by the use of surveys. However, if a benefit is not measurable it should not be formally recognised as a benefit as there will be insufficient evidence that it has been achieved. Thus, benefits must be measurable and evidence-based in order to demonstrate that they provide value. If benefits are not measured, or are not measurable, then we should accept that there is insufficient evidence to justify the investment.


While almost all projects have benefits, some projects don’t have obvious benefits such as compliance projects that are undertaken in response to changing legislation when deadlines are fixed and set externally, although perhaps the benefit might be we avoid penalties and we stay out of jail. Also, there are enabling projects that don’t have benefits themselves, such as a new computer network that allows other projects to run that do deliver benefits. Perhaps reading this book is an enabling project.

Benefits management process

Benefits Management (also referred to as Benefits Realisation Management or Benefits Realisation) is about ensuring that the required benefits that justified the investment are achieved and we obtain real value rather than merely products from our project. The process starts with defining the business change needed and the business outcomes required, although the benefits we identify at the commencement of our project may change over the life of the investment. Thus, business case benefits need to be regularly reviewed and updated in response to changes, which should be justified in terms of their added net value.

The process for benefits realisation starts with the end in mind. Obtaining some sort of benefit, whether financial, economic or otherwise is the reason we undertake our project.  If no worthwhile benefits are envisaged we should not embark on our project and our project should not include any products that do not produce the sought-after benefits.

We can’t expect benefits to materialise without some effort. Benefits evolve over time as people adopt the new product. However, some projects declared successful, never deliver the benefits originally envisaged. Also, different projects sometimes claim the same benefits. In fact, if any two projects that claim the same benefits are really the same project. Also, we need to recognise that one benefit may be dependent on first achieving another. And benefits are not necessarily assured. As with risks, their likely impact and probability needs to be periodically reviewed.

Benefits management is essentially about remembering why we are doing the project.   The process typically involves the following five steps:


  1. Define benefits management plan. A misunderstanding is that benefits just happen. This is not true, they need to be planned for. We must determine how benefits will be managed and set out policies for aspects such as measurement, roles and responsibilities, priorities and key performance indicators (KPIs). Different projects should not claim the same benefits. Unless benefits are progressively tracked
and reported, there is no opportunity for management to implement corrective measures (if need be) to ensure benefits
will be delivered in full, or in a timely manner. Priority should be given to those benefits with the greatest potential value whether financial or non-financial.
  2. Identify and structure benefits. Benefits are identified by users and other stakeholders and depend on the delivery of outputs and the achievement of outcomes. Both benefits and dis-benefits need to be measured. Informed and accurate decisions around business cases cannot be made unless dis-benefits are also identified and measured. Each benefit (and dis-benefit) should be documented in terms of their priority, interdependencies, value, timescale and ownership.
  3. Plan benefits realisation. This step requires we first determine baseline measurements and agree targets. Baseline measurements identify the current performance of an operation so that post-project improvements can be measured. This will enable the extent of success (or otherwise) of the initiative to be established. The benefits plan identifies the anticipated benefits and our confidence level in them being achieved, assigns responsibility for them, provides a timeline for realising benefits, and their relationship to project outputs. Accountability and responsibility for benefit realisation is key for successful benefits management. Benefits are owned by project sponsors and business managers and not usually by PMs, although business managers and us PMs must work together. Our project plan should include the required outcomes, benefits and their owners, and the timeframe in which benefits are to be realised, typically shown in table format:


  1. Implement change. Benefits only happen when something changes. This usually involves changing attitudes and behaviours as well as physical changes. While implementing change, new opportunities for additional benefits might become evident. Unless benefits are progressively tracked and reported, there is no opportunity for management to implement timely corrective measures (if need be) to ensure benefits
will be delivered in full.
  2. Realise benefits. Each benefit should be given an overall benefit ranking based on its total impact and importance to the project and highest priority benefits should receive greatest attention, resource and monitoring. Changes to the way people work need to be embedded to ensure that benefits continue to be realised. Failure to formally assign accountability and responsibility for benefits creates a significant risk that benefits will not be properly, measured or tracked. It is important that responsibility for benefit realisation remains with those business units affected. The project sponsor, specifically appointed change managers, and/or operations managers should track realisation and ensure that changes are permanent. Actions and monitoring for continued realisation should be agreed and documented as part of the product handover procedure to business-as-usual.

Benefit owners are ideally assigned at the start of the project and do not have to be part of the project team, but they do play an increasingly important role towards the end of the project. Typical responsibilities of a benefit owner are to provide input for the benefits realisation plan, to organise benefit measurement and reviews, and to report benefits realisation progress.

Why benefits may not realised

There are several reasons why project benefits may not be realised, fully realised or sustained, including:

  1. An unsatisfactory business case that doesn’t properly identify benefits and/or over-states benefits, which is sometimes deliberate to help ensure projects are approved or are given unwarranted funding priority. Also, some benefits are described in only vague terms with plenty of adjectives and adverbs that make their objective measurement difficult or impossible. Such business cases have probably not been subject to robust and objective scrutiny.
  2. Over-emphasis on products, without thinking much, or at all, about the benefits that the products are intended to create. Sometimes this is the consequence of lethargic sponsors and overly-product-driven PMs.
  3. Product users aren’t properly trained in the new product, have no or little “buy-in”, and/or are reluctant to make the change.
  4. Project sponsors and champions leave the organisation or become preoccupied with other responsibilities and/or the often more exciting prospect of starting new projects.
  5. Changing the way people think, work and manage is no easy task, but without it our project is in danger of joining a long list of successful project products that never realised their expected benefits. Common mistakes are believing that a project is over once the final product is produced, expecting benefits to automatically occur without further effort and expecting benefits when there’s been no change.
  6. No plan or mechanism in place to regularly review business case viability, or to review and manage resultant benefits, and little or no planning is undertaken for benefit tracking and harvesting.
  7. External factors (eg, politics, economics, social factors, new technology, new legislation, and competition) change to diminish or cancel anticipated benefits. Such external impacts are more likely and significant when benefits are to be realised over a period of years rather than months or weeks.


There is an argument that PMs should assume greater responsibility for benefit delivery.  As a minimum, PMs should include strategies for benefit tracking and realisation in our project implementation plans. And whether it’s the business analyst’s, sponsor’s or the PM’s responsibility, the first step is to ensure the following foundations for benefits realisation are in place:

  1. Check the project business case and identify and record the desired benefits. A periodical review and validation of the business case should be scheduled to validate the measures and targets assigned to the benefits.
  2. Identify the stakeholders who will be affected by each identified benefit.
  3. Identify the outcomes and enablers required for the realisation of each benefit.
  4. Determine how to measure the extent to which a particular benefit has been realised. This usually requires we take a baseline measurement before the project starts and use this as a benchmark.
  5. Allocate responsibility for delivery of benefits and identify benefit target dates.
  6. Prioritise the benefits so that the more important have the most focus. This ensures that the project makes the greatest impact.

Benefits are normally achieved after the project is completed, in the operational phase of the product – during the product life cycle. By this time all the money has been spent, the product has been delivered and the creation of value depends entirely upon delivering the benefits. Since benefits are realised or not realised after project closure, perhaps benefits realisation is therefore more appropriately a job for the project sponsor whose responsibilty for the project should therefore extend into the product life cycle until benefits are realised or not realised. The growth in other specialisations such as business analysis and change management means PMs are further removed from the business consequences of their actions. Nevertheless, we PMs should manage the project with the anticipated benefits clearly in mind and navigate our project to help ensure that the intended benefits materialise.

Although project benefits are always listed in the project business case, we may drive our project towards generating specified products, while not giving enough attention to the expected outcomes and benefits. This may be due to our belief that we don’t have a role in this regard, and that it is totally someone elses job to ensure benefits realisation. Also as future PMs we may not yet have been appointed and thus not involved in preparing the business case. This is often the job of the project sponsor and/or business analyst, but if we are identified as the PM early and are involved in business case preparation, consider this a bonus. We have just enhanced the likelihood of both PM and project success.

Further thoughts

While developing the business case might be viewed as a pre-project activity, benefit realisation can be another phase, a post-project activity, once we have closed the project. So projects don’t just end with the delivery of a product and a closure report. As PMs, we are in a unique position to help our customer gain the benefits as identified in the project business case. So, we don’t just let our projects deliver and die, we help ensure the benefits envisaged at the start are realised at the end.

Our early involvement means that we will better understand the rationale for the project and the required benefits, and we may be able to inject some timely, rational thinking, given our project is to deliver these anticipated results should the endeavour be approved. We might also help ensure that the business case and initial estimates are realistic. Sponsors and other key stakeholders, often very keen for their project propositions to be approved, have been know to over estimate benefits, ignore disbenefits, under-estimate project costs, downplay the risks involved, and promise amazingly optimistic delivery dates.

A common misconception is that if we build the projects, the benefits will come.  Benefits management is therefore seen as an unnecessary overhead and once projects are approved, no further justification is sought. Therefore not only are the claimed benefits not leveraged or managed but additional potential benefits are also ignored.  However, benefit realisation has become a vital driver for projects and it is now more common to assess the success of a project in terms of benefits achieved, rather than evaluating success only in terms of the traditional measures of time, cost, and scope. Challenges that often accompany benefits management include:

  1. Lack of clear description of benefits.
  2. Lack of clear benefits ownership and responsibilities.
  3. Lack of benefits measurement database and baseline metrics.

When the project is complete, it should be viewed against the business case. Only by comparing our project’s results against the business case can the degree of project success be determined and our future business cases improved. However, benefits may only be realised after the solution has been “live” for a period of time. A comprehensive benefits report might include mention of benefits planned, benefits realised, dis-benefits, benefits not yet achieved and why, actions to retrieve unachieved benefits, benefits disgarded, further benefits available, and lessons learned (rather than apportioning blame).


The realisation of benefits to create value (our organisation’s value delivery capability) is a core competence for every successful organisation. In summary, good practice principles for managing benefits are:

  1. Line managers and PMs must work together.
  2. Assign clear responsibilities for benefits delivery.
  3. Involve all stakeholders in planning benefits delivery.
  4. Include benefits delivery in the project plan.
  5. Develop benefits metrics for every project.
  6. Integrate risk management with benefits management.
  7. Communicate the benefits delivery plan to all stakeholders.

We must ensure stakeholders are clear about the benefits they are buying, and not just the products. Benefits are the rationale for undertaking the project and are identified in the project business case, which is a core reference document throughout the project life and subsequent product lifecycle. Benefits need to be clear, relevant and measurable, and the business case, which is a “living document,” needs to be updated as circumstances change. Sometimes the rationale or value proposition for the project significantly diminishes, resulting in project cancellation, and sometimes this might occur when project implementation is proceeding well in terms of schedule and budget performance.

While a business analyst may have prepared the project business case complete with anticipated benefits, the project sponsor “owns” the business case, is responsible for keeping it updated, and is primarily accountable for benefits’ realisation. Their responsibility intrudes into the operational life of the deliverable. Sponsor or line manager-arranged user surveys are helpful for gauging benefit realisation progress and effectiveness. Those who use the project product are usually required to provide regular feedback. They track, record and report performance against agreed benefits. Benefits also need to be sustained. Sometimes enhancement projects are implemented when benefits do not materialise as planned or products under-perform.

Project deliverables such as new IT systems, new buildings or new ways of working deliver no benefits in themselves; the benefits come from the application of those products in the business environment and the extent to which those contribute to achievement of business goals

The main focus of every project should be on the benefits and not the deliverables. The project deliverables and products are the vehicle upon which the benefits are delivered. It follows therefore that the project sponsor should be someone who has a direct interest in the project benefits. For example, implementation of a new IT system for finance would be better sponsored by a senior finance manager rather than a senior IT manager.






Comments are closed.


My latest thoughts on Project Management and life.

Business Analyst (BA) and Analysis

To survive or preferably thrive, organisations cannot stand still. They must evolve and progress to remain alive. Such evolution and progress requires projects. And...

Free Book: “Managing Smaller and Medium-Sized Projects” by Dr Jim Young PMP

I acknowledge with sincere appreciation the contributions to this book from numerous clients, student, colleagues, friends and project management practitioners. Their sometimes unwitting input...

The “Lean” Project

Lean is an often-used adjective in business these days, but there’s some confusion over its exact definition. In essence, the goal of Lean is...