How to Select Improvement Projects Worth Doing

The most expensive failure in continuous improvement is not the project that collapses in month three. It is the project that succeeds — on time, well documented, methodology impeccable — and changes nothing anyone cares about. Months of disciplined work aimed at the wrong target produce a well-organized irrelevance, and the organization draws the obvious, fatal conclusion: this method does not move the needle. The method was never the problem. The selection was.

Project selection is the least glamorous step in the improvement cycle and the most consequential. Done well, it aims scarce practitioner time at problems the business already feels. Done casually — projects chosen because someone was annoyed, a tool was exciting, or a department volunteered — it quietly caps everything that follows. DMAIC executes; it does not aim. Aiming is a separate skill, and it belongs to leadership.

What a worthwhile project looks like

Worthwhile projects share a profile. The problem is chronic — it has recurred long enough to have a history, not a one-time event with a known story. It is measurable — you can define the defect and count it. The cause is genuinely unknown — people have theories, and the theories disagree. It sits inside a process the organization runs repeatedly, so a fix keeps paying after the project ends. And it connects to something leadership already wants — cost, speed, quality, risk — so the result needs no explanation when it arrives. Miss any one of these and the project starts life owing a debt it may never repay.

Six filters before you charter anything

1. 01Business linkage — the problem connects to a goal someone above the team is already accountable for
2. 02Measurable defect — you can write the defect definition today and count occurrences tomorrow
3. 03Chronic, not episodic — the problem recurs; one bad month with a known cause is an anecdote, not a project
4. 04Unknown cause — if the solution is already known and merely needs doing, it is an implementation task; execute it, but do not dress it in DMAIC
5. 05Available data — records exist or can be collected within the project’s window, not after it
6. 06A named sponsor — one leader who owns the outcome, attends the gate reviews, and spends their capital when the project needs it

The filters are deliberately boring. Selection is not the place for vision; it is the place for arithmetic and candor. A candidate that passes all six is rare enough that finding one should feel like finding money. Notice what the filters do not include: how interesting the problem is, how loudly its victims complain, or how eager a team is to try a particular tool. Those are the forces that select projects when nobody is selecting deliberately — and they are the reason so many chartered projects were doomed on the day they were named.

The projects to refuse

Discipline in selection is mostly the discipline of refusal. Some candidates arrive pre-doomed, and accepting them costs more than declining them:

• Solutions in disguise — “implement the new scheduling software” is a decision wearing a project’s clothes; there is nothing to analyze
• Ocean boilers — “fix quality” and “improve communication” have no boundary and therefore no finish line
• One-off events — the cause died with the incident; hold a retrospective, not a project
• Orphans — no leader will put their name on the outcome, which predicts exactly how implementation will go
• Dead zones — the fix is already known to sit in territory the organization will not touch; a project cannot outrank the politics above it

Right-size the early portfolio

A young improvement program should select like an investor with no reserves: favor visible, winnable, short-cycle projects even when larger prizes beckon. Early wins buy the credibility that later, harder projects will spend. This is not timidity — it is sequencing. The boldest possible plan is a series of finished projects, each slightly larger than the last, each banked before the next begins. Programs die from one big stalled flagship far more often than they die from an excess of modest successes. There is a second reason to start small: early projects are also training grounds. A first-time Green Belt learning the method on a tightly bounded process can recover from a misstep. The same belt on a sprawling, politically loaded flagship cannot — and the program pays for both failures at once.

Build a hopper, not a lottery

Mature organizations do not select projects one at a time as irritation strikes. They maintain a hopper — a standing, scored list of candidate problems, refreshed as operations surface new pain and reviewed on a regular cadence. Each candidate carries an impact estimate and an effort estimate, however rough, and ranking follows. The hopper changes the conversation from “should we do this project?” to “is this the best project we could be doing?” — a much better question. It also makes stopping respectable: when a chartered project stops passing the filters, it returns to the hopper or dies. Killing a project that no longer deserves its team is not a failure of nerve. It is selection, working.

A good method can rescue a struggling project. Nothing rescues a project that should never have begun.

Learning to aim

Selection and chartering are where our Green Belt program begins, because they are where real projects begin — 35 hours built around a full simulated project from problem selection through control, ending in a 100-question proctored exam with one free retake and lifetime access, for $299. If you want the foundations first, the White Belt program is free: about six hours and a 30-question exam that will change how you look at every process you touch. The organizations that get improvement right are not the ones running the most projects. They are the ones running the fewest wrong ones.