Why Delivering on Time Is No Longer Enough
I’ve spent a good many years involved in project management, and one of the things that still surprises me is how readily organisations can declare a project successful without establishing whether it actually achieved what they originally wanted.
Picture a familiar scene. A major project has just been completed, the project manager presents the final report, and everybody is delighted to hear that the work finished on schedule and within the approved budget. The deliverables have been accepted, the outstanding issues are relatively minor, and senior management is congratulating everyone on a job well done.
Now, I wouldn’t want to take anything away from that achievement, because delivering a complicated project to an agreed schedule and budget is certainly something worth celebrating. However, there’s a question I would be tempted to ask before everyone disappears for the celebration lunch: What has the organisation actually gained from spending all that money?
You see, completing a project successfully and realizing the business benefits that justified it are two related but different things. We can deliver exactly what was requested, satisfy the agreed acceptance criteria and close the project properly, yet still discover that the expected improvements in productivity, customer satisfaction or financial performance haven’t materialised.
And that raises an interesting question about what project success really means, particularly when organisations are investing substantial sums in digital transformation, new technology, operational improvements and changes to the way people work.
So, let’s explore project benefits realisation, why it matters, who should be responsible for it and how we can make sure that delivering the project is only part of the success story.
Why Finishing a Project Doesn’t Necessarily Mean It Was Successful
Let’s imagine that a company decides to invest in a new customer relationship management system, usually referred to as a CRM. Its existing arrangements are inefficient, customer information is scattered across several departments, and salespeople are spending far too much time trying to locate the details they need.
The organisation approves a project to purchase and implement a new system. A project manager is appointed, the requirements are agreed, the supplier is selected, and the implementation proceeds according to plan.
Twelve months later, the system is installed, the data has been migrated, staff have received their training and the project is formally closed. The project manager has delivered everything required and can quite reasonably demonstrate that the agreed outputs have been produced.
But suppose we return six months later and discover that the salespeople are still maintaining their own spreadsheets because they find the new system cumbersome. Customer records remain incomplete, managers are struggling to obtain reliable reports, and the anticipated increase in sales productivity hasn’t happened.
Was the project successful?
Well, from a delivery perspective, it may have performed very well indeed. However, from the organisation’s perspective, the investment hasn’t yet produced the improvements that justified spending the money.
This is why I think we need to be careful about equating project completion with business success. The two should be connected, but one doesn’t automatically guarantee the other.
Understanding the Difference Between Outputs, Outcomes and Benefits
One of the most useful distinctions in benefits management is the difference between an output, an outcome and a benefit. These terms are sometimes used interchangeably in everyday conversation, but they describe different stages in the process of turning project expenditure into business value.
An output is something the project delivers. It might be a new IT system, a completed building, a revised business process or a training programme.
An outcome is the change that happens when people begin using that output. Employees might start processing customer orders differently, patients might gain access to a new appointment service, or managers might make decisions using more reliable information.
A benefit is the measurable improvement that results from the change. That could mean reduced operating costs, faster customer service, fewer errors, increased revenue or improved customer satisfaction.
Let’s return to our CRM example. The new software system is the output, the improved way of managing customer relationships is the outcome, and the resulting increase in sales productivity or reduction in administrative costs represents the benefit.
The important point is that each stage depends on more than simply completing the previous one. Installing software doesn’t guarantee that employees will use it effectively, and changing a process doesn’t necessarily mean that the expected financial or operational improvements will follow.
That’s why benefits realisation requires us to think beyond the immediate deliverables and consider what needs to happen after those deliverables become available.
Why the Business Case Should Be More Than a Funding Document
Most project professionals are familiar with the business case, which explains why a proposed investment is worthwhile. It typically considers the expected benefits, costs, risks, available options and the reasons for recommending a particular course of action.
Unfortunately, I’ve seen business cases treated almost as though their purpose ends once senior management approves the expenditure. The document is carefully prepared, presented to the investment committee and then quietly filed away while everybody concentrates on delivering the project.
That seems rather strange to me, because the business case contains the very assumptions that should help us judge whether the investment continues to make sense.
Suppose the organisation expects its new CRM system to reduce administrative effort by 20%, improve customer retention and provide better sales forecasts. Those anticipated benefits help justify the investment, but they should also influence decisions throughout delivery.
If the project team discovers that an important feature will cost substantially more than expected, we need to consider whether the additional expenditure is justified by the value it will provide. Equally, if circumstances change and one of the expected benefits is no longer realistic, that information should be considered before the organisation commits further resources.
A business case should therefore remain a living management tool, reviewed at appropriate decision points rather than treated as historical paperwork.
And if the justification for continuing the project disappears, responsible management may mean changing its direction or, in some circumstances, stopping it altogether.
How to Identify Benefits Before the Project Begins
If we want to realise meaningful benefits, we need to identify them early enough to influence the decisions we’re making. That sounds obvious, but it’s surprisingly easy for project discussions to become dominated by the features, equipment or facilities people want rather than the improvements those things are supposed to achieve.
Imagine that a hospital wants to introduce an online appointment booking system. During the initial discussions, stakeholders might request mobile access, automated reminders, appointment cancellation facilities and integration with existing patient records.
Those may all be sensible requirements, but I’d want to explore why they’re needed.
Perhaps patients are spending too long waiting on the telephone, administrative staff are overwhelmed during busy periods, and a significant number of appointments are being missed because patients forget to attend.
Now we’re beginning to understand the benefits the organisation wants to achieve. We might be looking for shorter telephone waiting times, reduced administrative workload, fewer missed appointments and improved patient satisfaction.
Those objectives give us a much stronger basis for deciding which features deserve priority. For example, automated reminders might produce a measurable reduction in missed appointments, while a sophisticated reporting feature could be less important during the initial implementation.
The key is to connect the proposed solution to the improvements that matter, rather than assuming that more features will automatically produce more value.
Why Every Important Benefit Needs a Measurable Target
Once we’ve identified the expected benefits, we need to decide how we’ll know whether they’ve actually been achieved. General statements such as improving efficiency, increasing customer satisfaction or making the organisation more competitive may sound impressive, but they aren’t particularly useful unless we establish what improvement we’re expecting.
Let’s imagine that a distribution company wants to reduce the time it takes to process customer orders. Its current average processing time is four hours, and the proposed system is expected to reduce that to two hours.
Now we have something meaningful to measure.
We know the existing position, which is often called the baseline, and we have a target against which future performance can be compared. We can also agree when the target should be achieved, perhaps three months after the system becomes operational.
However, I’d want to go a little further and ask how that processing time will be measured. Are we measuring from the moment an order is received until it’s approved, or until it’s ready for dispatch? Are weekends included? Do we measure every order or a representative sample?
These details matter because two people can produce very different performance figures while believing they’re measuring the same thing.
I’d also want to distinguish between the improvement itself and the financial value we expect it to create. Reducing order-processing time might release staff capacity, but that doesn’t automatically mean the organisation will save an equivalent amount of money. The capacity might instead be used to handle more orders, improve service or avoid recruiting additional employees as demand grows.
All of those outcomes could be valuable, but they should be described accurately rather than presented as guaranteed financial savings.
Who Is Actually Responsible for Realising the Benefits?
This is where benefits realisation becomes particularly interesting, because the people responsible for delivering a project aren’t always the people who can make the expected benefits happen.
A project manager may be responsible for coordinating the work, managing risks, controlling costs and ensuring that the agreed outputs are delivered. However, once the new system or process has been handed over, the project manager may have little direct authority over how the operational departments use it.
Suppose our CRM project has been completed and handed over to the sales department. The project manager can arrange training, support implementation and ensure that the agreed system is operational, but the sales director and departmental managers will usually have a much greater influence over whether employees adopt the new processes.
If those managers don’t reinforce the changes, provide appropriate support or address problems that emerge during everyday use, the expected benefits may never appear.
This is why benefits need clear ownership, and why that ownership often extends beyond the project itself.
The project sponsor normally has an important role in ensuring that the investment remains justified and that appropriate arrangements exist for achieving its benefits. Individual benefit owners, often drawn from the business areas receiving the improvements, should be accountable for monitoring progress and taking action when results fall short of expectations.
Of course, the exact arrangements will depend on the organisation and its governance structure. What matters is that responsibility doesn’t disappear simply because the project has reached its formal completion date.
Why Change Management Is Essential to Benefits Realisation
I think one of the biggest mistakes organisations make is assuming that once a new system or process has been delivered, employees will naturally adopt it and the benefits will follow.
Sometimes that happens, particularly when the new arrangements are clearly easier and more effective than the old ones. However, organisational change is rarely quite that straightforward.
People may be comfortable with existing procedures, worried about making mistakes or unconvinced that the proposed changes will improve their working lives. They may also have legitimate concerns about whether the new system supports the practical realities of their jobs.
Imagine that a company introduces a new digital purchasing process intended to reduce approval delays. The software works perfectly during testing, but once it’s introduced, departmental managers discover that some of the approval rules don’t reflect the way urgent purchases are handled.
Employees begin finding informal ways around the system, and before long the organisation has both the new process and several unofficial alternatives operating simultaneously.
The project may have delivered its output, but the desired outcome hasn’t been fully achieved.
Effective change management helps address this problem by involving the people affected, explaining why the change is necessary, providing appropriate training and supporting the transition into normal operations.
It also means listening to feedback and being prepared to adjust the implementation where genuine problems emerge. The objective isn’t simply to persuade employees to accept whatever has been delivered, but to make sure the new arrangements are capable of producing the improvements the organisation needs.
Why Some Benefits Cannot Be Measured Until After the Project Ends
Another important consideration is that benefits don’t always appear immediately when a project is completed. In fact, some of the most valuable improvements may take months or even years to develop.
Consider a project to introduce new manufacturing equipment. The machinery may be installed, tested and accepted on schedule, but employees still need time to become familiar with it. Production procedures may require adjustment, maintenance teams need experience of the equipment, and managers may have to reorganise work before the expected productivity improvements become visible.
If we measure performance during the first week of operation, we could conclude that the investment has failed, even though the organisation is still working through a perfectly reasonable period of transition.
On the other hand, waiting indefinitely before measuring benefits isn’t sensible either, because that makes it difficult to distinguish genuine improvement from wishful thinking.
The solution is to establish a realistic benefits realisation timetable, identifying when each important benefit is expected to emerge and when performance should be reviewed.
Some benefits may be visible almost immediately, while others require sustained operational changes. The important thing is to recognise these differences and make arrangements for monitoring performance after the project team has completed its work.
A Practical Example of Benefits Realisation Going Wrong
Let’s look at a more complete example.
Imagine that a regional logistics company approves a project to introduce a new warehouse management system. Its existing arrangements rely heavily on manual processes, stock information is sometimes inaccurate, and employees spend considerable time searching for items that haven’t been recorded correctly.
The business case predicts that the new system will reduce picking errors, improve stock accuracy and increase the number of orders processed each day.
The implementation project proceeds successfully. The software is installed, barcode scanners are introduced, warehouse employees receive training and the system goes live according to schedule.
Three months later, however, the expected improvements haven’t appeared.
An investigation reveals that employees are sometimes bypassing the scanning procedures because they believe the additional steps slow them down. Some product locations were never properly verified during the initial data migration, and supervisors haven’t been given enough time to review the accuracy reports generated by the new system.
None of these problems necessarily means that the software itself is defective. The difficulty is that the organisation hasn’t fully established the operational changes needed to obtain the expected benefits.
Now imagine that the warehouse manager takes ownership of the problem. The organisation corrects the location data, adjusts working procedures, provides additional coaching and introduces regular reviews of stock accuracy and picking performance.
Over the following months, the figures begin to improve. Picking errors decline, employees spend less time searching for stock and the warehouse gradually increases the number of orders it can process.
The interesting thing about this example is that the original project delivered the technology, but the benefits depended on what happened afterwards.
Without the operational changes, the investment might have been remembered as an expensive disappointment. With effective benefits management, the organisation has a much better opportunity to achieve the improvements it originally wanted.
How to Build a Practical Benefits Realisation Plan
Now, you might be thinking that benefits realisation sounds like another layer of paperwork, particularly if your organisation already has enough project documentation to keep several filing cabinets occupied.
But I don’t think it needs to be complicated.
For a relatively straightforward project, a concise benefits realisation plan may be perfectly adequate, provided that it answers the important questions.
I’d want to know which benefits we’re expecting, how those benefits support the business objectives and what measurements will demonstrate that they’ve been achieved. I’d also want to establish the current baseline, the target improvement, the expected timescale and the person responsible for monitoring each benefit.
Just as importantly, I’d want to understand what changes are necessary to make those benefits happen.
For example, if a new customer service system is expected to reduce average response times, the plan should consider whether employees need additional training, whether procedures must change and whether managers have the information needed to identify performance problems.
We should also consider the assumptions and risks associated with each benefit. Perhaps the anticipated improvement depends on customer demand remaining relatively stable, or on another department completing a related change.
These dependencies should be visible rather than hidden inside optimistic forecasts.
And because circumstances change, the plan should be reviewed and updated when necessary. A benefit that appeared realistic when the business case was approved may need reconsideration if the organisation’s priorities, operating environment or available resources change.
Why Benefits Reviews Should Continue After Project Closure
Once a project has been completed, organisations often want to release the team and move on to the next priority. That’s understandable, particularly when experienced people are in demand and there’s always another important initiative waiting for attention.
However, if the expected benefits will emerge over the following months, somebody needs to continue measuring performance and deciding whether corrective action is required.
A post-implementation review can help establish whether the delivered solution is operating as intended and whether the transition into business-as-usual activities has been successful.
A benefits review goes further by examining whether the anticipated improvements are actually being achieved.
These reviews may be combined where appropriate, but the distinction is useful. A system can be operating reliably without producing the expected business improvements, just as a project can deliver its agreed outputs without fully achieving its intended outcomes.
I’d also encourage organisations to examine unexpected results, because projects sometimes produce benefits or disadvantages that weren’t anticipated in the original business case.
A new digital service might reduce administrative costs while creating additional support demands elsewhere. A redesigned process could improve speed but introduce quality problems that need attention.
The purpose of reviewing benefits isn’t simply to prove that the original investment decision was correct. It’s to understand what has actually happened and use that information to improve performance and make better decisions in the future.
What Happens When the Expected Benefits Don’t Appear?
Suppose we’ve completed the project, introduced the necessary changes and allowed a reasonable period for the expected improvements to emerge, but the results are still disappointing.
At that point, I think the worst response is to quietly abandon the measurements and hope that nobody asks too many questions.
A much more useful approach is to investigate why the benefits haven’t appeared.
Perhaps the original assumptions were unrealistic, the solution hasn’t been adopted properly, or external circumstances have changed. It’s also possible that the benefits were poorly defined and the organisation is measuring something that doesn’t accurately reflect the value being created.
Once we understand the cause, we can consider what action is justified.
There may be opportunities to improve training, change operational procedures or make relatively modest adjustments to the delivered solution. Alternatively, the organisation may discover that further expenditure would be unlikely to produce sufficient value, in which case accepting the outcome and learning from the experience could be the most responsible decision.
I wouldn’t automatically regard every missed benefits target as evidence of poor project management, because some results depend on factors outside the project team’s control. However, I would be concerned if an organisation had no reliable way of recognising that benefits were falling short or deciding what to do about it.
Why Benefits Realisation Matters to Your Project Management Career
There’s another reason why I believe project professionals should understand benefits realisation, and it has to do with how their contribution is perceived by senior management.
If your conversations with executives are limited to schedules, budgets, resource allocations and progress reports, you may be regarded primarily as somebody who coordinates delivery. Those skills are important, of course, but senior leaders are usually interested in something beyond whether the project plan is being followed.
They want to know whether the investment is worthwhile, whether the organisation is becoming more effective and whether the expected improvements justify the money and effort being committed.
A project professional who understands the business case, recognises how outputs contribute to outcomes and can discuss the risks to expected benefits is in a much stronger position to contribute to those conversations.
That doesn’t mean the project manager should become personally accountable for every operational result after project closure. It means understanding how project delivery connects with business performance and ensuring that the right people are involved in decisions affecting the investment’s value.
This broader perspective is particularly important when working on transformation programmes, complex organisational change and projects where benefits depend on several departments working together.
It’s also one of the reasons professional qualifications such as PMP and APM PMQ place value on understanding business objectives, governance, stakeholder engagement and the wider environment in which projects operate.
Knowing how to produce a project schedule is useful. Understanding why the project exists and how its success will be judged makes that knowledge considerably more valuable.
What I Would Do Differently on My Next Project
If I were starting a new project tomorrow, I’d make sure the expected business benefits were part of the conversation from the very beginning.
Before becoming too involved in the detailed planning, I’d want to understand why the organisation is proposing the investment, what improvements it expects and how those improvements will be measured.
I’d also want to know who will be responsible for achieving the benefits once the project’s outputs have been delivered, because it’s much easier to establish those responsibilities early than to discover at project closure that nobody has agreed to take ownership.
As the project progresses, I’d use the business case and benefits information to help assess important changes and decisions. If a proposed feature adds cost without contributing meaningfully to the expected benefits, I’d want that questioned. Equally, if an alternative solution could achieve the same outcome more economically, I’d want the organisation to consider it.
And before closing the project, I’d make sure there were clear arrangements for handing over the outputs, supporting the operational changes and reviewing the benefits at appropriate times.
None of this requires us to abandon traditional project controls. We still need sensible schedules, cost management, risk management and quality assurance.
What changes is that we begin treating those controls as a means of achieving worthwhile business results, rather than as the final definition of success.
The Real Measure of Project Success
I think there’s a great deal to be proud of when a project is completed on time, within budget and to the required quality. Those achievements reflect professional planning, coordination and hard work, and I certainly wouldn’t want to diminish their importance.
However, the organisation didn’t normally approve the project simply because it wanted somebody to deliver a system, construct a building or introduce a new process. It approved the investment because it expected something valuable to happen as a result.
Perhaps it wanted to reduce costs, improve customer service, increase capacity, comply with new regulations or create opportunities for future growth.
Whatever the objective, that is the reason the project exists.
And if we want to become more effective project professionals, I believe we need to keep that purpose in mind from the moment the business case is first discussed until the expected benefits have been properly evaluated.
Because when we understand not only what we’re delivering, but also why it matters and what must happen for the organisation to benefit, we’re in a much better position to make the decisions that lead to genuine project success.
Develop Your Project Management Skills With Projex Academy
If you’ve found this article useful and would like to develop a deeper understanding of how projects create business value, you might like to explore the professional training available through Projex Academy.
Our PMP Masterclass helps you develop a broad understanding of project management, including business value, governance, stakeholder engagement and the professional judgement needed to make effective project decisions.
You may also be interested in our APM PMQ Masterclass, which covers important areas of project management knowledge, including the business case, benefits management, project governance and organisational change.
And if you’re looking to develop your professional knowledge more broadly, you’ll find our complete collection of Projex Academy courses, designed to help you build practical skills and prepare for recognised project management qualifications.
I’ve always believed that professional training should help people understand not only how to manage the work, but also how to make better decisions about the results they’re trying to achieve. That’s the approach behind my Masterclasses, and it’s something I hope comes across in the articles I share here.
Dave Litten
Project Management Trainer, Author and Founder of Projex Academy
