They Approved the AI Pilot at the End of a Twelve-Hour Day. That Is Where It Went Wrong.

Quick answer

A depleted leader does not write the problem statement before approving the vendor. They approve the vendor, then write the problem statement around the purchase. Decision fatigue shifts selection criteria from 'what solves the actual problem' to 'what reduces the pressure I feel right now.' The team inherits the result: an AI initiative whose success criteria nobody can defend, scoped around a symptom, launched without a documented baseline, measured by whatever the vendor proposed.

TL;DR

Five figures you need before reading further.

• Most AI projects fail before the build starts

  More than 80% of enterprise AI projects fail to deliver intended business value, roughly twice the failure rate of non-AI IT projects (RAND Corporation, 2024).

• Leadership drives the failure, not technology

  Data scientists and engineers interviewed by RAND cited leadership decisions and expectations as the primary reason AI projects fail. Technology limitations ranked far lower (RAND Corporation, 2024).

• Abandonment is accelerating sharply

  The share of companies abandoning most of their AI initiatives rose sharply in 2025. S&P Global Market Intelligence reported that organizations scrapped nearly half of AI proofs of concept before they reached production (S&P Global Market Intelligence, 2025).

• GenAI pilots return almost nothing

  95% of organizations running generative AI pilots saw zero measurable return on the income statement. Only 5% captured value at scale (MIT Project NANDA, 2025).

• The scoping problem precedes everything else

  RAND's root-cause analysis identifies misunderstood or miscommunicated problem definition as the first and most damaging failure pattern: AI models trained on the wrong metrics, optimized for the wrong outcome, never connected to the actual business workflow (RAND Corporation, 2024).

The moment the scoping decision actually happens

In August, I had a Wednesday where I delivered three one-hour training sessions, ran a production deployment, fielded two kickoff calls, and firefighted production bugs simultaneously. I knew that day was coming. I had cleared most of my Monday calendar deliberately so I had space to plan and pace before the load hit. I did not eliminate the hard day. I protected the thinking time that preceded it. I tell you that because the leader this piece is about did not do that. They did not have a protected Monday. By Tuesday at 6:47 p.m., after back-to-back calls since 8 a.m. and 34 unread emails, the vendor proposal had been sitting in their drafts folder for nine days. The manager had asked about it that morning. They opened the deck, skipped to the pricing page, typed 'looks good, let's move forward,' and closed the laptop. They had planned to block two hours on Thursday to write a real problem statement and read the SOW. They told themselves they could do that after the contract was signed. This is a scoping story. The problem definition just got written around a purchase rather than before it. And the project, from this point forward, will spend its energy defending that backwards sequence rather than solving the original problem. Before the research, I want to name what happened in those 90 seconds between opening the deck and typing 'looks good.' Because this piece is about that internal negotiation. The one where you know you said you would do the work Thursday, and you know you probably won't, and you build a case anyway: the contract is already mostly decided, the manager is waiting, the vendor has been patient, it's close enough. Rationalization is the word for that. And the project pays for it for the next six months.

What cognitive depletion does to a scoping decision specifically

Cognitive science is clear on the mechanism. Decision fatigue is the tendency to make less effortful decisions as the cumulative mental burden of decision-making increases (Health Psychology Review, 2025). Under sustained cognitive load, the brain defaults to heuristics: simpler, faster, pattern-matched choices that reduce the effort required in the moment. For an executive scoping an AI pilot, that default looks like this: they select the solution that most directly reduces the pressure they are currently feeling, rather than the solution that addresses the underlying operational problem. The two are rarely the same thing. Research published in the Journal of Novel Research and Innovative Development (2025) found that cognitive load and decision fatigue impair executive judgment by increasing vulnerability to cognitive biases and reducing the capacity for analytical problem-solving and self-regulation. For a technology purchase, this translates to a very specific failure: the criteria that should drive scope (what problem are we solving, for whom, measured how, by when) get replaced by a single criterion that is never written down: does this reduce what I am feeling right now. Jia et al. (2022) found that mentally fatigued individuals consistently prefer low-risk, low-return options over high-risk, high-return ones. In a vendor selection context, 'low risk' means the option that requires the least additional cognitive work from them: the vendor who sent the nicest deck, who already has a relationship in the building, whose proposal is the clearest to skim. None of that internal processing is visible from the outside. The decision looks like a decision. It does not look like a commitment broken.

The problem statement gets written after the fact

RAND's 2024 root-cause analysis, based on interviews with 65 experienced data scientists and engineers, names this pattern precisely: industry stakeholders often misunderstand or miscommunicate what problem needs to be solved using AI. Too often, AI models are deployed optimized for the wrong metrics or built without fitting into the actual business workflow. RAND's report goes further. Business leaders, it notes, may say they need an ML algorithm that tells them the price to set for a product. What they actually need is the price that gives the greatest profit margin, which is a different optimization entirely. The technical team builds what they were told. The business leader never realized the distinction mattered. The project fails on the outcome metric the business actually cared about, even though the model performed exactly as specified. This is the scoping failure. It is not a technology failure. It happens in the room, in the conversation, or in the nine-day silence where the conversation never happened at all. When the problem statement gets written around the purchase rather than before it, a second failure follows immediately: the success criteria come from the vendor's proposal rather than from an internal baseline. The team then spends the implementation trying to prove success by the vendor's definition, not by the operational outcome the business actually needs.

The retail context makes this worse

Retail operations leaders are under specific pressure that amplifies every dynamic above. NVIDIA's State of AI in Retail and CPG found that 97% of retailers plan to increase AI spending in the next fiscal year, and NRF's 2025 research confirmed near-universal budget commitment at the C-suite level (NVIDIA State of AI in Retail and CPG, 2025; NRF, 2025). The board has already signaled that AI is a priority. For the VP carrying the implementation, that signal creates a secondary pressure: demonstrate progress. Get something approved. Show the board something is moving. RAND identified exactly this dynamic: managers and directors find themselves under enormous pressure to do something, anything, with AI to demonstrate to their superiors that they are keeping up (RAND Corporation, 2024). So the scoping decision happens under two simultaneous pressures: the operational pressure of a day that started at 8 a.m. and has not stopped, and the organizational pressure of needing to show the room above them that AI is being addressed. Both pressures point in the same direction: approve something now, figure out the problem statement later. Retail-specific friction adds a third layer. Pertama Partners' analysis of enterprise AI implementations notes that retail contends with demand volatility that erodes model accuracy (Pertama Partners, 2026). A pilot scoped around a snapshot of the business at approval time may be measuring the wrong thing entirely by the time it reaches production, given how fast retail operating conditions shift.

What the team actually inherits

When the scoping decision happens at 6:47 p.m. on a Tuesday without a written problem statement, the team inherits four specific problems that are almost never named as such. First, they inherit undefined success criteria. The Gartner survey of 782 infrastructure and operations leaders found only 28% of AI use cases fully met ROI expectations (Gartner, 2026). A project without pre-defined success criteria cannot be in that 28%. Nobody knew what winning looked like before the build started. Second, they inherit a scoping boundary they did not set and cannot defend. When a direct report asks why the pilot is solving this problem and not that one, the honest answer is: because the vendor's deck was the clearest thing to skim at 6:47 p.m. nine days ago. That answer does not survive the first all-hands. Third, they inherit the organizational inertia of a signed contract. Once the SOW is executed, the problem statement tends to crystallize around whatever the contract describes. Scope changes after execution cost time, money, and credibility. The Thursday morning block, the two hours that were going to produce a real problem statement, becomes the time nobody ever reclaims. The contract is already signed. There is always something more urgent than revisiting a decision that already feels closed. Fourth, and least visible, they inherit a sponsorship gap. RAND and Pertama Partners both identify fading executive attention as a top failure driver. A leader who approved the project under depletion is unlikely to carry sustained sponsorship through implementation. When the next crisis hits, this initiative is the first thing that loses their attention.

The under-appreciated factor: they were the only one who could write the problem statement

This is the part that gets missed in post-mortems. The scoping decision matters because the depleted leader is often the only person in the building who holds the institutional knowledge required to write a defensible problem statement. They know which process is actually broken versus which process looks broken from the outside. They know why the last fix did not work. They know which team members will resist, which data sources are unreliable, and what the C-suite will measure once the pilot goes live. None of that knowledge is in the vendor's deck. None of it is in the SOW. It lives in their head, and when they type 'looks good, let's move forward' without writing any of it down, it stays there. The team then builds against a specification that does not contain the most important context. They ask questions. The leader answers them in fragments, between other things, over the following weeks. The answers are shaped by whatever is being managed that day. The scoping crystallizes inconsistently, and the implementation reflects that inconsistency. Deloitte's 2026 Tech Trends research found that seven in ten business leaders view speed and adaptability as critical priorities. Speed is a legitimate organizational value. The problem is when speed at the approval stage produces a project that moves slowly through implementation because nobody ever locked the problem statement.

What could go wrong

• The problem statement fix arrives too late

  Writing a proper problem statement three weeks into implementation is not the same as writing it before approval. By then, the vendor has begun scoping, the team has formed assumptions, and any significant reframe costs both money and relationship capital.

• The rationalization becomes the narrative

  The leader who typed 'looks good, let's move forward' at 6:47 p.m. built a case for themselves in the moment: the contract was basically decided, the manager was waiting, it was close enough. That internal narrative does not disappear after approval. It becomes the story they tell when the implementation struggles, and it points at the technology, the vendor, the team, rather than at the Thursday morning block that never got protected.

• The team optimizes for the wrong metric

  A team handed a vague problem statement will define success around what they can measure, which is rarely the outcome the business actually needs. RAND documented this pattern explicitly: models optimized for measurable proxies, not for the real business objective (RAND Corporation, 2024).

• The C-suite redefines success mid-implementation

  When the original success criteria were never written down, they are also never locked. The C-suite's definition of success can shift with the quarter, and a pilot without a fixed baseline has no way to demonstrate it delivered on the original intent.

• The initiative becomes a reference point for why AI does not work here

  A failed pilot that was scoped under depletion does not get diagnosed as a scoping failure. It gets diagnosed as an AI failure. The leader who approved the pilot at 6:47 p.m. often gets to watch the narrative form around the technology rather than around the decision that preceded everything else.

• The team never surfaces the problem to the leader who created it

  Direct reports who inherited a poorly scoped initiative are unlikely to tell their manager that the scope was wrong. They adapt, work around, and deliver something adjacent to what was actually needed. The feedback loop that would fix the scoping decision never completes.

The J.Caresse point of view

The AI pilots I have seen fail most consistently share one structural feature: the problem definition conversation happened under pressure. The Wednesday I described at the top of this piece was survivable because I protected the Monday before it. I did not make the big scoping decisions on Wednesday itself. The gym got skipped as a conscious choice. The hard deliverables got done. And then I caught a cold the following week, which was the honest cost of pushing that hard, even with the preparation. What I did not do was open a vendor deck at the end of that Wednesday and type 'looks good, let's move forward.' Because I know what I would have been approving. I would have been approving whatever reduced the pressure I felt at that moment, not whatever solved the actual problem. The Thursday morning block is where this lives. The two hours she planned to spend reading the SOW, writing the problem statement, asking the question she had not asked yet. That block is the first thing that disappears when the calendar has no slack. And once the contract is signed, those two hours become the two hours nobody ever reclaims. If you are leading an AI initiative right now, one question: can you write two sentences, right now, on what operational outcome you are measuring against a pre-implementation baseline? If the answer is no, or if those two sentences would come from the vendor's deck rather than from your own diagnosis, the scoping work is not done.

Key takeaways

What the research and the pattern actually say.

• The failure is upstream of implementation

  Leadership decisions, not technology, drive the majority of AI project failures. The most common failure mode is a problem that was never correctly defined before the build started (RAND Corporation, 2024).

• Decision fatigue changes the selection criteria

  Under cognitive depletion, a leader's selection criteria shift from 'what solves the actual problem' to 'what reduces the pressure I feel right now.' The two are different decisions that look identical from the outside.

• The team inherits undefined success

  Only 28% of AI use cases fully meet ROI expectations in infrastructure and operations contexts (Gartner, 2026). A project without a pre-written problem statement and documented baseline is not in that 28%.

• The institutional knowledge gap is the real risk

  The depleted leader is often the only person who can write a defensible problem statement. When they approve without writing it, that knowledge does not transfer to the team. It fragments across conversations over the following weeks.

• Protect the thinking time before the load hits, not during it

  The Monday before the hardest week is more valuable than any hour inside it. Problem definition requires cognitive capacity. Scoping decisions require it most. Those conversations belong in the calendar before the pressure arrives, not after the contract is signed.

• A signed SOW is not a problem statement

  The vendor's scope of work describes what they will build. It does not describe the operational outcome you need, the baseline you are measuring against, or what your C-suite will call success in six months. If those three things are not written down before the contract is executed, someone on your team is going to spend the implementation trying to reverse-engineer them.