PRINCE2 2017 Business Case Theme and Continued Justification
Keep investment decisions connected to real value by distinguishing products from outcomes and measuring whether expected benefits still justify cost, risk and dis-benefits.
Executive summary
Decision mechanism
The business case provides the mechanism for judging whether the project is and remains desirable, viable and achievable.
Value is broader than cost
Benefits, dis-benefits, risk, timescale, cost and operational consequences all contribute to the continuing investment decision.
Products are not benefits
Outputs must be used to create outcomes before benefits can be realised and measured.
Justification is maintained
The business case is developed, verified, maintained and used to confirm benefits across initiation, delivery, closure and post-project review.
Purpose of the Business Case theme
The source describes the purpose of the Business Case theme as establishing mechanisms to judge whether the project is, and remains, desirable, viable and achievable so that continued investment decisions can be made. These three tests create a balanced view. Desirable asks whether the expected benefits are worth the dis-benefits, costs and risks. Viable asks whether the necessary products can realistically be created. Achievable asks whether use of those products can produce the intended outcomes and benefits.
The business case therefore supports the principle of continued business justification. It is not a one-time approval paper produced to obtain funding and then archived. It is a live decision basis that is updated when actual performance, forecasts, issues, risks or external events change the project’s value proposition.
What belongs in the justification
The supplied material characterises the business case as the justification for the organisational activity, typically including timescale, cost, benefits and risk. It begins with the business need or problem to be addressed and explains the expected benefits, how they will be achieved and how the organisation will know whether they have been achieved.
Because benefits need confirmation, they should be measurable. That does not mean every benefit must have a direct cash value. A benefit may be non-financial, but the project still needs a meaningful measure or evidence basis. The source also notes that operational costs after project delivery and the cost of organisational changes required to use the outputs should be included in the justification rather than focusing only on the cost of creating the products.
Benefits, dis-benefits and risks
| Concept | Meaning in the supplied material | Management implication |
|---|---|---|
| Benefit | A planned measurable improvement resulting from an outcome and perceived as an advantage | Define ownership, baseline, measurement method and timing. |
| Dis-benefit | A planned negative consequence of undertaking the project | Include it in the value judgement rather than hiding it as if it were an uncertain risk. |
| Threat | An uncertain event that may cause loss or harm | Assess probability and impact and plan a response. |
| Opportunity | An uncertain event that may create gain or improvement | Assess and actively consider responses that increase the chance or effect of the opportunity. |
This distinction matters because a known negative consequence should not be treated as though it might never happen. If a project is expected to increase one operating cost while reducing another, the increase is a dis-benefit to be included in the decision. A threat, by contrast, may or may not occur and is managed through the risk procedure.
Outputs, outcomes and benefits
The source uses a service-system example to show the sequence from product to value. The technical upgrade is the project output. When the organisation starts using it, work can be performed differently; that changed behaviour is an outcome. Only when measurable service performance improves is a benefit realised.
Business need
A problem, opportunity or mandatory requirement creates a reason to consider change.
Output
The project produces an agreed specialist product.
Outcome
People or operations use the product and behaviour or capability changes.
Benefit
The outcome produces a measurable improvement against a baseline.
Confirmation
A planned review checks whether the expected benefit was actually realised.
Project governance should therefore avoid setting “product delivered” as the only success measure. Acceptance of the product is essential, but the business case exists because the organisation expects value from using it. This is why benefit measurement can continue after formal project closure.
Roles and accountability for justification
| Role or level | Business-case responsibility highlighted by the source |
|---|---|
| Executive | Represents the business interest; accountable for the business case and benefits-management approach through the project; ensures alignment and value; secures funding. |
| Senior User | Specifies expected benefits, represents users and helps ensure products can be used to create the intended outcomes. |
| Senior Supplier | Confirms that required products are technically viable and can be delivered using expected resources and costs. |
| Project Manager | Assists development, prepares and updates benefits-management information, updates the business case at stage boundaries and assesses issue/risk impacts. |
| Corporate/programme/customer | Provides the mandate and retains post-project ownership of benefits-management activity. |
| Project Assurance | Monitors the business case and its exposure to project or external events independently of day-to-day project management. |
Minimum management requirements
The theme’s minimum requirements in the source can be paraphrased into four controls. First, create and maintain a business justification throughout the project. Second, review and update it when decisions or events may affect desirability, viability or achievability. Third, define the management actions needed to achieve outcomes and confirm benefits, normally through a Benefits Management Approach. Fourth, make roles and responsibilities for the business case and benefits explicit.
The source specifically notes that compulsory projects still require justification. The obligation may remove the “do nothing” option, but the selected way of complying should still demonstrate value and be managed against cost, risk and expected outcomes.
Business case development cycle
Develop
Create an outline case from the mandate or business need before significant commitment.
Verify
Check during initiation that the detailed case remains viable once plans, costs, risks and controls are better understood.
Maintain
Update actuals and forecasts through delivery, especially at stage boundaries and when material issues or risks arise.
Confirm
Review whether intended benefits are realised, including measurements that may occur after project closure.
This cycle aligns the business case with staged governance. The project board can authorise only the next stage while retaining the option to stop, redirect or replan if the latest justification does not support further investment. The business case is therefore not just a finance document; it is the core argument behind every major continuation decision.
Benefits Management Approach
The source states that the Benefits Management Approach specifies the management actions required to ensure outcomes are achieved and benefits can be confirmed. It may identify benefits and their owners, measurement methods, measurement timing, baseline measures, resources needed for benefit reviews and how product performance will be reviewed.
Some reviews may occur during delivery, some near final delivery and some after the project has closed. That timing should follow the way benefits actually emerge. A benefit that depends on user adoption or an operating cycle cannot be credibly confirmed immediately after technical handover.
| Benefits-control question | Evidence to define |
|---|---|
| What improvement is expected? | A clear benefit statement connected to a project outcome. |
| Who owns it? | A named role or accountable business owner, not merely the project team as a whole. |
| Compared with what? | A baseline or reference performance level. |
| How will it be measured? | A practical metric, data source, method and acceptance of any limitations. |
| When can it be measured? | Review timing that reflects how quickly the outcome can produce a measurable result. |
| What happens after closure? | Ownership and resources for post-project benefit reviews. |
Governance decision test
At each important decision point, the business case should be challenged rather than merely updated mechanically. Has the problem changed? Are the products still capable of producing the expected outcomes? Have cost, timescale, risk or dis-benefits changed enough to alter the value judgement? Are benefit assumptions still credible? Is there a better option now available? If the answer indicates that the current project is no longer justified, the principle requires a change of course rather than automatic continuation.
Practical verification checklist
- State the business need or problem before describing the preferred solution.
- Assess desirability, viability and achievability rather than cost alone.
- Separate outputs, outcomes, benefits, dis-benefits and uncertain risks.
- Define measurable benefits and an appropriate baseline wherever benefits are claimed.
- Include operational or organisational change costs needed to use the project outputs.
- Assign business-case accountability to the appropriate business role and benefit ownership to user/business roles.
- Update the justification at stage boundaries and whenever material issues, risks or forecasts change it.
- Plan post-project benefit reviews and transfer their ownership before the temporary project organisation closes.
Common mistakes to avoid
- Treating the business case as a one-time funding document rather than a continuing decision basis.
- Calling a delivered product a benefit without explaining how use creates an outcome and measurable improvement.
- Ignoring planned negative consequences instead of recording them as dis-benefits.
- Assuming a mandatory project needs no value-for-money justification for the chosen solution.
- Leaving post-project benefit measurement with a project team that will no longer exist.
- Continuing because substantial money has already been spent even when the latest justification is no longer valid.