White Belt · 13 min
Scoping a project you can actually finish
After this you can
- complete a SIPOC for a process I work in.
- describe my own role on an improvement team and what a Green Belt will expect from me.
Assumes you have done Writing a problem statement that does not contain its own answer.
The problem
A project to "improve the referral process" ran for fourteen months. It started at booking, expanded upstream into how GPs write referrals, then downstream into clinic templates, then sideways into the patient letter system. Four of the original six members had left the team by the end. At the closing review, the sponsor and the project lead gave different answers to the question of where the process started — and both were quoting the kick-off meeting they had both attended.
The idea
Two things kill improvement projects, and neither is technical.
The scope was never bounded, so it grew until finishing became impossible. Nobody agreed who was doing what, so the work fell to whoever felt most responsible — usually one person, usually until they burned out.
Both are fixed on one page, before any data is collected.
The SIPOC, and the line most templates leave off
A SIPOC lists Suppliers, Inputs, Process, Outputs, Customers. Five columns, filled from the middle outwards. It is a fifteen-minute document and its value is almost entirely in two lines that are not columns at all:
Where the process starts, and where it ends. Write both as observable events, not as stages. "Referral arrives in the booking inbox" is an event; "the referral stage" is not. A project whose boundaries are unstated expands until it cannot be finished, and everyone in the room will remember agreeing to a different scope — sincerely.
The boundary is also what stops a team hitting its target by pushing work outside it. If approval time is measured from assignment, rejecting a case resets the clock and looks like success.
Four to seven process steps, each starting with a verb. More than that and you have started drawing a process map before anyone has agreed what is being improved, which is the order that produces maps nobody uses. "Receive referral", not "referral received": a state cannot be timed, staffed or removed, and an action can.
And a stated need for every customer. Naming a customer without writing what they want is how a team optimises for whatever is easiest to measure. Writing the sentence is usually the moment somebody says "actually, that is not what they care about" — which is worth the whole fifteen minutes.
Who does what
An improvement team has four roles, and the failure mode of each is specific.
Sponsor — usually a senior manager. Owns the problem, not the project. Their real job is removing obstacles the team cannot remove and deciding when the scope must not grow. Failure mode: a sponsor who attends the kick-off and the closing review, and is unreachable in between.
Project lead (often a Green Belt) — runs the method. Decides what gets measured and when the team moves to the next phase. Failure mode: doing all the work personally, because it is faster than explaining it, and ending up with a solution nobody in the process believes in.
Team members — the people who do the work being improved. They are not there to be consulted; they are there because they hold information that exists nowhere else. Failure mode: being invited to two meetings and mentioned in the report.
Process owner — whoever will still be responsible after the project closes. If nobody holds this role, the improvement decays quietly and reappears as next year's project.
What a Green Belt will expect from you as a team member
Concretely: that you describe what actually happens rather than what the procedure says; that you say when a proposed change will not survive a busy Friday; that you collect data as the plan states even when you are confident of the answer; and that you disagree in the room rather than in the corridor. The Green Belt owns the method. You own what is true about the work, and there is no substitute available.
Worked example
The referral project's first SIPOC — the one from the kick-off both people were quoting:
| S | I | P | O | C |
|---|---|---|---|---|
| Referring GP practice | Referral letter | 14 steps, from "Referral received" to "Outcome recorded" | Booked appointment | Patient |
| Patient | Patient demographics | Confirmation letter | Referring GP practice | |
| Booking team | Consultant availability | Clinic letter | ||
| Waiting-list update |
Starts with: (blank). Ends with: (blank).
Four failures, and they are the four that produce fourteen-month projects.
No boundaries. This is the whole story. With nothing written down, "the referral process" meant booking to the booking team, letter-writing to the consultants, and everything from the GP's pen to the clinic outcome to the sponsor. Every one of them was working on the process they had in mind.
Fourteen process steps. The kick-off was spent arguing about step 9 rather than agreeing the scope. Several of the fourteen — "Notes pulled", "Notes prepared" — turned out to be outside any sensible boundary once one existed.
"Referral received" and "Letter generated" are states, not actions. Neither can be timed or staffed. Rewritten as "Receive referral" and "Generate letter", both become things somebody does, which is the first requirement for measuring them. Several others on the list are the same shape — "Slot booked", "Notes pulled", "Clinic held" — and the tool does not catch those, because it matches a fixed list of past-tense endings rather than parsing grammar. It finds the two it can and the rest are yours to spot.
Four outputs, two customers. Somebody receives the waiting-list update; nobody wrote down who, so nobody asked what they needed from it.
The same project, scoped:
Starts with: the referral is logged in the booking system. Ends with: the first appointment offer is sent to the patient.
| S | I | P | O | C |
|---|---|---|---|---|
| Referring GP practice | Referral letter | Receive referral | Booked appointment | Patient — seen within six weeks, at a time they can attend |
| Patient | Demographics | Triage to specialty | Appointment offer | Referring GP practice — told within 5 days that the referral was accepted |
| Consultant rota | Clinic availability | Check availability | Waiting-list update | Waiting-list team — accurate position, daily |
| Offer appointment | ||||
| Confirm and record |
Five steps. Both boundaries stated as events. Every customer has a need in their own words — and note the patient's, which is not "the earliest possible appointment". A number of patients were quietly not attending the early ones.
What this cost: fifteen minutes. What it would have saved: thirteen months, and four of the six team members.
Dataset: ds-referral-sipoc — the same data loads in the tool below, so you can reproduce every figure here yourself.
Your turn
The canvas opens with the kick-off version.
- Fill in starts with and ends with first, as observable events. Then look at the process column again — several of the fourteen steps are now obviously outside the boundary, and deleting them takes seconds rather than an argument.
- Cut the process column to five or six verb-first steps and watch both findings clear.
- Write what each customer actually wants, in their words. This is the hard field and the only one that reliably changes what the team does next.
- The canvas has four outputs and only two customers. Add two — the waiting-list team and the referring practice — and watch that finding clear. Adding one is not enough, which is the point: every output goes to somebody, and the count has to reconcile.
- Finally, write down — outside the tool — who your sponsor, project lead and process owner are, by name. If any of the three is blank, that is the most important finding of the session.
SIPOC Canvas
practiceWho hands something in, before the process starts.
What they hand in.
4–7 steps, each starting with a verb. Not a process map.
What comes out. Every one goes to somebody.
Who receives an output — and what they want.
scopeNo start or end point. This is the single most valuable line on the canvas: a project whose boundaries are unstated will expand until it cannot be finished, and everyone will believe they agreed to a different scope.
process14 steps. A SIPOC keeps the process column to about 4–7 so the conversation stays on scope. Past that you are drawing a process map, and you are drawing it before anyone has agreed what is being improved — which is the order that produces maps nobody uses.
process"Referral received" describes a state, not something a person does. Start with a verb — "Receive order", not "Order received". A state cannot be timed, staffed or removed; an action can.
process"Letter generated" describes a state, not something a person does. Start with a verb — "Receive order", not "Order received". A state cannot be timed, staffed or removed; an action can.
customers"Patient" has no stated need. Naming a customer without saying what they want is how a team ends up optimising for what is easy to measure. Write the sentence — it is usually the moment somebody says "actually, that is not what they care about".
customers"Referring GP practice" has no stated need. Naming a customer without saying what they want is how a team ends up optimising for what is easy to measure. Write the sentence — it is usually the moment somebody says "actually, that is not what they care about".
outputs4 outputs but only 2 customers. Every output goes to somebody. An output with no named recipient is either work nobody needs — which is worth knowing — or a customer who has been left off the canvas.
suppliers"Patient" also appears in the process column. A supplier is upstream — it hands something in. If it is doing the work, it belongs in the process, and the real supplier is whoever gives it what it starts with.
How this is calculated
No statistics — this is a structural completeness check, and it deliberately produces no score. A canvas graded out of ten teaches people to fill boxes until the grade goes up.
- Every column has at least one entry, and the start and end are stated.
- The process column holds 4–7 steps. More than that and you are drawing a process map before anyone has agreed what is being improved.
- Each step starts with a verb — “Receive order”, not “Order received”.
- Each named customer has a stated need.
- There are not more outputs than customers to receive them.
Source: George, M. et al. (2005), The Lean Six Sigma Pocket Toolbook, SIPOC; Rasmusson, D. (2006), The SIPOC Picture Book.
Saved runs can be attached to a project deliverable as evidence. Both what you entered and what the tool computed are stored, so the result can be checked again later.
Check yourself
No hints. Wrong answers are explained, not softened.
Which pair correctly states the boundaries of an invoice-payment project?
You are a team member on a Green Belt project. You believe a proposed change will not survive a busy Friday. What is expected of you?
A project closes successfully. Six months later the old behaviour has returned. Which role was most likely missing?
Worth remembering
Why are the start and end points the most valuable lines on a SIPOC?
A project whose boundaries are unstated expands until it cannot be finished, and everyone sincerely remembers agreeing to a different scope. The boundary also stops a team hitting its target by pushing work outside it.
What does a process owner do that a sponsor does not?
Remain responsible after the project closes. Without one, an improvement decays quietly and reappears as next year's project.
What does a Green Belt need from a team member?
What is actually true about the work — including when a proposed change will not survive a busy Friday, said in the room rather than the corridor.
Can you do this now?
Rate yourself honestly. We compare your rating with how you actually answered — the gap is more useful than either number alone.
I can complete a SIPOC for a process I work in.
I can describe my own role on an improvement team and what a Green Belt will expect from me.
Your rating is recorded alongside your drill results. Neither alone marks the competency as met.