Most Lean Six Sigma programs don’t fail because of bad tools or weak training. They fail because the wrong project got picked first. A Black Belt spends four months on a process nobody cares about, the results are marginal, and leadership loses interest in the whole initiative before it ever proves its worth. Solid lean six sigma project selection criteria prevent that outcome by forcing you to vet ideas against real business impact before anyone touches a DMAIC chart.
This article gives you the seven factors experienced Black Belts and deployment leaders actually use to separate strong projects from time-wasters, including financial impact and data availability. You’ll see how to weigh customer impact against effort required, why leadership sponsorship changes a project’s odds of survival, and how scope size determines whether a team finishes in weeks or drags on for a year.
We’ve built training and consulting programs around these exact filters for over a decade, working with manufacturing plants, corporate service teams, and law enforcement agencies. What follows isn’t theory. It’s the practical checklist we use before greenlighting any improvement effort, so your next project gets picked for the right reasons and delivers a result that’s easy to measure and easy to defend.
1. Strategic alignment with organizational goals
Every project you consider should trace back to something leadership already cares about, whether that’s a cost target, a customer complaint trend, or a strategic initiative on the CEO’s scorecard. Strategic alignment is the first filter because it decides whether your finished project gets celebrated or ignored.
What it means
Strategic alignment means the problem you’re solving connects directly to a stated organizational priority, not just a process that annoys the team working in it. If your hospital system has publicly committed to cutting patient wait times, a project targeting discharge delays fits. A project reducing supply closet clutter, however useful, doesn’t carry the same weight. Organizational priorities usually live in annual reports, strategic plans, or the goals your plant manager or VP repeats in every meeting. Match your project charter language to that same vocabulary.
Why it matters
Projects tied to top-level goals get funded faster, get resources released faster, and get protected when budgets tighten. Leadership sponsors what they already believe matters, and they lose patience with initiatives that don’t connect to what they’re being measured on themselves.
A Lean Six Sigma project that doesn’t map to a stated business goal is a project waiting to get cut.
We’ve watched well-run projects get shelved mid-cycle simply because nobody could explain how they moved a metric the executive team tracked. Alignment isn’t a paperwork exercise. It’s the difference between a project that survives a budget review and one that gets quietly killed.
How to evaluate it
Before drafting a charter, run every candidate project through a short alignment test:
- Name the strategic goal it supports (cost reduction, quality score, customer retention, safety compliance).
- Identify the executive sponsor who would recognize the connection without explanation.
- Check the metric overlap. Does the project move a number that’s already on someone’s dashboard?
- Confirm timing. Does this fit the current fiscal year’s priorities, or is it solving yesterday’s problem?
If you can’t answer all four in under five minutes, the project probably needs more scoping work, or it belongs lower on the priority list, before your team invests a single hour in data collection.
2. Measurable financial and operational impact
Once a project clears the strategic filter, the next question is simple: can you put a number on it? Financial impact is what turns a good idea into a funded project, and it’s one of the core lean six sigma project selection criteria that separates a real initiative from a wish list item.
What it means
Measurable impact means you can attach a dollar figure, a cycle time reduction, or a defect rate drop to the outcome before you start. Hard savings like reduced scrap, lower overtime, or fewer warranty claims carry more weight than soft benefits like "improved morale." A project that saves $150,000 a year in rework costs is easy to defend. A project that "might help communication" isn’t.
Why it matters
Finance and operations leaders fund what they can track. Projects with clear, quantifiable targets get budget approval faster and keep sponsors engaged through the inevitable rough patches in a DMAIC cycle.
If you can’t put a number on the outcome, you can’t defend the project when budgets get tight.
Teams that skip this step often finish a project and struggle to prove it mattered, which quietly damages the credibility of the entire program.
How to evaluate it
Before approving a project, require a written estimate covering:
- Projected annual savings or revenue impact, in dollars
- Baseline metric and the target improvement percentage
- Time to break-even on the project’s cost
If the team can’t produce rough numbers within a day of scoping, the project needs more definition before it earns a spot on the pipeline.
3. Availability of reliable, quantifiable data
A project can align with strategy and promise a strong return, but if nobody can measure the current process, you’re stuck before you start. Data availability is one of the lean six sigma project selection criteria teams overlook until they’re three weeks into Measure phase with nothing solid to show.
What it means
Reliable data means the process already generates numbers you can pull, or you can capture them cheaply within a few weeks. That includes transaction logs, defect counts, cycle time stamps, or inspection records sitting in an existing system. Quantifiable baselines don’t have to be perfect, but they need to exist somewhere other than someone’s memory of "it usually takes about a week."
Why it matters
DMAIC runs on data. Without a trustworthy baseline, you can’t prove improvement, calculate a defects-per-million-opportunities rate, or run basic statistical tests. Teams that pick data-starved projects end up spending half the project timeline just building a measurement system, which burns momentum and sponsor patience.
No baseline, no proof of improvement, no credit for the work.
How to evaluate it
Run a quick data audit before committing a team:
- Locate the source system (ERP, MES, ticketing tool, spreadsheet log) that already tracks the metric
- Check history depth. Do you have at least 3 to 6 months of usable records?
- Assess data quality. Are entries consistent, or does every department define the metric differently?
- Estimate collection cost. If data doesn’t exist, how many weeks and dollars to build a reliable capture plan?
If the answer to that last question stretches past a few weeks, reconsider the project’s place in your pipeline.
4. Manageable scope and realistic timeline
A project can pass every other filter and still collapse under its own weight if the scope keeps growing. Scope creep is the quiet killer of Lean Six Sigma initiatives, turning a 90-day project into a year-long slog nobody remembers approving.
What it means
Manageable scope means the project targets one process, one defect type, or one customer segment, not an entire department’s workflow. A charter that says "reduce order-to-cash cycle time in the Midwest distribution center" is scoped. One that says "fix supply chain efficiency company-wide" isn’t. Realistic timelines usually run 60 to 120 days for a Green Belt project and up to six months for a complex Black Belt effort. Anything longer needs to be broken into phases.
Why it matters
Large, undefined projects lose sponsor attention long before they finish. Teams get pulled onto other priorities, the original problem shifts, and the data collected in month one no longer matches reality in month six.
A project too big to finish in a quarter is really three projects wearing one charter.
Tight scope also makes results easier to measure and defend, since fewer variables muddy the before-and-after comparison.
How to evaluate it
Use this quick scope check before finalizing the charter:
- Single process boundary. Can you draw a clear start and end point on a SIPOC diagram?
- Team capacity. Does the core team have four to eight hours a week available, realistically?
- Milestone spacing. Can you define Measure, Analyze, and Improve checkpoints inside 90 days?
- Escalation trigger. Who decides if the scope needs to shrink once work begins?
If the charter reads more like a mission statement than a project plan, cut it down before assigning a belt.
5. Stakeholder support and resource availability
A project can have perfect data and a tight scope, but it still needs people willing to show up and do the work. Stakeholder support is one of the lean six sigma project selection criteria that gets assumed rather than verified, and that assumption sinks more projects than bad math ever does.
What it means
Stakeholder support means the process owner, frontline team, and immediate supervisor all agree the problem is worth solving and are willing to free up time for it. Resource availability covers the practical side: a trained Green Belt or Black Belt, access to subject matter experts, and a budget line for any tools or software the team needs. Without both, a charter is just a document.
Why it matters
Process owners who feel a project was forced on them tend to slow-walk data requests and skip improvement meetings. Teams without a dedicated belt or protected hours default to "whenever we get to it," and the project stalls indefinitely.
A project with no committed resources isn’t a project, it’s a wish.
Sponsors notice which initiatives move fast and which ones drift, and that pattern shapes whether they fund the next round of improvement work.
How to evaluate it
Confirm three things before assigning a team:
- Written commitment from the process owner to participate in data collection and reviews
- Named belt or facilitator with hours already blocked on their calendar
- Budget or tool access confirmed, not just assumed available
Skip any project where the answer to these is "we’ll figure it out later."
6. Feasibility and risk of implementation
Even a well-scoped, well-funded project can create more problems than it solves if the fix itself is risky or impractical. Implementation feasibility is the last checkpoint before you commit a team, and it catches the projects that look great on paper but fall apart once you try to change anything on the floor.
What it means
Feasibility means the likely solution fits within your regulatory, technical, and cultural constraints. A project that requires rewriting FDA-regulated procedures or replacing a core ERP module carries more implementation risk than one that adjusts a work instruction or reorders a workstation layout. Implementation risk also includes the human side: how much resistance you expect from the team whose routine is about to change.
Why it matters
Projects that require sweeping approvals, capital investment, or union negotiation often stall in the Improve phase, regardless of how solid the analysis was. Teams that ignore this factor sometimes finish a flawless Analyze phase and then wait six months for a change control board to approve a fix.
A brilliant solution nobody can implement isn’t a solution, it’s an academic exercise.
How to evaluate it
Walk through this checklist before committing to a project:
- Regulatory exposure. Does the likely fix touch a compliance-controlled process?
- Capital requirement. Will the solution need equipment, software, or facility changes beyond a normal budget line?
- Change resistance. Has this team resisted similar changes before, and is there a plan to manage that?
- Approval chain. How many sign-offs stand between a validated improvement and actual implementation?
If the answers point to a long, uncertain approval path, weigh that risk against the project’s expected payoff before you commit a belt’s time to it.
Choosing your next project with confidence
Six filters won’t guarantee a perfect project, but skipping them almost guarantees a wasted one. Strategic alignment, financial impact, data availability, scope, stakeholder support, and implementation feasibility catch the problems that sink initiatives before a single DMAIC tool gets used. Run every candidate through these checks and you’ll spend less time defending your choices to leadership and more time delivering results they actually notice.
Most teams don’t need more training on statistics. They need a disciplined selection process that stops good people from working on the wrong problems. Build that discipline into your project pipeline now, and every belt you certify afterward will have a real shot at proving their worth.
If you want help building that pipeline, from selection criteria through certification and staffing, contact our team and we’ll walk through what a stronger project queue looks like for your organization.