Most operational excellence advice tells you what excellence looks like. This guide tells you how to actually run the program that gets you there, week by week, without it collapsing into a slide deck nobody reads by month three.

A program is not a philosophy. It is a defined effort with a start date, a small set of problems it will fix, named owners, a measurement baseline, and a cadence that keeps it moving. If you cannot point to those five things, you do not have a program. You have good intentions.

The order below matters. Skip the baseline and you will argue about whether anything improved. Skip the scope and you will boil the ocean. Skip the cadence and the whole thing decays the moment your attention moves on. Here is how to do it properly.

What a working program actually looks like

The deep frameworks behind this, lean and the Toyota Production System, Six Sigma, kaizen, and the maturity models, are covered in the companion piece on operational excellence as a discipline. This guide assumes you already believe the ideas and now need to execute them.

A working program has a spine: one clear problem statement, a number that has to move, an accountable owner, and a review rhythm where progress is inspected in person. Everything else hangs off that spine. Programs fail when teams buy the tools first and never write the problem statement.

Strong looks like a single sentence on a wall: "Order-to-ship time is 6 days; we will get it under 3 by Q3, owned by the fulfilment lead." Weak looks like "we are rolling out Six Sigma across the company." The first is testable; the second is a press release.

Step 1 — Set an honest baseline before you change anything

You cannot improve what you have not measured, and you cannot prove you improved it without a "before" number. So the first week is not action. It is measurement.

Pick the two or three metrics that reflect how the business actually delivers value: cycle time (request to done), throughput (completed per week), defect or rework rate, and cost per unit. Measure them for long enough to see normal variation, usually two to four weeks, not a single good day.

Strong baselining pulls real numbers from the actual system, warts and all: "average cycle time is 6.2 days, but 15% of orders take over 12 days." Weak baselining asks a manager for their impression and writes down "about 5 days," a soft number nobody trusts the moment you try to improve it. If your systems cannot report the number cleanly, that itself is a finding and a good early win. The disciplines for turning raw operational data into reliable numbers live in the data-driven operations guide.

Step 2 — Scope ruthlessly: pick one or two problems worth solving

The biggest mistake COOs make is launching a program against everything at once. Excellence is earned one bottleneck at a time. Choose problems using two filters: how much pain the problem causes and how solvable it is in a quarter.

Two things fall out of this. First, you deliberately defer the big, slow, expensive problems so they do not swallow the program; they get their own plan and timeline. Second, you visibly ignore the trivial stuff so the team knows this is about material outcomes, not tidying. Strong scope names one or two problems. Weak scope lists fifteen "focus areas," which is another way of saying no focus at all.

Step 3 — Charter the work and name a single owner

Every problem you take on gets a one-page charter: the problem statement, baseline, target, deadline, owner, and who does the work. One owner, not a committee. A committee is where accountability goes to die.

Use a simple responsibility model so nobody is confused about their role. RACI (Responsible, Accountable, Consulted, Informed) works well here: exactly one name in the Accountable column per problem. The owner need not do all the work, but they own the number and show up to every review with the current status.

Strong chartering makes the owner a line manager who controls the resources needed, so they can actually act. Weak chartering appoints a junior "program coordinator" with responsibility but no authority, then wonders why nothing moves. If you want the change to stick across departments, pair the charter with the discipline in change management strategies, because most operational fixes fail on adoption, not design.

Step 4 — Run the improvement loop, small and fast

Now you improve, in short cycles, not one giant rollout. The engine is PDCA (Plan, Do, Check, Act), or its more data-heavy cousin DMAIC (Define, Measure, Analyse, Improve, Control) from Six Sigma. Both say the same thing: change one thing, measure it, keep what worked, discard what did not, repeat.

The discipline is to test at small scale first. If a new routing rule should cut order time, run it on one product line or shift for two weeks before you inflict it on everyone. A change that looks brilliant on a whiteboard often breaks on real volume, and a small test costs a fortnight instead of a quarter.

Strong loops close in weeks: a change is proposed Monday, tested on one line, measured, and either standardised or killed inside a month. Weak loops are annual big-bang rollouts nobody dares measure honestly. Most of your wins come from mapping the actual workflow and removing wasted steps, which is the core of process optimization, before you spend a cent on new technology.

Step 5 — Standardise the win, or it evaporates

A fix that lives in one person's head is not a fix. The moment a change works, you write it down as the new standard way of doing the work, a short SOP, a checklist, a changed screen, and you train everyone who touches that process.

This is the step that separates a real improvement culture from a hero culture. In a hero culture, your best operator quietly does things the smart way and results dip the week they are on holiday. In a strong program, the smart way is the documented default, so a new hire follows it without knowing it was ever a problem.

Strong standardisation makes the improved process the path of least resistance: the old way is genuinely harder to do than the new way. Weak standardisation emails a PDF that nobody opens and hopes people remember. Where the standard is about defect prevention and consistency, formal systems like ISO 9001 or the practices in the quality management guide give you an auditable backbone rather than tribal memory.

Step 6 — Build the cadence that keeps it alive

Programs die from lost attention, not bad ideas. The countermeasure is a fixed review rhythm that does not depend on anyone remembering to schedule it.

Run a short, standing review, weekly for active problems and monthly for the overall program, where each owner reports the current number against target in a few minutes. Keep it visible: a simple board (physical or digital) showing each problem's baseline, target, and this week's actual. When a number stalls for two reviews running, that is the signal to change the approach, not defend it.

Executive time is the scarcest, most expensive input here: with US chief executives earning a median of around \$206,420 a year (BLS, May 2024), the cadence has to be tight and decision-focused. Strong cadence is 25 minutes where three decisions get made. Weak cadence is a 90-minute meeting where everyone reads slides aloud and nothing is decided.

Weak vs strong: how to spot theatre from a working program

The pattern is clear: strong programs are specific, small-batch, owned, and measured; weak programs are vague, big-bang, shared, and vibes-based. Keep an eye on which side each of your six steps sits on, and you will catch decay early. For choosing which numbers to track and how to report them upward, the operations metrics guide goes deeper than we can here.

Key takeaways

• A program needs five concrete things: a problem statement, a baseline, a target, one owner, and a review cadence. Missing any one and it is not a program.
• Measure the "before" honestly, from real data, before you change anything. A soft baseline makes every later claim of improvement arguable.
• Scope to one or two solvable, high-pain problems per quarter. Deliberately defer the big slow projects and ignore the trivial ones.
• Improve in small, fast loops (PDCA or DMAIC). Test at small scale before any wide rollout.
• Standardise every win into the documented default, or it evaporates the week your best operator is away.
• Protect the cadence. Programs die from lost attention, not bad ideas.

Frequently asked questions

How long should a program run before I see results? Your first small-scale wins should appear within four to eight weeks, because you are testing changes on one line, not the whole company. A meaningful shift in a headline metric like cycle time usually takes a quarter. If nothing has moved in three months, the cause is almost always scope (too broad) or ownership (no one truly accountable), not effort. What is the difference between operational excellence and just cutting costs? Cost cutting removes spend, often at the expense of quality or capacity, and stops the moment the target is hit. Operational excellence removes waste and variation from how work is done, so cost falls as a by-product and the gain compounds. A cost cut is a one-off event; a program builds a repeatable habit of fixing the next bottleneck. Do I need Six Sigma or lean certification to run a program? No. Certification helps for complex statistical problems, but the six steps here work without any certified belt in the room. Start with the discipline and the small-batch loop. Bring in formal Six Sigma or lean training when a specific problem genuinely needs the deeper toolkit, not as a prerequisite for starting. What are the most common reasons these programs fail? Three failures dominate: no honest baseline (so improvement cannot be proven and support evaporates), scope that is too broad (fifteen focus areas means none), and a review cadence that quietly lapses once the executive's attention moves elsewhere. All three are about discipline; protecting the weekly review matters most. Who should own the program, the COO or a dedicated program manager? The COO owns the program overall and sits in the reviews, because their authority is what unblocks cross-department problems. Each individual problem, though, needs a single accountable line manager who controls the relevant resources. A program coordinator can run the mechanics, but accountability for each number must sit with someone who can actually change the process. How do I stop the gains from slipping back after the program winds down? Standardise (Step 5) and keep a lightweight cadence running (Step 6) even after the headline target is hit. The most durable protection is making the improved process the path of least resistance. Fold a short monthly check of your key metrics into normal operations, so any regression shows up as a number before it becomes a crisis.