Why care?

  • Helpful for making cases for budgets/briefs​
    • Measurable benefits are easier to pitch/sell​
  • Evidence of your performance​
    • Performance plans, yaaay…​
  • Publicly accessible in government, so citizens (and journalists) care​. If you’re private, your shareholders probably care too!
    • Don’t you want to know your tax dollars are achieving what you paid for?​
    • Audits happen too​?
  • Looks really nice on your resume or social media​

Need a template? Here is one you might like based on the following approach: https://businessanalysis.space/document-templates-samples/benefits-realisation-plan-template/

1) Define & setting the goals​

SMART5 W’s
Specific​Measurable​Attainable​Realistic​Timely​ ​Who: Who is involved?​What:  What do we want to accomplish?​Where: Identify a location if applicable.​When: Establish a time frame.​Why: Specific reasons, purpose or justification for accomplishing the goal.​
General“Get in shape.” ​“Budget/cost reduction.” ​
Specific“The team will join the Name Pending health club in Melbourne CBD and workout 3 days a week to get in shape.”​“The project team will reduce server hosting costs by utilising new technology to reduce IT budget by Q3.”​

2) What specifically is the benefit?​ What are the metrics?​

  • A benefit is the positive results of meeting a goal, the result of completing the success part of a success statement. ​
    • This is typically phrased starting with words such as Increase/Gain, Reduce/Lose, Create/Make/Generate/Enable, Eliminate/Remove/Nullify, etc.​
  • The goal mentions getting in shape, so “increased physical fitness” could be one, and “reduce body fat”. Our second goal mentions budget cost reductions, which could be “reduced IT budget”, but it also mentions utilising new technology, which could provide additional benefits such as “Develop automation capability” or “Reduce legacy software risk”.​

⚠ You must have at least 1 metric for each benefit otherwise the benefit is “Not Realised/Achieved”.​

  • A metric should contain:​
    • measurable source, ​
    • clear target statistic (a %, count, or scientific indicator), ​
    • relate back to a goal and benefit. ​
  • Keep it realistic, and consider external impacts. ​
    • COVID-19 was completely unexpected ​
    • What if vendors change prices, delays increase build time, or another project drive costs up?​
    • A 1% decrease on a budget of $10,000 will be considered insignificant and too easy to meet, but 1% at 10,000,000 could be a challenge​
    • Consider if the metric or measurement tools will change over time or have unforeseen consequences​
      • Algorithms, agreements and tools may have exclusions or inclusions!​
  • Tools cannot distinguish context or circumstances, and statistics can easily be misinterpreted to incorrectly tell a story!​
Goal/objective:The project team will reduce server hosting costs by utilising new technology to reduce IT budget​The project team will reduce server hosting costs by utilising new technology to reduce IT budget​The project team will reduce server hosting costs by utilising new technology to reduce IT budget​
Benefit:Reduced IT budget​Develop automation capability​Reduce legacy software risk​
Metric with target and source:AWS server hosting cost reduced by 10% compared to 2019, taken from AWS monthly billing reports​Full automation of server provisioning from “Requested” status to “Deployed” status, measured by less than 2 human touch points.​Critical risk penetration test results relating to server hosting eliminated (reduced to 0) compared to 2019 test results, from external penetration test.​

3) Baseline and targeting setting​

Once you have a set of metrics, investigate the current state and attempt to measure it. ​

If a baseline cannot be found, or cannot record, these metrics will need to be redefined with further consideration. ​​Re-write the metric, reconsider the sources and applicability. ​If a baseline is found, document both the result and the steps to obtain the baseline for future guidance. ​​The benefits reviewer will need to follow these steps in order to ensure they get an accurate result from the same source or comparable justifiable equivalent.​

You cannot re-baseline later down the track, and no baseline means no evidence it’s been achieved.

❌ No Baseline = Not Realised/Achieved​

4) Post project review​

  • The benefits reviewer (Business Analyst, Project Manager, etc) will attempt to;​
    • find the latest metrics, ​
    • compare against the baseline and target, ​
    • Assess/grade the realisation status.​
  • They are also responsible for the inclusion of relevant commentary and if suitable recommendations for further projects.​
    • Disagree or found some external contributing factor to your score? Add commentary​

This huge table below documents a single benefit and covers everything we want to know, from our goal/objective (current driver), our benefit (in the title) and our metrics (Baseline, Target and how it’s measured)​

A sample benefits realisation record

In general, benefits are measured on a scale; ​

  • “Fully Realised” ​
    • Met target or exceeding​
  • “Partially Met” ​
    • Above baseline but not to target​
  • “Not Realised/Achieved” ​
    • Equal to or below baseline, statistics gathered cannot be confidently/certainly attributed to the benefit or otherwise not measurable. ​

General Principles​

For Project Managers/Owners:

  • Realistically achievable; Make sure they’re achievable and measurable. If it can’t be measured, it can’t be met. This also means keep the list of benefits to an achievable amount/count. ​
  • Justifiable; If the benefit is impacted by another outside project, this may reflect in your benefits realisation. Any benefit selected should have reasoning as to why it was selected, why/how it was baselined, and how much impact your project should have. ​
  • If it’s in the business case, it’s measured; Not all things said in a business case can be measured, but if it helped you get funding, it should be in here.​

For the benefits reviewer (Business Analyst, Project Manager, etc):​

  • Neutrality; everyone wants projects success, but it’s our responsibility to be truthful, transparent and unbiased. ​
  • Accountable; Anecdotal quotes isn’t enough to define a status. You should be able to provide evidence when asked. It should be documented and have certainty beyond reasonable doubt.​
  • Questioning; If a measure doesn’t seem applicable, or mis-represents the situation, ask why and reflect that in the report recommendations and comments. ​
    • Similarly, there is a little wiggle to make an equivalent measure with the same intent, and you can justify a new measure if it is in alignment to the spirit of the benefit.​

We create and share this content to help give back to the community, and give aspiring Business Analysts the guidance we wish we had when we started out.

Please remember you can join the conversation or suggest other topics at any time over in the Business Analysis Space Discord. We welcome any feedback on this or any other posts via email or via the Discord. If this content has helped you or you just appreciate the goal, you can help by sharing our site with your networks or consider donating to our hosting costs.

Contributions & authored by:

Iannelli, Stefan Carton

This content is licensed under CC BY-SA 4.0: Attribution-ShareAlike 4.0 International with full rights to original listed authors & contributors. The opinions expressed within the content above are solely of the respective authors and contributors, and may not reflect the opinions and beliefs of their respective employers/organisations, other writers on this site or website affiliates.

Updated: 2/09/2022