The post-mortem on a failed AI implementation almost always sounds the same. The technology didn't perform as expected. Adoption was low. The ROI never arrived. The vendor gets blamed, or the timing, or the team's readiness for change.
What rarely gets named is the actual cause: the process that the AI was supposed to improve was never defined, measured, or corrected before the tool was deployed. The failure didn't happen when the tool went live. It happened in the months before; when the organization skipped the work that makes AI worth deploying at all.
This isn't a technology problem. It's a sequencing problem. And until we talk about it strategically, organizations, especially those with limited resources that cannot afford a failed implementation will keep making the same mistake.
As you may know, or not know, the Lean Six Sigma's DMAIC framework - Define, Measure, Analyze, Improve, Control is one of the most widely cited process improvement methodologies in operations. Most people in business have heard of it. Far fewer apply it correctly when it comes to AI adoption.
Here's the issue: AI belongs in the Improve phase. That's where technology-driven solutions such as: automation, machine learning, intelligent routing, predictive analytics have their maximum impact. The Improve phase is where you redesign how the work gets done, with the best tools available to you.
But the Improve phase only works if you've completed the three phases before it.
Define means you can describe the current process step by step, in writing, without referencing the tool you want to deploy. You know what the inputs are, what the outputs are, who touches it, and where the decision points live. If you can't document the current state, you can't design a better one.
Measure means you have quantifiable data on how the process performs today. Not impressions or general feedback - actual numbers. Cycle time, error rate, cost per unit, volume by day and shift. Without a baseline, you have no way to prove that the AI improved anything, and no way to detect when it's making things worse.
Analyze means you've identified where and why the process breaks down. Not where you assume it breaks down - where the data shows it breaks down. This is the phase most organizations skip hardest. They see a pain point, select a tool that addresses it, and call that analysis. It isn't. Root cause analysis "the real kind" requires sitting with data until you understand the mechanism behind the problem, not just its surface symptoms.
Most AI implementations jump straight to Improve without meaningful input in Define, Measure, or Analyze. Leading to a sophisticated tool running on a process that was never understood in the first place.
In early 2022, the operation I managed was running excessive overtime. The cost was significant and climbing. The instinct, which was shared by most of leadership, was that this was a staffing problem. Headcount was for sure the answer. Tools to optimize scheduling were being evaluated.
I pulled the data instead.
Over the following three months, I built SQL queries that cross-referenced scheduling patterns against customer demand signals, fleet availability, and shift coverage windows. The goal wasn't to confirm what we already believed - it was to find out what was actually happening.
The overtime wasn't distributed where leadership assumed it was. The inefficiency was structural: shifts were being assigned in patterns that didn't align with when demand actually peaked. The problem wasn't headcount. It was sequencing. And it was invisible to gut feel, completely visible to SQL.
We restructured the scheduling logic based on what the analysis revealed. Over the next six to eight months, overtime costs dropped 23% - approximately $221,000 recovered annually. No AI scheduling tool was purchased. No new headcount was added. The process was defined, measured, and analyzed before anything was changed.
Here's the version of that story that doesn't go that way: leadership decides the problem is scheduling inefficiency, purchases an AI-powered scheduling tool, and deploys it against the same broken logic. The tool does its job. It automates the broken pattern consistently, at scale, faster than any human could. The overtime doesn't decrease. It might increase. And now there's a contract with a vendor and an organizational commitment to a tool that's actively replicating the problem.
This is not hypothetical. It's what happens when organizations skip the Analyze phase.
The dynamics I've described play out across industries, but nonprofits face compounding challenges that make premature AI adoption particularly costly.
Resource constraints are the obvious factor. A failed AI implementation in a 500-person corporation is a line item. In a 50-person nonprofit, it can be a material portion of an annual budget and months of staff capacity that could have gone toward mission-critical work. The margin for error is structurally smaller.
But the deeper issue is process maturity. Many nonprofit operational processes evolved organically, built on institutional knowledge and the capability of whoever happened to be in the role at the time. Grant reporting happens in spreadsheets because that's what was available when the process was built. Donor data lives in a CRM that hasn't been updated in a decade because the organization can't afford to migrate. Program outcomes are tracked inconsistently because there's never been the bandwidth to standardize the approach.
These are not technology problems. They're process problems. And dropping an AI layer on top of them doesn't resolve the underlying inconsistency, it operationalizes it.
The right sequence for nonprofits, as with any organization, is to document the process first. Measure what's happening now. Find where it breaks. Then, and only then, evaluate whether AI belongs in the solution and what kind of AI, and where to apply it.
After nearly a decade of working in operations, I've landed on three questions that I run before recommending any technology investment. They're not complex. They're just honest.
Can you document the process without the tool? Describe the current state end to end: i.e. inputs, steps, decision points, handoffs, outputs. Write it down. If you can't, you're not ready for AI. The tool will be making decisions inside a process that no one fully understands. That's not an upgrade.
Do you know exactly where it breaks down, and why? Not approximately. Not based on who complains the loudest. Where, specifically, does the process generate errors, delays, or waste, and what's the mechanism behind it? The $221,000 in overtime savings came from answering this question with data, not assumption. That's the Analyze phase. It takes longer than selecting a vendor. It's worth significantly more.
Is your data consistent and measurable enough to feed the tool? Garbage in, garbage out is a maxim that gets repeated constantly in data circles, but it's usually applied to data quality in a narrow sense. The more relevant question is consistency. Does your process generate structured, reliable, measurable outputs that an AI system can learn from and act on? If the process itself produces variable, undocumented outputs, the AI will train on that variability and systematize it.
If you can answer all three questions clearly, you're in the Improve phase. If you can't, you're still in Define, Measure, or Analyze - and knowing that is the most valuable thing you can know right now.
There's a version of the AI conversation that treats the technology as the variable: "which model", "which platform", "which vendor", "which use case". That conversation will continue to consume an enormous amount organizational energy for the foreseeable future.
The more useful conversation is about sequencing. AI is genuinely capable of improving operations in ways that weren't possible five years ago. But capability doesn't equal readiness. A tool that can do remarkable things applied to a process that was never defined will produce remarkably consistent problems.
The organizations that will extract durable value from AI are not necessarily the ones that move fastest. They're the ones that do the process work first; that define, measure, and analyze before they improve and deploy technology against a problem they actually understand.
That's not a conservative position on AI. It's the position that makes AI work.
Damarius McNair is an operations and analytics leader with 8+ years scaling fleet and retail operations through data-informed process design.