Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Benefits Realization
A working system isn’t the goal
Buying a gym membership doesn’t make you fit. Going to the gym does. In the same way, a new system working perfectly doesn’t create value until people use it and the business changes how it works.
Benefits realisation is the discipline of making sure an investment delivers the value promised in its business case. COBIT treats it as a governance issue: the board wants to know investments create value, not just that projects finish.
From promise to proof
Each benefit in the business case needs:
- a named business owner
- a baseline measured before the change
- a target and the date it should be reached
- an agreed measure and data source
- any dependencies, such as process changes or training
After go-live
Many benefits only appear months after implementation, once processes change and people get used to the system. So tracking continues after the project closes, with results reported to the sponsor and governance bodies. The post-implementation review compares actual benefits with the business case and identifies what to fix.
Why benefits go missing
- scope cuts: the feature that delivered the benefit was dropped to hit a deadline
- low adoption: people keep using the old way
- the process didn’t change: the old steps carry on alongside the new system
- no owner: nobody tracks or pushes the benefit
Example. An expense system promised to cut processing time by 60%. Six months after go-live, processing time is unchanged, because finance still prints and manually checks every claim. The system works; the benefit was never realised, because the process didn’t change.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who is responsible for realising benefits? | Business owners / the sponsor |
| What’s needed to measure a benefit | A baseline, a target and an agreed measure |
| When benefits are assessed | After implementation, often in a post-implementation review |
| The project was on time and on budget but delivered no value | Benefits weren’t realised; review adoption and process change |
In short
- Benefits realisation makes sure the benefits in the business case are actually achieved after implementation.
- Each benefit needs a business owner, a baseline, a measurable target and a date.
- Many benefits arrive after the project closes, so measurement continues beyond go-live.
- The post-implementation review compares actual benefits with those promised.
- Benefits are lost through scope cuts, poor adoption, or the old process carrying on.
Exam traps
- On time and on budget isn't the same as benefits delivered.
- IT doesn't own business benefits; business owners do.
- Without a baseline measured before the change, nobody can prove an improvement.
Slides
Click the slide and use the arrow keys. F toggles full screen.
From promise to proof