How to Structure a CI Program: Groups, Roles, and Governance

Most continuous improvement programs do not fail because someone ran a bad project. They fail at the program level. A systematic review of CI initiatives in manufacturing published in Total Quality Management & Business Excellence grouped the documented failure causes into six themes: strategic planning, change management, knowledge management, performance measurement, sustainability, and motivation. Read that list again. None of those are statistical problems. They are organizational design problems, and they are decided before the first project charter is written.

This article is for the person making those decisions: the deployment leader standing up a CI program across plants, sites, business units, or training cohorts. It covers the four structural decisions that outlive any individual project: where the visibility boundaries sit, how roles split authority, how tollgates govern the work, and how new project ideas enter the pipeline.

Draw the isolation boundaries first

Before roles, before templates, before the first kickoff, decide who can see what. This is the least glamorous decision in program design and the hardest one to retrofit.

Programs default to one of two broken states. In the first, everyone sees everything. That sounds collaborative until a plant manager finds their scrap-rate project quoted in another site's deck, or a training cohort browses the projects of the cohort ahead of them. In the second, each unit runs its own tracker, and the program office spends every month-end merging spreadsheets that do not share a status vocabulary.

The working structure is a boundary at the level where accountability actually sits, with a controlled roll-up above it. In practice that boundary is usually the plant, the site, the business unit, or the cohort. In SixGrid this is the Group: every person and every project belongs to one, and that assignment determines visibility. A practitioner in the Cleveland group works Cleveland projects. They do not scroll past Monterrey's.

The same structure carries a different program shape without modification. A training provider running belt cohorts makes each cohort a group: students see their own cohort's projects, each instructor gets Manager access scoped to the cohorts they teach, and the provider's administrators see every cohort at once. When the spring cohort graduates, its group and its project history remain intact for audit, and the fall cohort starts clean. The isolation decision is identical to the multi-site case. Only the label on the boundary changes.

Two properties matter when you draw these lines:

• The boundary should match a real accountability line, not the org chart's cosmetics. If one leader answers for the results of two departments, they are probably one group.
• The roll-up must be automatic. If aggregating across boundaries requires a human to assemble anything, the aggregation will be late, and then it will stop happening.

Split authority into two tiers

A common failure is a single flat role list that tries to answer two different questions at once: what can this person do in the organization, and what can they do on this project. Those are separate questions, and a program structure should answer them separately.

The first tier is organization-wide. SixGrid's version has five system roles: an Owner and Admins who run the workspace, Managers with full access scoped to their assigned groups, Users who see their own group's projects, and Executives with read-only access to everything. The scoping on the Manager role is the load-bearing part. A site CI manager gets full control of their site's portfolio and nothing else, which means you can delegate real authority without delegating the whole program.

The second tier lives inside a single project, and it splits into full access and contributor levels. Project Leaders and Associate Leaders edit everything: charter, milestones, financials. Champions, Mentors, Financial Reps, and Team Members contribute to-dos, notes, and files, but cannot rewrite the charter or the benefit figures. This is not bureaucracy. A charter that anyone can edit is not a charter, and a benefits ledger that anyone can edit will not survive its first finance review. Giving the controller's delegate a Financial Rep seat lets them inspect and challenge the numbers while the accountability for those numbers stays with the project leader.

The two tiers compose. An Executive can open any project in any group and read the discussion on any to-do, but posts nothing and edits nothing. A User who opens a project in their own group without being on the team gets contributor access automatically. Nobody needs a permissions request queue to do their job.

Give leadership visibility, not edit rights

The deployment governance guidance published by iSixSigma puts a steering committee of key stakeholders and process owners at the top of the structure, with an experienced Champion managing the people side of the change. What that guidance assumes, and what many programs skip, is that this committee can actually see the portfolio without commissioning a slide deck.

Make read-only executive visibility a structural feature, not a monthly reporting exercise. When the COO can open the program view and see every project's phase, lead, and financial position grouped by site, two things change. Status meetings stop being data transfer and start being decision-making. And practitioners stop maintaining a parallel PowerPoint version of reality, which is unpaid work that the systematic review would file under both motivation and knowledge management failures.

The What Is SixGrid? overview describes this as visibility without anyone assembling a slide deck first. At program scale, that is not a convenience. It is the difference between governance that runs on evidence and governance that runs on whoever writes the best summary.

Run governance through tollgates, not status meetings

A status meeting asks what happened. A tollgate asks for a decision. Phase-gate reviews at the end of each DMAIC phase, in which a sponsor and steering committee review the evidence and issue a go, no-go, or recycle decision, are the standard governance mechanism in Six Sigma deployment, and they are the program's real operating rhythm.

Practice varies on granularity. Some organizations hold one review per DMAIC phase, others gate individual deliverables within each phase. The phase-level gate is the right default for a new program: five decision points per project is enough governance to catch a drifting project and little enough that reviews stay substantive. A typical review runs 30 to 60 minutes: accomplishments against the phase's exit criteria, risks and mitigations, questions from the sponsor and stakeholders, then the decision.

Three rules keep tollgates honest:

1. Put the gates in the plan from day one. In SixGrid, tollgate rows sit directly in the milestone sequence of the methodology template, so every project carries its gates from creation and nobody schedules governance retroactively.
2. Review evidence that already exists. If the charter, metrics, and financials live in the system, the tollgate reads them there. The moment a tollgate requires a specially prepared deck, you have created a shadow reporting system.
3. Let the gate say no. A recycle decision that sends a project back into Analyze is the mechanism working, not failing. A program whose tollgates have never once said no does not have governance. It has ceremony.

Build an intake pipeline, not a suggestion box

Every program has more improvement ideas than capacity. The structural question is where those ideas live between being noticed and being chartered. In most organizations the answer is nowhere: ideas live in inboxes and hallway conversations, and project selection happens by whoever asks loudest.

The steering committee's selection role exists precisely to prevent this, and to stop separate teams from unknowingly attacking the same problem. But a committee can only select from a pipeline it can see. So make the pipeline a structural object. In SixGrid, any project left at Idea status appears automatically in the organization-wide Project Ideas view, sized by its Cost of Poor Quality figure. There is no separate intake form to fill in and no submission workflow to administer. An idea is simply a project that has not started, carrying an annualized dollar estimate of the opportunity it targets.

This does two things for governance. Selection becomes an allocation decision made against visible alternatives, ranked by opportunity size, instead of a first-come queue. And the unstarted pipeline itself becomes a program metric: the total identified-but-unworked opportunity is a number the steering committee can watch quarter over quarter, and a persuasive one when the program's budget is questioned.

Decide in this order

The four decisions interlock, and the sequence matters because each one constrains the next:

1. Boundaries. Decide the isolation unit (site, business unit, cohort) and create the groups before inviting anyone.
2. Roles. Assign scoped managers per group, read-only executives at the top, and the two-tier split inside projects.
3. Governance cadence. Put tollgates into the methodology template so every project carries the same gates, and stand up the steering committee that will sit in them.
4. Intake. Turn on the idea pipeline and route new opportunities into it, so selection is a governed decision from the first quarter onward.

Get these four right and the individual projects can fail safely: a bad project dies at a tollgate and the program continues. Get them wrong and even good projects underperform, because their results cannot be seen, compared, or trusted at the level where the program is judged. The Continuous Improvement hub covers the project-level disciplines that run inside this structure, from chartering to financial tracking.