Businesses rightly pay attention when a project runs late or over budget. Those failures are visible and hard to ignore. A more dangerous failure can look like success. The project finishes, the new system or equipment is accepted, the schedule closes and the budget is largely intact. Yet the business gains little, because the work was weakly connected to what mattered, duplicated another effort, used scarce people at the wrong time or solved a problem that had already faded.
Consulting firm EY’s work on portfolio management describes this risk: organisations can become better at managing projects and still leak value, because they lack a process for deciding which projects deserve to be done and whether they still deserve it. Delivery discipline is essential, but it cannot compensate for investing in the wrong thing.
This article explains the difference between outputs, outcomes and benefits, the ways a well-delivered project can still fail to create value, and a simple continuing-justification test that small and growing businesses can apply at key review points.
Doing things right and doing the right things
Most management systems see execution more clearly than strategic effect. Schedule slippage can be calculated. Spending can be reported. Milestones can be counted. Whether a project actually advanced the business is harder to see, because it depends on assumptions about customers, adoption, capability, competing priorities and whether the original goal still matters.
That creates a bias towards what is easiest to manage. A project two months late gets intense attention. A project perfectly on time that no longer supports the most important priorities may proceed quietly, because nothing in its report looks wrong.
Project management governs how an approved piece of work is delivered. Portfolio management, at any scale, asks which pieces of work should be approved, continued, sped up or stopped. In a small business, the portfolio may be the owner’s list of improvement projects, new products and investments, and the portfolio manager is usually the owner.
Outputs, outcomes and benefits
Project management writers such as Williams and Parr distinguish three things:
- Outputs are what the project delivers: a new machine installed, a system configured, a product launched, a process documented. They are specific and verifiable.
- Outcomes are the changes in how the business operates as a result: staff using the new system, the machine running at its intended rate, customers buying the new product.
- Benefits are the value those changes create: lower costs, more sales, fewer errors, faster delivery.
A project can deliver its outputs perfectly while outcomes and benefits never arrive. A new scheduling system can be installed on time while staff keep using spreadsheets. A new machine can be commissioned while bottlenecks elsewhere mean output does not rise. The chain from output to benefit needs to be designed and owned, not assumed.
Common misreadings
- Approval proves value. Approval shows only that the project passed whatever decision process existed at the time. Strategy, costs, evidence and competing options can all change.
- Money spent justifies more spending. Sunk cost explains a project’s history. It does not justify its future.
- Delivery equals benefit. A technically correct output can go unused, or be used without producing the expected improvement.
- Every project is strategic. Almost any project can be described as supporting growth, efficiency or customers. Real alignment needs a clear chain from output to outcome to benefit to a current priority.
Four ways a successful project can destroy value
Delivering the wrong priority
A sound project can be a poor use of resources if something more important is waiting. When a business has more approved work than people to do it, every lower-priority project slows something more important.
Delivering an output without an outcome
A completed system, product or procedure is an output. If behaviour, processes or operating conditions do not change, the intended outcome never occurs. Training, process changes, incentives and follow-up are part of delivering the outcome, not optional extras.
Improving one area while weakening another
Projects are often sponsored within one part of the business, and their cases emphasise local benefits. A cost-saving change in one area can push work onto another. A new online ordering system can create demand the warehouse cannot handle. A purchasing saving can create supply risk. The project meets its own goal while the business as a whole is worse off.
Staying “successful” after circumstances change
A project’s plan reflects assumptions at a point in time. If those assumptions change, such as a major customer leaving, a new competitor arriving or costs rising, a project can remain on track against an outdated plan. Sometimes discipline means changing the commitment.
A continuing justification test
At major review points, ask five questions:
- Relevance: which current priority does this project materially support?
- Causal logic: what output will create which outcome, and how does that outcome produce value?
- Relative value: is this still a better use of scarce money and people than the alternatives?
- Feasibility: do we still have the capacity, dependencies and conditions needed for the outcome?
- Reversibility: what does it cost to stop, delay, redesign or continue?
A project can perform well against its own plan and still fail this test. The purpose is not to unsettle every project, but to distinguish genuine confidence from automatic continuation.
Name a benefit owner
The person who delivers a project is often not the person who must make its benefits happen. A project manager can install a system. The operations manager must make sure people use it and that it improves performance. Before a project starts, name the person who owns each expected benefit after handover, agree how it will be measured and when it will be checked. Without a benefit owner, benefits tend to be assumed rather than achieved.
Capacity is the hidden constraint
In most small businesses, the limit on improvement is not ideas or money but people. The same owner, managers and key staff are involved in every project while also running daily operations. Approving more projects than these people can genuinely work on does not speed things up. It spreads attention so thin that everything slows down, and the benefits of finished projects arrive later. A practical discipline is to limit how many significant projects run at once, finish them before starting new ones, and treat the time of key people as the scarce resource it is when deciding what to approve.
Review benefits after handover
Most projects are reviewed when they finish, if at all. Benefits usually appear later. Schedule short reviews at sensible points after handover, for example three months and twelve months, and compare what has happened with what the business case promised. Ask whether the outcome is happening, whether the benefit is appearing, what is preventing it if not, and what the business has learned about estimating benefits. These reviews do two jobs: they prompt action to realise benefits that are lagging, and they make future business cases more realistic.
Compare projects with each other
Reviewing each project only against its own approved plan hides opportunity cost. Periodically compare projects with each other: which would we approve again today if they had not started? Which are consuming people needed for something more valuable? Which could be paused with little loss? This comparison is where a business genuinely chooses its priorities.
Keep the strategy and the project list connected
When priorities change, such as a new major customer, a market shift or a cash squeeze, the project list should change too. A useful habit is to review the project list at the same meeting where priorities are discussed, asking for each project whether it still supports the current priorities and in what order. If strategy discussions and project reviews happen separately, the project list tends to become a record of past commitments rather than a tool for current priorities.
Set stop criteria in advance
A project should not have to become a disaster before it can be stopped. Write down at approval what would justify stopping or redesigning it: benefits that no longer look achievable, a strategic change that makes it less relevant, or capacity pressure on more important work. Stopping a project that is being delivered competently is hard, which is why agreeing the criteria in advance helps.
A worked example
This is an illustration. A 40-person manufacturer runs six improvement projects at once. All report green. The largest, a $180,000 project to install new production scheduling software, is on time and on budget. Yet the owner notices that delivery performance has not improved, and two other projects, a new product range and a customer portal, are slipping because the same planners and IT contractor are tied up.
The owner applies the continuing justification test:
- Relevance: the business’s current priority is winning a large new customer that requires reliable lead times and a portal for orders. The scheduling software supports lead times, but only if planners use it fully.
- Causal logic: the output is the configured software. The intended outcome is planners scheduling all jobs in it and customers getting reliable dates. In practice, planners still use their old spreadsheets for urgent jobs, so the outcome is only partly happening.
- Relative value: the customer portal is required to win the new customer and is waiting for the same IT contractor.
- Feasibility: the planners lack time to learn the software properly while also maintaining the old system.
The owner makes three changes. The scheduling project’s remaining configuration work is paused for six weeks while the IT contractor completes the customer portal. The operations manager is named as owner of the scheduling benefit, with a clear outcome measure: all jobs scheduled in the new system within two months, and on-time delivery measured weekly. The old spreadsheets are retired on a set date, with extra training beforehand. The new product range is deliberately deferred by a quarter.
Within three months, the portal is live and the new customer is won. Planners have moved fully to the new software, and on-time delivery rises measurably. No project was delivered faster, but the portfolio created more value.
How this applies to a small Australian business
Small businesses often run several improvement projects alongside daily work, with the same few people involved in all of them. Practical steps:
- List all current projects in one place.
- Define the output, outcome and benefit for each significant project.
- Name a benefit owner for each expected benefit.
- Apply the continuing justification test at key review points.
- Compare projects with each other, especially when people are stretched.
- Write stop criteria at approval.
- Check benefits after handover, not just completion.
The articles on project management basics, writing a project report or business case and mapping dependencies across your projects cover related topics.
Signals worth watching
- Many projects completed but few measurable benefits.
- Projects described as strategic without a clear chain to a priority.
- Business cases never revisited after approval.
- Benefits with no owner after handover.
- Projects protected mainly because of money already spent.
- Strategy changes without any change to the project list.
Common mistakes
- Measuring completion instead of outcomes and benefits.
- Treating approval as permanent justification.
- Ignoring opportunity cost when people are shared across projects.
- Leaving benefits to happen by themselves.
- Continuing because of sunk cost.
- Never stopping a well-run but low-value project.
Frequently asked questions
How often should we apply the justification test? At major milestones, when circumstances change significantly and at least every few months for longer projects.
What if stopping a project upsets the people working on it? Explain the reasons openly, recognise their work, capture what was learned and redeploy them to the higher-priority work. Stopping for good reasons, explained well, usually builds trust in how decisions are made.
How do we measure benefits that take a long time to appear? Identify earlier indicators that the outcome is happening, such as system usage, process times or customer adoption, and check them regularly until the final benefit can be measured.
What should a business case include to make this easier? The expected outputs, the outcomes they should create, the benefits and how they will be measured, the benefit owner, the assumptions that must hold, the people and capacity required, and the conditions under which the project should be stopped or redesigned.
What if the benefit owner and the project manager disagree? Bring the disagreement into the open at the next review. Usually it reveals an unstated assumption about what the output must do to produce the outcome, which is worth resolving before more money is spent.
Is this relevant for very small businesses? Yes. Even a business with two or three improvement projects benefits from asking whether each still matters and who will make its benefits real.
Questions to ask
- Which of our current projects would we approve again today if they had not started?
- Where are we measuring completion rather than effect?
- Which benefits depend on changes outside the project team’s control?
- Which projects continue mainly because of money spent or a sponsor’s influence?
- Where might an on-track project be using capacity needed for something more valuable?
- When our priorities last changed, did our project list change too?
Bringing it together
Delivery discipline answers whether a commitment was carried out well. Strategy asks whether it was worth making, and whether it still is. Distinguish outputs, outcomes and benefits, name benefit owners, test projects for relevance, causal logic, relative value, feasibility and reversibility, compare them with each other and write stop criteria in advance. The hardest decisions are not about failing projects, which eventually demand attention. They are about projects being delivered well that no longer deserve the same priority.
Source: KEVOS notes, drawing on EY guidance on project portfolio management and the distinction between outputs, outcomes and benefits described by Williams and Parr. Examples and figures in this article are illustrations.
