The conversation about why AI implementations fail has become its own kind of noise. Bad data quality. Lack of executive buy-in. Change management gaps. These explanations are real, but they're downstream of a more fundamental problem that anyone with a process improvement background will recognize immediately: organizations are deploying solutions before they understand their problems.
Lean Six Sigma practitioners have a name for this. They call it skipping phases. And they have a framework - DMAIC - that was built precisely to prevent it. The AI world has largely ignored that framework, not because it doesn't apply, but because most AI thought leaders came from product and engineering backgrounds, not operations floors. They've never worked through a DMAIC project. They don't recognize the failure mode because they haven't been trained to see it.
I hold a Lean Six Sigma Green Belt. I've led process improvement work across fleet operations managing an $89M market. And when I look at the way most AI implementations are structured, I see the same category of mistake being made, at scale, over and over again.
When I was tasked with reducing overtime costs at the fleet operation I managed, the instinct in the room - the instinct most rooms have - was to find the solution first. A better scheduling system. A smarter allocation tool. Something that could automate the decision-making that was driving costs up.
That instinct is almost always wrong, and Lean Six Sigma is built around the recognition that it's wrong. The methodology exists because decades of process improvement work showed that organizations consistently jump to solutions before understanding root causes. The result is predictable: well-executed solutions to the wrong problems.
Before any tool or intervention was selected, we pulled two years of overtime data and ran SQL-based root-cause analysis to understand where the overtime was actually occurring - not where it appeared to be occurring, but where it was truly concentrated when you sliced it by role, location, shift pattern, and day of week. The overtime wasn't distributed the way anyone in the room had expected. It was clustering in specific conditions that only became visible when you looked at the intersections in the data.
That analysis phase took weeks. The result was a 23% reduction in overtime costs - roughly $221K annually - because the interventions that followed were aimed at the actual root causes, not the assumed ones.
No AI tool was at the center of that outcome. The discipline that made it possible was DMAIC.
DMAIC stands for Define, Measure, Analyze, Improve, Control. In Lean Six Sigma practice, these phases are sequential and each one gates the next. You do not move to Improve until you have completed Analyze. You do not move to Analyze until you have completed Measure. The sequence exists because each phase produces the inputs that make the next phase meaningful.
Here is what that looks like in practice - and where AI implementations break down at each step.
Define is the phase where you establish exactly what process you are improving, who it affects, what the boundaries of the problem are, and what success looks like in specific, measurable terms. "We want to use AI for grant reporting" is not a Define. A real Define sounds like: "Our grant reporting process requires 40 staff hours per quarter per grant, with a 30% error rate on financial reconciliation. We want to reduce hours to 15 and errors to under 5%." That specificity isn't bureaucratic overhead - it's the foundation that every subsequent phase builds on.
Most AI projects skip Define entirely. They start with a technology and work backward to a use case rather than starting with a problem and working forward to the right tool.
Measure is the phase where you document current-state performance in data. What is the baseline? How long does the process take today? What does quality look like before the AI touches it? Without a measured baseline, you cannot prove that the AI improved anything. You are also flying blind about what you are actually trying to beat.
In my fleet operation work, the Measure phase meant building the data infrastructure to see overtime at granular resolution - not just the total figure, but the distribution across every relevant dimension. The Power BI dashboards and SQL pipelines I built during this work were not optional overhead. They were the Measure phase made operational. They are also the foundation that made Control possible later.
Most AI projects skip Measure. The AI goes live, it produces outputs, and there is no baseline against which to evaluate whether those outputs represent an improvement. Six months in, the team believes the AI is working because nobody documented what "not working" looked like.
Analyze is where you investigate root causes before selecting a solution. This is the phase that Lean practitioners most consistently identify as the one organizations want to rush. It feels like delay. It looks like research rather than progress. But it is the phase that determines whether your solution addresses a real problem or an assumed one.
In the overtime reduction project, the Analyze phase revealed that the clustering pattern was tied to specific shift transition conditions that were invisible in the aggregate numbers. An AI scheduling tool deployed before that analysis would have been optimizing for the wrong variables - because the right variables hadn't been identified yet.
Most AI projects skip Analyze. The assumption is that the AI will figure out the root causes as part of its optimization. This is occasionally true for narrow, well-defined problems. It is almost never true for complex operational processes where the failure mode is embedded in how the work is structured, not just how it is executed.
Improve is the phase where the solution gets designed, tested, and deployed. This is where AI tools belong - after the first three phases have produced a clear problem definition, a measured baseline, and a root-cause analysis that points toward specific intervention targets. At this point, tool selection becomes substantially clearer because you know what the tool needs to accomplish.
The AI industry lives almost entirely in the Improve phase. Conferences, vendor pitches, implementation guides - they almost all assume that the Define, Measure, and Analyze work has been done. It almost never has.
Control is the phase that prevents the gains from eroding. It means building ongoing monitoring, establishing governance ownership, creating alerts for performance degradation, and periodically reviewing whether the improvement is holding. In the fleet operation, Control meant Power BI dashboards that surfaced overtime patterns in near-real-time, with defined thresholds that triggered review.
Most AI deployments have no Control phase. The model goes live, the project team disbands, and the ongoing performance of the system is nobody's explicit job. Model drift - the gradual degradation of model performance as real-world conditions shift - goes undetected because there is no monitoring baseline and no governance owner watching for it. This is not a technology problem. It is a project structure problem that DMAIC was designed to prevent.
The practical implication is straightforward, even if acting on it requires discipline that runs against the current pressure to move fast.
Before any AI project starts, Define the process you are actually trying to improve with the specificity that would survive scrutiny: what does it do, who does it serve, what does success look like in measurable terms, and what is currently preventing that outcome. If you cannot answer these questions, you are not ready to select a tool.
Before any AI goes live, Measure the current-state performance in data that will survive comparison later. If you skip this step, you are giving up your ability to prove the AI worked - and your ability to detect when it stops working.
Before any AI is designed, Analyze why the current process performs the way it does. The root causes are rarely where initial assumptions place them. The data analysis phase - whether that is SQL-based investigation, process mapping, or structured observation - is what separates an intervention aimed at the real problem from one aimed at the visible symptom.
When the AI goes live, treat Control as a deliverable, not an afterthought. Assign governance ownership. Build monitoring that compares performance against the Measure-phase baseline. Create a review cadence. Without this, you are building on a foundation that will erode.
For nonprofits specifically, this framing matters because the resource pressure to skip to Improve is highest where capacity is lowest. Grant-funded AI implementation projects almost never include the Define, Measure, and Analyze work - it doesn't look like progress, and it doesn't fit neatly into a grant deliverable. But nonprofits that skip these phases spend more on cleanup, re-implementation, and abandoned tools than they would have spent on doing the analysis work upfront.
The phrase I keep coming back to from Lean practice is simple: automate a broken process and you get a faster broken process. Process improvement practitioners have understood this for three decades. The AI industry is currently learning it at significant organizational cost.
DMAIC is not a methodology that requires a Six Sigma certification to apply. It is a logic for sequencing the work of improvement in a way that makes success measurable and sustainable. The five phases exist because organizations, left to their own instincts, will skip the hard analytical work and go straight to the visible solution.
AI implementations are not a different category of organizational problem. They are process improvement problems in new clothes. The framework that has been successfully applied to manufacturing lines, logistics operations, healthcare workflows, and retail supply chains applies here too.
The question worth sitting with: at which phase does your organization's AI project currently live - and what would it look like to go back and do the earlier phases properly?