How to scope your first CI project

Most failed CI initiatives die at the scoping stage — too big, too vague, or owned by nobody. A practitioner's guide to scoping work that ships.

Why scope is the hardest part

Ask any CI lead what kills more initiatives than execution failure, and most will say the same thing: scope. The project sounded important. The sponsor was enthusiastic. Six weeks in, nobody can describe what 'done' looks like, the team has drifted into adjacent problems, and the original outcome metric is no longer being measured.

Scope discipline isn't a methodology preference. It's the single highest-leverage skill a practitioner can build. The good news: the rules are short.

The four scoping checks

First, name the outcome — not the activity. 'Reduce on-time-delivery variance from 12% to under 5% by Q3' is an outcome. 'Run a Kaizen on dispatch' is an activity. Outcomes survive personnel change; activities don't.

Second, name the owner. One person, named, who can say no on scope changes. If the owner needs three signatures for every decision, the project will move at the speed of the slowest signatory.

Third, name the data. What measure tells you whether the work succeeded? If you can't answer that on day one, the work isn't ready to start.

Fourth, name the time-box. CI projects without a clock become standing committees. 12 weeks is the right default for a first project.

What to do with the rest

The work that doesn't fit the scope isn't lost — it goes to the Idea Hopper. The discipline is keeping the active project boundary tight while the wider portfolio remains visible. That's the system-of-record argument: the scope of one project shouldn't have to compete with everything else for attention.