Success and Failure: What Does Good Look Like?

# PRINCE2

What does good look like, and who gets to decide?

June 24, 2026

Tomos Jones

Success and Failure: What Does Good Look Like?

1. Introduction

Projects are often judged by one simple question: Was it a success?

The problem is that different project stakeholders may answer that question in very different ways.

A customer may see success as receiving the right product or service, on time, at the agreed price, and to the correct level of quality (fit for purpose). A supplier may see success as delivering within the contract terms while protecting profit margin (nothing wrong in making a profit). Senior leaders may focus on strategic objectives, return on investment and benefits, while minimising disbenefits. End users may judge success by whether the solution actually makes their working lives easier.

This highlights the central challenge: Project success is not judged by a single measure. It is shaped by performance across benefits, cost, quality, scope, sustainability, risk and time, as well as by the value created, stakeholder satisfaction and continued business justification, and it must be defined deliberately rather than assumed. So, before we ask whether a project has succeeded or failed, we need to ask a better question:

What does good look like, and who gets to decide?

2. Why Projects Are More Complex Than They Appear

Projects can appear simple from the outside. There is a requirement (a need), a plan, a pot of money, a team and a deadline. Surely the job is just to deliver what was agreed?

In reality, projects are often complex, uncertain and difficult to deliver. They involve:

Stakeholders

Requests for change

Risk (threats and opportunities)

Assumptions

Dependencies (internal and external)

Constraints (money and time as examples)

Suppliers

Changing priorities

· Unrealistic expectations

3. Evidence from the CHAOS Report

The Standish Group’s CHAOS Report 2015 used data from more than 25,000 software projects from 2011 to 2015.

Traditional Definition of Success (on time, on budget and on target)

Status	Percentage
Successful	36%
Challenged	45%
Failed	19%

Modern Definition of Success (on time, on budget and delivering a satisfactory result)

Status	Percentage
Successful	29%
Challenged	52%
Failed	19%

A project can be on time and on budget, but still fail to satisfy users, customers or the wider organisation. The shift in results between the traditional and modern definitions suggests that delivery discipline alone is not enough; perceived value and stakeholder satisfaction are harder to achieve and just as important.

Projects are easy to start, but much harder to deliver successfully or even close early.

4. Why Projects Fail

Sometimes the project manager becomes the visible face of failure, but the root causes may sit elsewhere.

Common contributing factors include:

Poor sponsorship

Unclear requirements

Weak governance

Unrealistic deadlines

Lack of user engagement

Changing business priorities

Weak risk management

Poor supplier relationships

Slow decision-making

Project failure is rarely caused by one person. It is usually the result of a system that has not worked well enough.

Projects rarely fail overnight. They usually drift into failure.

5. Success and Failure Are Not Always Black and White

A project may be delivered on time and within budget but still fail to realise the expected benefits. A project may exceed its original budget but deliver a strategically important capability that transforms the organisation. A supplier may deliver exactly what was specified in the contract, yet the customer may still feel the solution does not meet the underlying business need.

This is where disagreement often begins, particularly when delivery measures and business value are treated as if they were the same thing.

Success needs to be defined early, agreed clearly and reviewed as the project evolves.

6. Defining “What Good Looks Like”

Good project management starts by turning broad ideas about success into a shared and usable definition.

This means asking questions such as:

What problem or opportunity are we trying to solve?

What products/services will the project deliver (project scope)?

What outcomes are expected once those outputs are used in the BAU environment?

What measurable benefits are required (our rewards for investment)?

What are the disbenefits?

What risks are we prepared to accept (risk appetite)?

What constraints must we work within (time and costs as two examples)?

Who has the authority to make decisions?

What would make this project no longer worth continuing?

7. Using PRINCE2 Project Management to Improve Project Success

PRINCE2 project management provides a governance framework for improving project success.

At its heart, it helps answer three key questions:

Why are we doing this project? (The Business Case)

Who is responsible for what? (Roles and responsibilities)

How will we control the work? (e.g. Plans, Reporting, Management by exception)

8. How PRINCE2 Project Management Helps

8.1 Continued Business Justification

Projects should only start, continue and complete if they remain worthwhile. If the Business Case no longer holds, the project should be stopped or changed.

Stopping a project is not failure - it is good governance.

8.2 Define Roles and Responsibilities

Clear accountability and responsibility are essential:

Executive (business representation)

Senior Users (user perspective)

Senior Suppliers (delivery perspective)

Project Manager (delivery coordination)

8.3 Manage by Exception

Authority should be delegated within agreed tolerances.

This avoids:

Micromanagement

Hidden issues and risks

8.4 Focus on Products

Projects should focus on products (outputs) rather than just activities:

What products are required?

What quality standards must they meet?

Who will approve them?

How will we know they are fit for purpose?

8.5 Manage Risk Properly

Good risk management asks:

What might happen?

What impact would it have?

How likely is it?

Who owns the risk?

What response is needed?

8.6 Learn from Experience

Lessons should be:

Considered before starting

Captured during the project

Applied during and after completion

8.7 Tailor the Approach

PRINCE2 must be tailored:

Light for small projects

Stronger for complex projects

8.8 Engage Stakeholders Early and Honestly

Good engagement:

Aligns expectations

Reduces misunderstanding

Creates a shared definition of success

9. Conclusion: Success Needs to Be Designed

Project success does not happen by accident. It is shaped by deliberate choices from the start.

It needs to be:

Defined: so, everyone understands what good looks like

Agreed: so, key stakeholders share the same expectations

Governed: so, the right people make the right decisions

Reviewed: so, the project remains aligned to its justification

Protected: so, risks, issues and changes are actively managed

The more meaningful test of success is not simply whether the project delivered, but whether it delivered something worthwhile for the right people, in a controlled and justified way.

Successful projects do the right things and deliver them in the right way.

Ultimately, project success should be judged not only by whether something was delivered, but by whether it created value, remained justified and met the needs of those it was intended to serve. Defining what good looks like at the outset gives projects a far better chance of achieving meaningful and lasting success.

Because in the end, good project management is not just about getting to the finish line. It is about making sure the finish line was worth reaching.

Note: The references to PRINCE2 in this article are intended as a snapshot of how the method can help improve project success. They are not a complete list of every PRINCE2 element, principle, practice, process or technique that could be applied to a project.