Skip to content

Lesson 2 — Project Initiation and the Business Case

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Explain what initiation achieves and why it happens before detailed planning.
  2. Construct a business case that states expected value, cost, and the rationale, and that compares at least two options including doing nothing.
  3. Distinguish outputs, deliverables, and benefits, and explain why the distinction matters.
  4. Write a project charter that bounds a project and names its authority.

Prerequisites

Introduction

Most of the money a project will ever spend is committed before anyone writes a plan. The choice to proceed, the scope boundary, and the success criteria are all fixed in initiation — and those decisions are far cheaper to change at that point than at any later one.

Initiation exists to answer three questions while the answers are still cheap: Should we do this? What exactly are we authorising? Who says yes? This lesson covers the two documents that answer them — the business case and the charter.

1. Why initiation comes first

Initiation is not a formality that precedes "real work". It is the cheapest opportunity the project will ever have to be wrong.

Decision Cost to change in initiation Cost to change during delivery
Scope boundary A conversation Rework, re-planning, unhappy stakeholders
Success criteria A sentence An argument about whether the project succeeded
Options considered An afternoon A project that should never have been started
Authority Writing it down Escalation after a disputed decision

A useful discipline: write down what would make you stop. A project with no stopping condition is not a project, it is a commitment.

2. The business case

A business case states why the project should exist. It is not a plan, and it should be short enough to be read. It answers:

  • Value: what improves if this succeeds, and for whom?
  • Cost: what will it take — money, people, time, and what else will not be done instead?
  • Options: what are the alternatives, including doing nothing?
  • Rationale: why is this option the best available one?
  • Risk: what would make the case fail, including non-delivery?

The most frequently skipped line is "do nothing". It is always an option, and comparing against it is what turns a wish into a decision.

Concept Meaning Example (illustrative)
Output What the team produces A stock-tracking module
Deliverable What is handed over A working inventory system in production
Benefit The value that results Fewer stock-outs; less staff time on stock counts

A project can deliver every deliverable and produce no benefit. That is exactly why benefits are written in the business case, and monitored long after the project closes.

Inventory management system (illustrative)

The inventory system is easy to justify because the benefit is measurable: staff currently spend a known number of hours per week on manual stock counts, and stock-outs have a cost. Both are countable, which makes the case arguable rather than aspirational — a real advantage over projects whose benefit is "better user experience".

3. The charter

A charter formally authorises the project. It is one or two pages and must contain:

  1. Purpose — why the project exists, in terms an outsider understands.
  2. Success criteria — observable and testable.
  3. Scope, in and out — with explicit exclusions.
  4. Deliverables and their owners.
  5. Constraints (fixed facts) and assumptions (unconfirmed beliefs).
  6. Milestones.
  7. Governance and authority — from Lesson 1.
  8. Initial risks.

A charter is not a plan. If it contains a task breakdown and a schedule, it has gone too far and will not be read.

4. Authorisation and baselines

Approval of the charter is what turns an idea into an authorised project. Three things change at that moment:

  • The sponsor is committed, and the project has a named owner of the outcome.
  • The scope in the charter becomes the reference point for judging later changes.
  • The project manager's authority exists and can be exercised, not merely hoped for.

Key terms

Term Meaning
Business case The justification for the project: value, cost, options, rationale, risk
Charter The short document that formally authorises and bounds the project
Output What the team produces
Deliverable What is handed over to the recipient
Benefit The value that results from the deliverable being used
Baseline The approved reference version of scope, schedule, or cost

Worked example

Task: build a one-page business case for the illustrative inventory system.

Step 1 — State the problem. Staff record stock in spreadsheets; counts are done weekly by hand; discrepancies are found late; stock-outs are noticed by customers.

Step 2 — List the options. (a) Do nothing; (b) buy an off-the-shelf package and adapt processes; (c) build a tailored system; (d) improve the spreadsheets only.

Step 3 — Estimate value and cost for each. Invented figures, given only to demonstrate the method:

Option Cost (illustrative) Annual benefit (illustrative) Payback (illustrative)
(a) Do nothing 0 0 —
(b) Buy and adapt 12 units 9 units ~1.3 years
(c) Build tailored 30 units 11 units ~2.7 years
(d) Spreadsheets only 3 units 2 units ~1.5 years

Step 4 — Apply the non-financial criteria. Option (b) is cheapest per unit of benefit, but supplier systems vary in capability and the warehouse has unusual processes. Option (c) is only justified if those processes really are unusual.

Step 5 — Write the rationale. Recommended: option (b), with a fixed two-week evaluation of whether the package can model our reorder rules; if it cannot, fall back to option (c). This states a decision, a reason, and a condition — which is what a sponsor needs in order to say yes.

Step 6 — Name the risk to the case. The benefit depends on staff actually using the new process. If adoption fails, the project will deliver on time and produce nothing, so adoption becomes a success criterion, not an afterthought.

Common misconceptions

“A business case is a funding form”

It is an argument, and its job is to be arguable. If it cannot survive the question "why not do nothing?", it is a form with numbers on it.

“Delivering the deliverables means success”

Deliverables are outputs. Benefits are outcomes. A technically perfect system that nobody uses has delivered everything and achieved nothing.

“The charter is the plan”

The charter authorises; the plan organises. Mixing them produces a document too long to approve and too vague to plan from.

Practical activity

Write a business case and charter. Choose an example project.

  1. Draft a business case of no more than one page: problem, options (including do nothing), estimates, recommendation, and the main risk to the case.
  2. Write success criteria that are observable — three of them.
  3. Complete a Project Charter, including the out-of-scope table with at least three exclusions.
  4. Mark every assumption that, if false, would invalidate the case.

What "good" looks like: a "do nothing" option with a real argument attached, and at least one assumption you would be uncomfortable if the sponsor challenged. Label all invented figures as illustrative.

Self-assessment

  1. Why is "do nothing" essential to a business case?
  2. Give an example where a project delivers every deliverable but no benefit, and explain how initiation could have prevented it.

  3. What is the difference between a constraint and an assumption, and why does mixing them matter?

  4. Apply it — inventory management system. The business case claims the system will pay for itself because “staff will spend less time on stock counts”. The sponsor wants a six-month payback before releasing the budget. Nobody has measured how long the counts currently take.

    Hint: A strong answer names the missing baseline, the option the case is missing, and how a target should be recorded.

Show answers
  1. Because the case is a comparison, not a proposal. Without the null option there is no benchmark, so any cost looks justified. "Do nothing" makes the argument falsifiable.
  2. A system is delivered to specification but staff continue with the old process, so the promised time savings never appear. Initiation could have prevented it by naming adoption as a success criterion and by involving the staff who would have to change their work — which is exactly the stakeholder analysis from Lesson 1.
  3. A constraint is fixed and cannot be changed (a deadline, a required integration). An assumption is believed true but unconfirmed, and may turn out false. Mixing them means untested beliefs are treated as facts, so the plan silently depends on things nobody has verified — and the failure surfaces as a schedule problem rather than a mistaken belief.
  4. The case is missing its baseline: the current effort spent on counts, measured or at least stated as a range with the reason for the range. Without it there is no number the benefit can be compared against, and the payback figure is unevidenced. It also needs the options compared — including doing nothing, which here means continuing with the spreadsheets — the timing of the benefits, and who owns their realisation. Treat six months as the sponsor's target, not an estimate: record it as a target, state the confidence and the assumption it rests on, and note that in a system whose main risk is data migration, benefits usually arrive after the transition is complete, not at go-live.

Summary

  • Initiation answers should we?, what?, and who approves? while the answers are still cheap.
  • A business case argues for the project, compares options including doing nothing, and states the risk to its own case.
  • Outputs, deliverables, and benefits are different things; a project can deliver everything and achieve nothing.
  • The charter authorises and bounds the project; approval creates the baseline and the project manager's authority.

Further learning

Next

Continue to Lesson 3 — Feasibility and Project Selection.