Notes

Stage gate review: a project example from pilot to rollout

The pilot finished and met its targets. Overnight support is still missing. Follow a stage gate review that separates completed work from permission to roll out.

A stage gate is a decision point where an authorised person or group decides whether and how a project should proceed. A review brings together the evidence for that decision: outcomes, costs, risks, readiness and the work being proposed next.

The warehouse pilot finishes on Friday. The test report is good, training is complete and the project team asks to order equipment for the remaining shifts.

The night-shift supervisor asks who to call if the new scanning process fails at 2am. The pilot only ran during the day. Nobody has tested an overnight support route.

The pilot is finished, but rollout would extend it to a shift the team has not tested.

APM's stage-gate guidance stresses decision authority, operational involvement and a genuine possibility of saying no. A review that can only approve the next phase cannot properly assess whether it is ready.

Stage gate vs milestone: completion and permission

A milestone marks an event or result in the plan. A gate decides what the organisation will authorise next. They can occur together without meaning the same thing.

Item Question it answers Warehouse example
Milestone Has a defined event or result been reached? The day-shift pilot review is complete
Gate evidence What supports the next decision, and what is missing? Pilot outcomes, costs, support tests and rollout risks
Gate decision What may proceed, within which limits? Hold rollout until overnight support has been tested

An approved project charter establishes the initial authority and boundary. A later gate can authorise a further stage, reject it or ask for a revised proposal. The people making that decision need the appropriate delegated authority.

Gate numbers and phase names differ between organisations. This article uses a general project phase review, not a prescribed branded product-development method.

Set the gate criteria before running the pilot

Our fictional distributor has spent €8,000 on a day-shift scanning pilot. It now requests a separate €40,000 rollout stage covering the remaining warehouse shifts.

That stage includes training the other shifts and preparing deployment. Authorising it would not immediately approve go-live.

Before the pilot, the sponsor agreed to review four things: late dispatches at most 4%, picking errors at most 1%, an accepted operating owner with trained day staff, and a tested support route for the shifts included in rollout.

The pilot records 20 late dispatches among 1,000 orders, or 2%. Eight orders have picking errors, or 0.8%. The counts may overlap; they describe different outcomes over the same 1,000 orders.

Both pilot targets are met. Overnight support still needs a test before the project extends to that shift.

APM's project-review explanation describes gates as evidence-based checks on readiness for a next stage. Keep that readiness question beside the pilot results, rather than letting the two percentages become the whole review.

Stage gate review example: evidence, options and funding

In this example, the operations director is the sponsor who can authorise rollout within the company's Finance, IT and purchasing controls. The project lead prepares the evidence and proposed next scope. The operating owner confirms what can be supported after release.

All four decision routes stay visible below. Start with the missing support evidence. Then assume an overnight recovery test has been completed and accepted, and see which part of the decision changes.

Completed pilot / next commitment still undecided

What does the gate authorise next?

The pilot has finished and met its local outcome targets. Rollout also requires a tested overnight support route. Select a possible decision; each option stays visible.

Define pilotPilot completeGate reviewRollout request

Scroll sideways for the full evidence and status columns.

Fictional review pack. Entry conditions were agreed before the pilot. The sponsor reviews these conditions before deciding whether rollout can proceed.
Entry conditionEvidence in this exampleStatus
Pilot late dispatches at most 4%20 of 1,000 orders = 2%Met in the pilot
Picking errors at most 1%8 of 1,000 orders = 0.8%Met in the pilot
Operating owner and day trainingOwner accepts the scope; day team trainedRecorded
Overnight support routeNamed cover and a recovery test are not yet recordedMissing evidence

Authorise a defined next stage with scope, resources and conditions recorded.

Wait for specified missing evidence, with an owner and a return date.

Revise the proposal or approach and bring it back for another decision.

Do not proceed; organise closure, existing obligations and retained learning.

Hold: a decision to record

Keep the rollout uncommitted. Name the person who will supply the missing evidence and set a return date.

Pilot already spent€8,000Unchanged by the selected next decision

Rollout spending this decision could authorise€0No rollout authorisation under this selected route

Decision authority, money and evidence

The operations director is the assumed sponsor with authority to approve this €40,000 rollout stage, subject to normal Finance, IT and purchasing controls. The €8,000 pilot spend is separate. If the full rollout is authorised, the combined proposed project total is €48,000. This is a spending limit, not money already spent.

The checkbox assumes the overnight test has passed. The sponsor still has to record the decision. Hold and rework need an owner and a return date; further work or spending needs appropriate authority.

Fictional phase review: €8,000 pilot spend and a separate €40,000 rollout request. Compare the decisions using the evidence available.

Choosing “Go” before testing overnight support would skip one of the agreed conditions.

Once overnight support has been tested and accepted, the sponsor can consider Go. Record what may proceed, its spending limit and any conditions.

If authorised in full, the proposed project total would be €8,000 already spent plus the €40,000 next stage, or €48,000. The €40,000 is proposed spending, not money already spent. The pilot's €8,000 stays the same under every decision.

What go, hold, rework and stop mean

Go authorises a specified next stage. It should identify what may be committed, the owner and the conditions that apply.

Hold waits for something defined. For this warehouse, name who will arrange the overnight support test and record its result, and set a date to bring the result back. Any further work or spend needs its own authority.

Rework asks for a different proposal. The team might revise the support design or return with a narrower rollout scope and its costs. It cannot label the existing plan smaller without changing the actual commitments.

Stop ends the proposed route. Existing purchases, contracts, support and records still need to be handled. Judge the next investment on its expected costs and benefits, even if money has already been spent.

Some organisations also use conditional approvals. State exactly which work may proceed before the condition is closed. “Go, subject to support” would be unclear here if the equipment order and release both depend on that support arrangement.

Keep the gate record short enough to use

A useful record identifies the proposed decision, scope and funding; the criteria and evidence; open issues; the decision owner; and what has actually been authorised.

Record conditions with owners and dates. Link the underlying evidence instead of copying an entire test folder into the meeting pack. The requirements traceability example shows why a passed test summary still needs a connection to the agreed requirements.

Keep an independent review distinct from the investment decision. UK government gate guidance describes assurance at key decision points. Its specific public-sector process is not the approval policy for our warehouse.

If the next scope changes, follow the change-control route before committing it. A gate record should make that change visible rather than quietly expand the pilot's original permission.

Carry the decision into operating work

A Go decision should reach the people booking time, placing orders, providing support and accepting the new process. A meeting minute alone won't reserve an overnight responder.

After release, keep the operating owner and outcome review in place. The benefits realisation note explains why delivery completion and later benefits need separate ownership.

For this pilot, arrange the overnight support test and bring the result back to the sponsor. Record the decision so the people ordering equipment and preparing the next shift know what has been authorised.

Sources and example notes

The warehouse, rates, costs, criteria and decision rights are fictional. The pilot results describe the day shift; another shift needs its own readiness review. They do not establish what caused the reported rates.

NextStakeholder mapping: a power-interest matrix example

Working on something like this?

I work with operations and transformation teams on operational excellence, digital transformation programs, supply chains and industrial AI. If this sounds like your line, your program or your problem, I’d be glad to compare notes.

Abolfazl ShirkavandImage preview unavailable