5.8 Project Scope and Boundaries

Four dimensions of scope

Every one of the four must be written down. A charter that names the process but not the sites will grow to include the other sites by the fourth week.

Start and stop events

The single most useful discipline is defining the process boundary as observable events, not department names.

• Weak: "the order process".
• Strong: "starts when a customer purchase order is received in the order management system; ends when the shipment confirmation is transmitted to the customer."

Observable events do three things: they define exactly which transactions belong in the data set, they determine what the cycle-time clock measures, and they settle arguments about whether a defect belongs to this project.

In-frame and out-of-frame

Scope is only enforceable if the exclusions are written down. The in-frame / out-of-frame tool (sometimes drawn as a rectangle with items inside and outside) forces the team to state both.

Notice that the out-of-frame column carries reasons. "Custom colour grades, under 2% of volume" is a decision; "custom colour grades" alone is an omission somebody will challenge.

The two failure modes

Scoped too wide

Symptoms: the Measure phase runs for months, the data set has too many strata to analyze, the team cannot name a single process owner, and the toll gate keeps slipping. Cause: the team scoped the problem statement rather than the project -- "reduce customer complaints" instead of "reduce mis-shipment complaints on the West distribution centre's pick-and-pack process".

Remedy: decompose with a Pareto, then take one slice. A Pareto of complaint categories, a Pareto by site, or a project tree that breaks a business-level goal into process-level projects will all work. Charter the largest slice and keep the rest as a documented follow-on portfolio, which also protects the team from the accusation that they ignored the remainder.

Scoped too narrow

Symptoms: the team confirms a root cause but cannot act on it because the cause lies outside the boundary; the improvement moves the problem to the adjacent step; the benefit is too small to justify a Black Belt.

Remedy: extend the boundary upstream to include the process that creates the condition, and get the sponsor changed if that crosses into another function. This is the case where a scope change is clearly correct.

Testing that scope has customer value

The Body of Knowledge specifically asks that boundaries be reviewed to ensure the project has value to the customer. Three tests:

1. Does the scoped process produce something a customer receives or depends on? A project scoped entirely inside an internal reporting activity may improve efficiency without improving anything the customer experiences.
2. Is the primary metric a customer-facing characteristic or a proxy? Reducing internal inspection hours is a cost measure; reducing escaping defects is a customer measure.
3. Would the customer notice the target improvement? Moving a lead time from 11.0 to 10.6 days is inside the customer's noise band; moving 11 days to 4 days changes their behaviour.

Managing scope change

Scope changes are not failures; unmanaged scope changes are. Treat any change as a formal request:

The reason to formalize it is that the sponsor approved a specific commitment. Silent expansion means the project is later judged against a promise the team never actually made and cannot meet.

Sizing heuristics

• One Black Belt, four to six months, is the standard target size. A project that cannot plausibly finish in that window should be decomposed.
• The scoped process should have one identifiable process owner who can implement the change.
• The baseline should contain enough events to analyze: as a rule of thumb, at least 30 defect occurrences or 100 continuous observations in the baseline period, otherwise the Measure phase must be extended or the boundary widened.
• The estimated benefit should exceed the deployment's threshold with the scope as written, not with optimistic extrapolation to sites outside the frame.