The Initiation Phase
Initiation is the cheapest phase to skip and the most expensive one to have skipped. It costs a couple of conversations. Getting it wrong costs everything spent afterwards on a project that shouldn’t have started, or that nobody was ever going to defend when it got hard.
In short
- Initiation answers one question: should this exist at all, and why now?
- Its output is a charter — purpose, sponsor, rough scope, rough size. A paragraph is fine; nothing is not.
- “No” and “not yet” are successful outcomes. A phase that approves everything is a queue, not a filter.
- The most common defect is a project with no named sponsor. Everything downstream then has no way to settle a disagreement.
Why this phase exists
Projects almost never begin with a decision. They begin with momentum: a comment in a meeting, a competitor’s announcement, a frustration someone voiced twice. By the time anyone asks “are we doing this?” the honest answer is often “we appear to have started”.
Initiation is the deliberate interruption of that drift. It forces four questions to be answered by a person rather than absorbed by a team, and it produces a short written record of the answers so that in month four, when the project is difficult and someone asks why it exists, there is something to point at.
The four questions, in detail
1. Is there a real problem, stated in someone’s own words?
Write down the problem as the affected person would describe it, not as the solution implies it. “We need a new CRM” is a solution wearing a problem’s clothes. “Sales can’t tell which leads were already contacted, so customers get called twice” is a problem — and notice how much more it tells you about what “done” would look like.
The test: could you tell whether the problem had gone away without looking at whether the project shipped? If not, you have a solution and no problem behind it.
2. Is there a sponsor who will decide trade-offs?
A sponsor is not a cheerleader. A sponsor is the person who, when scope and date collide in month three, decides which one gives. If you cannot name that person, the project has no way to resolve its first real conflict, and the conflict will instead be resolved by whoever is loudest or by the calendar running out.
Ask directly: if we have to choose between the deadline and half the features, who makes that call? A vague answer here is the strongest predictor of trouble in the whole phase.
3. Is it worth more than what it displaces?
Every project is funded by not doing something else. The relevant comparison is never “is this valuable?” — almost everything proposed is valuable. It is “is this more valuable than the next thing on the list, and than the operational work these people will now stop doing?”
You don’t need a business case with a spreadsheet for a small project. You do need a sentence naming what gets displaced.
4. Can we actually staff it now?
The classic failure is approving a project whose named people are already fully committed to two others. Nothing about the approval frees their time, so the project starts, moves slowly, and its lateness is later blamed on execution. See 1.3 Projects vs Operations for why part-time attention costs more than the arithmetic suggests.
The charter: what it has to contain
The project charter is initiation’s only deliverable. Its length should match the project — a paragraph for a two-week build, a couple of pages for a six-month programme — but the same six things belong in both:
| Element | The question it answers | Warning sign |
|---|---|---|
| Purpose | What problem does this remove? | It describes the solution, not the problem |
| Sponsor | Who decides when things collide? | A team name instead of a person |
| Success | How will we know it worked? | “It’s delivered” — that’s output, not outcome |
| Rough scope | What’s in, and pointedly what’s out? | No exclusions listed at all |
| Rough size | Order of magnitude: weeks or quarters? | A precise date before any planning |
| Known constraints | What can’t move — a regulation, an event, a contract? | Constraints discovered in execution |
Note what is not in a charter: a detailed schedule, a task breakdown, a firm budget. Those are planning outputs, and producing them before the go/no-go means you spent the planning effort on a project that might not be approved — which is precisely the waste the gate exists to prevent.
What thin initiation looks like three months later
- The purpose keeps mutating. Every stakeholder describes the goal slightly differently, and each version is plausible. Nobody wrote one sentence down at the start, so all of them are equally official.
- Nobody can say no. Requests arrive and get absorbed because there is no sponsor with the standing to decline them. This is where scope creep comes from — not from greedy stakeholders, but from an absent decider.
- Success is contested at the end. The team delivered what was asked; the sponsor expected something else. Both are telling the truth, because “success” was never written down while it was still cheap to argue about.
- The project can’t be stopped. With no stated purpose, there is no test for whether the purpose still holds. Projects that cannot be evaluated cannot be cancelled, so they end by exhaustion instead.
How much initiation is enough?
Under-doing it
A project appears in the tool with a name and a deadline and nothing else. It will be delivered by whoever remembers the hallway conversation, and evaluated against whatever the loudest stakeholder remembers wanting.
Over-doing it
Six weeks of business-case preparation, three committee reviews and a benefits model for something the team could have built in a fortnight. The approval process now costs more than the project.
A workable rule: initiation should cost about 1–2% of the project. Two days of shaping on a three-month project is proportionate. Two days on a three-day task is not.
How this looks in AB
In AB Projects, creating a new project is the act of writing the charter. The form asks for the four anchors a charter cares about — project name and owner, start and end dates, members, and a one-line description of the deliverable.
The longer charter content (background, success measures, stakeholder notes, initial risks) belongs in a pinned page in the project Wiki, so the “why” stays attached to the project rather than rotting in a shared drive nobody opens. Stakeholders added as project members get visibility and a clear “who approves what” footprint from day one.
Two habits worth adopting:
- Treat the description field as the purpose statement. If it says “CRM migration” you have a title, not a purpose. If it says “so sales stop calling the same lead twice”, the project can be evaluated later.
- Record the go/no-go itself. One Wiki line — approved by <name> on <date> — is what turns an assumption into a decision.
Terms used on this page
- Initiation
- The first phase of the project lifecycle, in which a project is defined well enough to be approved, deferred or declined. Its output is the charter. More →
- Project charter
- The short document that authorises a project: purpose, sponsor, success measure, rough scope and size, known constraints. It is the thing you point at when someone asks why this exists. More →
- Sponsor
- The person who funds the project and decides trade-offs the team cannot. Not a cheerleader — a decider. A project without one has no way to resolve its first real conflict. More →
- Business case
- The argument that the project is worth more than its cost and than the alternatives. On small projects it can be one sentence naming what gets displaced. More →
- Stakeholder
- Anyone affected by the project or able to affect it. Identifying them during initiation is much cheaper than discovering them during execution. More →
- Phase gate
- The decision point at the end of a phase, where continuing is a choice rather than a default. The go/no-go at the end of initiation is the first one. More →
- Scope creep
- Work added after scope was agreed without a matching change to time or budget. Usually a symptom of an absent sponsor rather than demanding stakeholders. More →
Related reading
2.2 The Planning Phase
What happens once the charter is approved: turning a rough size into a plan you can be measured against.
4.2 Stakeholder Management
Finding the people who can affect the project before they find you.
3.1 Defining Project Scope
Turning the charter’s rough scope into a boundary that can settle an argument.