Business Case
In PRINCE2, the Business Case is the central justification document for any change. It answers the fundamental question: why are we doing this, and does it remain worthwhile? A Business Case is created and reviewed at each stage of the Change Request lifecycle, evolving from an outline at initiation through to a confirmed record at closure.
There are two approaches to handling a Business Case in smallChange. If your organisation has mature processes and the documentation to support it, a Business Case can be uploaded as a Management Product. Attachments marked as Management Products are displayed for review when a stage progression is being sought. smallChange assumes that the uploaded file is Approved and has already been through an external approval process. Alternatively to this you can create a Business Case in smallChange, that is the process that this page describes.
Key Principle: A change should only proceed if it has a valid, demonstrable business justification. If that justification ceases to be valid at any stage, the change should be stopped or replanned.
Section 1 – Document Details
Business Case Title *
Provide a clear, descriptive title that identifies the change being justified. This title is pre-populated from the Change Request but can be refined to better reflect the business justification perspective.
Example: Implementation of Customer Portal to Reduce Support Costs
Stage *
Indicates which stage of the Change Request lifecycle this Business Case covers. A separate Business Case is created for each stage, allowing justification to be assessed and reconfirmed as the change progresses.
| Stage | Description |
|---|---|
| Change Requested | Initial outline justification supporting the decision to investigate the change. |
| Planning | Developed justification based on the planning work completed, including cost and schedule estimates. |
| Implementation | Reconfirmed justification as implementation proceeds. |
| Completion | Final justification review confirming the change delivered its intended outcomes. |
| Closing | Closure record comparing actuals against the original justification. |
Version
Track document revisions using a version number (e.g. 0.1 for draft, 1.0 for the first approved version). Version control ensures that the project board is always reviewing the most current justification and that previous versions are retained for comparison. All versions are viewable on the Business Case page.
Author
The person responsible for preparing this Business Case. Defaults to the Change Manager but can be delegated to any Contributor via a Task.
Last Updated
Automatically recorded. The Business Case must be updated at the end of each stage to reflect actual progress and any changes to costs, benefits, or risks. It is a blocker to seeking approval for the next stage.
Executive Summary
Provide a concise overview of the change, its purpose, and the key outcomes expected. The executive summary should enable a project board member to understand the essentials of the Business Case without reading the full document.
Include:
- What the change is
- Why it is needed
- What the expected outcomes are
- Whether the Business Case is sound
Customer
Displays the customer associated with the Change Request — the individual or organisation that will use the outputs of this change to realise the expected benefits. The customer is drawn directly from the Change Request and cannot be edited here.
Section 2 – Reasons
Explain why this change is necessary. This section provides the business drivers and organisational context that justify the investment.
Consider:
- The problem or opportunity being addressed
- The consequences of not proceeding (the do-nothing position)
- Alignment with organisational strategy, regulatory obligations, or quality objectives
This field is pre-populated from the Change Request description but can be expanded here. Changes made in this section are saved with the Business Case independently of the Change Request.
Note: The Reasons section maps to the Business Case justification principle. Every change must have a clearly articulated reason that connects to organisational objectives. Regulatory or compliance-driven changes still require justification for the chosen approach, not just the obligation itself.
Section 3 – Options
Present the options that were considered for addressing the identified need. PRINCE2 requires that at least two options are evaluated — the do-nothing option must always be included as the baseline against which all other options are compared.
| Field | Description |
|---|---|
| Option Title | A short label for the option (e.g. Do Nothing, Build In-House, Buy COTS Solution). |
| Recommendation | Whether this option is Recommended, Considered (evaluated but not chosen), or Rejected (ruled out). |
| Description | Explain what this option involves and why it was accepted or rejected. |
Up to three options can be recorded. Exactly one option should be marked as Recommended — this is the option the Business Case is built around.
Tip: The do-nothing option is not a null option — it represents the cost and risk of maintaining the current state. Describing it explicitly helps the Change Manager/Board understand what is at stake if the change is not approved.
Section 4 – Expected Benefits
List all measurable improvements (benefits) and negative consequences (dis-benefits) that are expected to result from implementing the recommended option.
Benefits
Benefits are the measurable improvements that the change is expected to deliver. They must be expressed in terms that can be assessed — vague or unverifiable benefits undermine the Business Case.
| Field | Description |
|---|---|
| Description | A clear statement of what the benefit is. |
| Measurement | How achievement of this benefit will be measured (e.g. customer satisfaction score, processing time in minutes). |
| Quantified Value | The estimated financial or numeric value of the benefit (e.g. $50,000 per year, 40% reduction in processing time). |
| Expected Timescale | When this benefit is expected to be realised (e.g. 6 months post-delivery). |
Note: Benefits that cannot be measured cannot be confirmed. If a benefit is difficult to quantify, use descriptive measures with a baseline and target state, rather than leaving it undefined.
Dis-benefits
Dis-benefits are measurable negative outcomes that are expected consequences of implementing the change. Unlike risks, dis-benefits are certain — they are planned outcomes that are accepted as part of the trade-off.
| Field | Description |
|---|---|
| Description | A clear statement of the dis-benefit. |
| Impact | The expected effect (e.g. short-term reduction in throughput during transition). |
| Mitigation | How this dis-benefit will be managed or minimised. |
Benefits Realisation Method
Describe how and when benefits will be confirmed after the change is complete. This should include who is responsible for measuring each benefit, what data will be used, and when reviews will take place.
Important: Many benefits are only realised after the change has closed. Planning for post-change benefits measurement during the Business Case stage ensures accountability is established while the project board still has authority to do so.
Section 5 – Timescale
Define the projected timeframe for this change and the period over which benefits are expected to be realised.
| Field | Description |
|---|---|
| Change Start Date | The planned date on which implementation work begins. |
| Change End Date | The planned date on which the change is expected to be complete and accepted. |
| Benefits Realisation End | The date by which all expected benefits should have been realised and confirmed. |
The Benefits Realisation End date will often extend well beyond the Change End Date, reflecting that operational benefits accumulate over time after delivery.
Section 6 – Costs
List all costs associated with implementing and operating the change. A complete cost picture is essential for a valid investment appraisal.
| Cost Type | Description |
|---|---|
| Capital | One-time expenditure on assets (e.g. hardware, software licences, infrastructure). |
| Operational | Ongoing running costs (e.g. hosting, maintenance contracts, support). |
| One-off | Non-recurring costs that are not capital in nature (e.g. training, migration, consultancy). |
| Ongoing | Recurring costs that are not strictly operational (e.g. periodic licencing fees, scheduled reviews). |
Contingency
A contingency percentage is applied to the total cost to account for uncertainty and unidentified risk. The default is 10%, which should be reviewed and adjusted to reflect the level of risk and uncertainty in the cost estimates. Higher contingency is appropriate where estimates are less mature or the scope is less well-defined.
The Total Cost displayed includes the contingency and represents the full budget requirement for the Business Case.
Section 7 – Investment Appraisal
The investment appraisal compares the total cost of the change against the value of the benefits over time, providing a basis for the project board to determine financial viability.
Appraisal Method
Select the technique used to evaluate the financial return on this investment:
| Method | Description |
|---|---|
| NPV (Net Present Value) | The present value of all future benefits, discounted to account for the time value of money, minus total costs. A positive NPV indicates a worthwhile investment. |
| ROI (Return on Investment) | The percentage return on the investment, calculated as net benefit divided by total cost. |
| Payback Period | The time required to recover the investment from the benefits generated. |
| IRR (Internal Rate of Return) | The discount rate at which the NPV equals zero. Higher IRR indicates a more attractive investment. |
| BCR (Benefit-Cost Ratio) | The ratio of total benefits to total costs. A BCR greater than 1.0 indicates the benefits exceed the costs. |
Appraisal Value
Enter the calculated result of the chosen method (e.g. the NPV figure, the ROI percentage, or the payback period in months).
Investment Appraisal Narrative
Explain the assumptions underlying the appraisal and summarise the conclusion on financial viability. This narrative is important context for the project board — the raw figure alone does not convey the confidence level or the key sensitivities.
Include:
- Key assumptions (e.g. discount rate used, benefit growth rate)
- Sensitivity to changes in key variables
- Whether the result clears any organisational investment threshold
Section 8 – Risks
Summarise the key risks that could affect the viability of this Business Case. This section provides a business-level view of risk — detailed risk analysis, ownership, and response planning is held in the Risk Register.
Existing Risks
Any risks already logged in the Risk Register for this Change Request are displayed here for reference. These do not need to be re-entered.
Adding New Risks
Use this section to record risks that have been identified during Business Case preparation but have not yet been logged in the Risk Register. When the Business Case is saved, these risks are automatically created in the Risk Register.
For each risk, record:
| Field | Description |
|---|---|
| Risk Type | Whether this is a Threat (negative impact) or an Opportunity (positive impact). |
| Impact | The severity of the effect on objectives if the risk occurs (Very High → Very Low). |
| Probability | The likelihood of the risk occurring (Very High → Very Low). |
| Risk Title | A short, descriptive label for the risk (maps to Cause in the Risk Register). |
| Risk Description | What could happen — the risk event itself. |
| Effect | The consequence for the Business Case or project objectives if this risk materialises. |
Note: PRINCE2 expresses risk as a relationship between cause, event, and effect. Thinking through all three components produces more actionable risk entries and clearer ownership. Risks should cover both threats to benefits realisation and opportunities that could enhance the Business Case.
Section 9 – Recommendation
State the formal recommendation on whether this change should proceed based on the evidence assembled in this Business Case.
| Recommendation | Meaning |
|---|---|
| Proceed | The Business Case is sound. The change should continue to the next stage. |
| Close Prematurely | The Business Case is no longer valid. The change should be stopped in a controlled manner. |
| Park | The change remains potentially valid but cannot proceed at this time (e.g. due to resource constraints or external dependencies). It should be revisited at a defined future point. |
Reasoning
Provide a clear explanation of why this recommendation has been made. The reasoning should reference the key findings from the Business Case — the balance of costs, benefits, risks, and alignment with organisational objectives.
Important: A recommendation to close or park a change is not a failure — it is the Business Case process working as intended. Stopping a change that can no longer be justified protects organisational resources and avoids wasted investment.
Lifecycle Status
The Business Case lifecycle status is displayed as a badge and follows this progression:
| Status | Description |
|---|---|
| Draft | The Business Case is being prepared and has not yet been reviewed. |
| Approved | The project board has reviewed and accepted the Business Case for this stage. |
| Rejected | The project board has determined the Business Case does not support proceeding. |
| Superseded | A newer version of the Business Case for this stage has been approved, replacing this record. |
Saving and Approving
Save Draft
Saves the current state of the Business Case without changing its lifecycle status. Use this to preserve work in progress. Drafts can be returned to and edited until they are submitted for review.
Any new risks added in Section 8 are created in the Risk Register when the draft is saved.
Approve
Marks the Business Case as Approved for the current stage. This action is typically performed by the Change Manager or Board after review. An approved Business Case authorises the change to proceed to the next stage.
Note: The Change Manager can only seek approval for the next stage if the Business Case demonstrates that the change remains desirable (the benefits justify the costs), viable (it can be delivered), and achievable (the outcomes are realistic). If any of these conditions cannot be confirmed, the recommendation should be to park or close the change rather than approve.