Scope It With a SIPOC Before You Touch DMAIC
Improvement projects fail less often from bad analysis than from bad scoping. A team sets out to fix "the onboarding process," three weeks in discovers it has been arguing about four different processes, and the sponsor quietly loses faith. A SIPOC — Suppliers, Inputs, Process, Outputs, Customers — is the one-page tool that prevents this, and it belongs at the very front of DMAIC, in the Define phase, before anyone collects a single measurement.
The reason to build it first is alignment. DMAIC runs Define, Measure, Analyze, Improve, Control in that order, and everything downstream depends on agreeing what process you are actually improving. A SIPOC forces that agreement onto a single page everyone can see. In early 2021, with cross-functional teams scattered across home offices, a shared one-pager does work that a hallway whiteboard used to do for free.
Build it from the middle out
Counter-intuitively, do not start at Suppliers. Start with Process, because the rest only makes sense once the process is bounded.
Process. Name the process and sketch it in four to seven high-level steps — no more. If you need ten steps, your scope is too wide. The first and last steps define your boundaries.
Outputs. List what the process produces — the documents, products, or decisions that leave it. Be concrete; 'a result' is not an output, 'an approved purchase order' is.
Customers. Identify who receives each output. These are not always external; the next internal team is often the customer that matters.
Inputs. List what the process consumes to do its work — information, materials, approvals.
Suppliers. Name who provides each input. This is where you spot dependencies on teams or vendors you do not control.
Use it to draw a hard boundary
The most valuable thing a SIPOC produces is the line around your project. Once the first and last process steps are fixed, you can say plainly what is in scope and, just as important, what is out. When the sponsor later asks you to also fix the upstream system, you have a document to point at: that is a different process, a different SIPOC, possibly a different project.
Keep the process to one verb-led step per box — 'receive request,' 'verify budget,' 'issue order.'
Build it with the people who do the work, not just the manager who describes it; the two views rarely match.
Treat it as a draft you confirm with data in Measure, not as gospel — the real process often differs from the official one.
Revisit it if Analyze reveals the true problem sits outside your boundaries; that is a scope conversation, not a quiet expansion.
A SIPOC is not analysis, and it is not meant to be. It is a contract about scope, drawn before the expensive work begins. An hour spent agreeing on those five columns routinely saves weeks of measuring the wrong process — which is exactly the kind of waste Lean Six Sigma exists to remove.
If you are scoping an improvement effort and want a steady hand on the framing, XNM's strategic advisory can help you define the problem before you spend on solving it.