In many small businesses, a project begins with three words from the owner: “Let’s go ahead.” The person asked to deliver it receives a name, a rough budget and a date. What they usually do not receive is everything that sat behind the decision: why this option was chosen over the others, which assumptions made it worthwhile, what would make it no longer worth doing, and how far their own authority runs before they need to come back.
None of that is written down, because it all seemed obvious at the time. Six weeks later, a supplier quote comes in 15% higher than expected, or a key date moves, and the delivery lead faces a choice the owner already thought through but never handed over. They either guess, or they stop and ask about everything, and neither is good for the project.
This article explains why the early decisions on a project are different decisions, why authorising delivery should never be asked to justify the investment, and what a go-ahead should carry into delivery so that the people doing the work can act on the reasoning behind it. It is general information for owners and managers who approve and run projects.
Four decisions, not four documents
Larger organisations often have four documents for the early life of a project: a proposal, a feasibility study, a business case and a project charter. Having four templates can look like good governance. The real test is whether each supports a different decision:
| Stage | The question it answers |
|---|---|
| Proposal | Is this idea worth investigating further? |
| Feasibility | Can it realistically work under our constraints? |
| Business case | Should we invest, and why is this option better than the alternatives, including doing nothing? |
| Authorisation | Are we authorising this defined piece of work, with these limits, these people and this authority? |
A small business does not need four documents. A one-page note can cover all four for a modest project. But the decisions should not be collapsed into one, because each resolves a different uncertainty. The underlying principle is simple: evidence should get stronger before commitment gets bigger. The which ideas deserve a closer look article covers the early stages, and feasibility is more than the numbers covers testing whether an option can work.
Common misreadings
- A business case is a bigger proposal. A proposal makes the case for looking further. A business case compares options, including doing nothing, and explains why the chosen one is better, what it will cost, what could go wrong and how the benefit will be realised.
- Feasible means worthwhile. An option can be technically feasible and still commercially unattractive, or worse than an alternative. Feasibility asks “can it work?”, not “should we do it?”.
- The go-ahead is the final business case. Authorising delivery is an act of governance: it gives someone authority to spend money and use people. It should follow a sound decision to invest, not stand in for one. A paragraph of background and a budget line cannot substitute for comparing options.
- The go-ahead gives unlimited authority. Authority to deliver is bounded by the budget, the scope, the assumptions on which approval was given and the owner’s remaining decisions.
When the go-ahead is asked to do the work of a missing business case, the delivery lead is asked to justify the investment while also delivering it. That weakens both.
What the go-ahead should carry
The moment of authorisation is a handover from “should we invest?” to “how do we deliver?”. A good handover carries four things, without becoming a second business case:
- Intent: the business outcome the project serves, not just the thing to be delivered. “Reduce time spent taking phone orders so the yard team can serve customers” is intent. “Install an online ordering system” is a deliverable.
- Boundaries: what the project includes and what it does not, and what stays with operations or other work.
- Conditions: the assumptions, constraints and limits that made the decision worthwhile. These include return conditions, the specific circumstances in which the delivery lead must come back for a decision, such as a cost forecast above a figure, a key assumption proving false or a critical date at risk.
- Authority: who may decide what, and what must be escalated.
Return conditions are the part most often missing, and the most useful. They let the delivery lead act confidently inside the limits and recognise immediately when a situation is no longer theirs to decide. They also protect the owner: the decision to invest was made on certain assumptions, and the owner should know when those assumptions break.
Delivery success and benefit success are different
A project is a temporary piece of work inside a larger business. It delivers outputs: a system, a fit-out, a machine, a process. The benefits usually come later, when the people who use those outputs change how they work. A new production line delivers capacity; operations must turn it into throughput and lower cost. A new system delivers capability; staff must adopt new ways of working.
The go-ahead should be precise about which of these the project is accountable for and which belongs to someone else. Separate two measures:
- Delivery success: the project delivered the agreed outputs, to the agreed standard, within its limits.
- Benefit success: the business achieved the outcome that justified the investment.
Both matter, and they usually have different owners. The sponsors who can stop and owners who must deliver article covers naming the people who own benefits.
The owner’s role continues after the yes
Approving a project is not the end of the owner’s or sponsor’s involvement. Their job continues as the keeper of the reason for the investment. They should be able to answer at any point:
- Why does this project matter?
- Which trade-offs are acceptable, and which are not?
- Which benefits justify the disruption?
- Which decisions must come back to them?
- What happens if the case for the project weakens?
The delivery lead manages delivery risks. The owner protects the connection between the project and the reason it exists.
Scale it to the decision
Governance should be proportionate. A minor process improvement should not face the paperwork of a major capital investment. But even the smallest project benefits from a clear answer to each of the four decisions, and from a go-ahead that states intent, boundaries, conditions and authority. The test is not how many documents exist but whether each decision was made on enough evidence, and whether the people delivering know what was decided.
A one-page go-ahead note
For most small-business projects, a single page is enough:
| Element | What to write |
|---|---|
| Purpose | The business outcome, not just the output |
| Options considered | What else was considered, including doing nothing, and why this option won |
| Boundaries | What is in, what is out, and what stays with operations |
| Key assumptions | The few assumptions that make the investment worthwhile |
| Return conditions | The situations that require coming back for a decision |
| Authority | What the delivery lead may decide, and what goes to the owner |
| Success | Delivery measures and benefit measures, with owners |
Writing it usually takes under an hour, and it often exposes a gap in the decision itself, such as an assumption nobody has tested.
Writing it down after the fact
Many projects are already under way with none of this written down. It is not too late. Ask the owner and the delivery lead to write the one-page note together, from memory, in half an hour. The exercise usually reveals two or three things the two people understood differently: a budget limit one assumed and the other did not, a deliverable the lead thought was included, or a date the owner regarded as fixed and the lead regarded as a target. Settling those differences part-way through is far cheaper than discovering them at the end, when they become arguments about what was promised.
A worked example
This is an illustration. A landscape supplies business takes most orders by phone, and the yard team spends much of each morning answering calls rather than loading trucks. The owner considers three options: do nothing, hire a part-time phone person, or add an online ordering and delivery-booking system. After pricing each and talking to a few regular customers, the owner chooses the online system, mainly because it also lets customers book delivery slots, which the phone option would not.
The owner writes a one-page go-ahead for the office manager, who will lead delivery:
- Purpose: reduce morning phone time so the yard team can load and serve customers, and let customers book delivery slots themselves.
- Options considered: do nothing, part-time phone staff, online system; the online system won on delivery booking and long-run cost.
- Boundaries: the project delivers the ordering and booking system, a migrated product list, staff training and customer communication. Changes to pricing and to delivery areas are out of scope.
- Key assumptions: about a fifth of orders move online within a year; the system connects to the existing accounting software; the system is live before the spring peak in September.
- Return conditions: the cost forecast exceeds $50,000 against a budget of $45,000; the accounting connection cannot be shown working by the end of June; or the September date is at risk.
- Authority: the office manager chooses between the two shortlisted vendors, decides configuration details within budget and instructs the vendor. Anything that changes what customers pay goes to the owner.
- Success: delivery success is a working system, trained staff and a migrated product list by September. Benefit success, owned by the yard manager, is fewer morning calls and online orders reaching a fifth of the total within a year.
In June, the vendor says the accounting connection needs an upgraded accounting subscription, adding $3,500 and lifting the forecast to $48,500. That is inside the return conditions, so the office manager approves it, records it and tells the owner at the next weekly catch-up.
In August, the vendor’s delivery-booking module slips by five weeks, putting September at risk. That triggers a return condition. The office manager brings the owner two options: delay the whole launch, or launch ordering in September and add delivery booking after the peak. The owner chooses the second, because reducing phone time during spring matters most. The decision takes one meeting, because the reasoning was already written down.
How this applies to a small Australian business
- Keep the four decisions distinct, even if one page covers them all.
- Compare options, including doing nothing, before approving.
- Write a one-page go-ahead for any significant project.
- State return conditions so the delivery lead knows when to come back.
- Separate delivery success from benefit success, with an owner for each.
- Stay involved after approval as the keeper of the project’s purpose.
- Revisit the go-ahead when a return condition fires.
- Scale the paperwork to the size and reversibility of the decision.
Signals worth watching
- Projects approved with a name, a budget and a date, and nothing else.
- Delivery leads unsure whether a decision is theirs.
- Business cases written after the decision was made.
- Nobody able to say what alternatives were considered.
- Success measured only as on time and on budget.
- Owners first hearing about a broken assumption at the end.
Common mistakes
- Treating approval as justification.
- Copying the same information between stages without answering a new question.
- Confusing feasible with worthwhile.
- Handing over a deliverable without the intent behind it.
- Leaving return conditions unstated.
- Assuming the delivery lead can decide everything, or nothing.
Frequently asked questions
Is this too formal for a small business? One page is not formal. It records decisions the owner has already made, so others can act on them.
What if the owner is also the delivery lead? Write the note anyway. It helps the owner notice when their own assumptions break, and it helps anyone who joins later.
How many return conditions should there be? Usually three to five: cost, a key date, one or two critical assumptions, and anything with legal or safety consequences.
What if a return condition fires often? It may be set too tight, or the project may be more uncertain than the go-ahead assumed. Either way, it is information worth acting on.
Should the business case be updated during delivery? Revisit it when a return condition fires or a key assumption changes. It is the basis on which the investment was justified.
Questions to ask
- Which of the four decisions have we actually made, and on what evidence?
- What alternatives did we reject, and why?
- What outcome is this project for, beyond its deliverables?
- Which assumptions make it worthwhile?
- When must the delivery lead come back to us?
- Who owns the benefit after delivery?
Bringing it together
Exploring an idea, testing whether it can work, deciding to invest and authorising delivery are four different decisions. Keep them distinct, even when one page records them all, and let evidence grow before commitment does. When you give the go-ahead, hand over more than a name, a budget and a date: pass on the intent, the boundaries, the conditions behind the decision and the authority that goes with it, including the specific situations that must come back to you. Separate delivery success from benefit success, and stay involved as the keeper of the reason the project exists.
Source: KEVOS notes, drawing on teaching material on project initiation, proposals, feasibility studies, business cases, project charters and project boundaries. Examples and figures in this article are illustrations. This article is general information.
