In McKinsey's 2026 global AI survey, nearly 90% said their company used AI on a regular basis in at least one part of the business.
But when McKinsey asked those people how far along their companies were, only 44% said AI was scaling across the whole company.
The rest said they were still testing it or running pilots.
That gap makes sense to me.
I spent years showing clients what our tech could do before they bought it.
I’ve given more demos than I can count. 😂
But the first demo is really just meant to show how an idea might work.
It can’t prove that the data will hold up, that people will use it, or that the client can run it independently.
As an AI Forward Deployed Engineer, or FDE, at IBM, that’s exactly what we aim for.
An FDE works side by side with a client to build AI and put it to work in their business.
We work in a small team called a pod.
And every project we choose to take on with a client is called an engagement.
Here’s the full path, from the first look at the work to client ownership.
Five phases, five questions
An FDE engagement moves through five phases: Technical Qualification, Scope, Build, Deploy, and Adopt.
Each phase answers one question and ends at a checkpoint.
We don't move on until the checkpoint is met.
Each phase below has five parts: what it is, how we run it, the checkpoint, what it produces, and how we measure it.
We track early signs that a phase is on track, and proof that it's done.
All the proof must be in before we move on.
1. Technical Qualification: Are we solving the right problem?
RAND talked with 65 data scientists and engineers about why AI projects fail.
The first root cause on their list: people misread, or poorly explain, the problem the AI is meant to solve.
What it is: We learn how the work really runs, not how the manual says it runs.
This phase runs on every engagement.
How we run it:
Shadow the real work, workarounds and all.
Map the whole flow: people, systems, data, decisions, handoffs, and weak spots.
Turn the pain we see into ideas we can test.
Measure today’s accuracy, speed, and cost. That’s the starting line.
Name the client engineer who will pair with us.
Checkpoint:
We know the systems, the data, and how they integrate.
The value case is in writing: the limit, the starting line, and the target.
A small first version or workshop shows the problem is real.
What it produces:
A written problem statement
Today’s numbers for accuracy, speed, and cost
A map of how the work runs today
A named client engineer
The problem statement answers five questions. Fill it in like this:
What must improve: [task] takes [time] and goes wrong [how often].
Who will use it: [role].
Data it needs: [sources].
Limits: [rules, systems, budget].
Success: [measure] goes from [today] to [target].How we measure it:
On track: The sponsor meets us and we watch at least 80% of the steps firsthand.
Done: Sponsor signs the problem statement and all three starting numbers are in.
2. Scope: What is the smallest useful win?
What it is: Scope turns what we found into work one engagement can finish.
We shrink a big goal to one workflow, one user, and one decision.
Then we write down what “done” means before anyone builds.
In our experience, skipping this step is a common reason a pilot never goes live.
How we run it:
Narrow to one use case: one workflow, one type of user, one decision.
Plan the path: how data maps, how systems connect, and what we build first.
Build the test set with the client. Their experts write real cases.
Write the definition of done: the passing score and what counts as a failure.
Start the approvals early. Bring in the product, security, and commercial teams.
Checkpoint:
A build plan, step by step.
A people plan, with both sides confirmed and free.
A target go-live date, with what it depends on.
What it produces:
A written definition of done
A test set written by the client’s experts
An agreed plan and build order
Approvals under way with the right teams
How we measure it:
On track: All the test cases we asked for are in and one use case is in scope.
Done: The client signs the definition of done. The full test set is in hand.
3. Build: Can it work from end to end?
What it is: One real use case to working result on the client’s real data and systems.
Then we make it safe to run: tested, secured, watched, and easy to undo.
We end with a working system and the proof a risk team needs to approve it.
How we run it:
Build the thinnest path first: One slice, not many half-built parts.
Make it solid from day one: clean outputs, tests, and error handling.
Run the test set every week and share the score. The trend is the status.
Build the proof: docs, tested failure cases, known limits, and a plan to watch it.
Clear security and governance, the rules for safe AI use.
Plan for failure: a backup, a way to send hard cases to a person, and an off switch.
The client engineer writes the how-to guide, then runs the system end to end.
Checkpoint:
A first version works on real data in a test setting.
The test score meets the passing bar.
Approvals are in, the undo is tested, and we can see what it’s doing.
The client can run it without us, with a clear path to go-live.
What it produces:
A working system on real data
A test score at the bar
Sign-off from security and the risk team
A how-to guide the client wrote
A list of product gaps and what each one costs the business
How we measure it:
On track: The weekly test score keeps going up until it hits the bar.
Done: The final score meets the bar. Both approvals are in.
4. Deploy: Can it hold up in real work?
What it is: We move the system into real use in steps: watch-only, then a small live group, then everyone. We also check that people really use it.
Many projects never get this far.
In an S&P Global survey, 42% of companies said they dropped most of their AI projects between a first test and real use. A year earlier, 17% said that.
How we run it:
Run it in watch-only mode. It answers live work, but no one acts on it.
Go live for one team, region, or slice of the work.
Switch everyone over only when those changes are steady and below the limit.
Track use from day one: who uses it, how often, and their workarounds.
Keep it steady. Watch for slipping quality, rising cost, and slow answers.
Checkpoint:
The first version runs in the client’s live setting.
The client signs off that it does what we agreed.
People change its answers less than the agreed limit, and that rate holds steady.
What it produces:
A system doing real work
A low, steady rate of changed answers
Use tracked from day one
A stable system, with quality and cost under watch
How we measure it:
On track: Watch-only mode, disagrees with people no more than the agreed limit.
Done: Changed answers stay at or below the limit. More people use it each week.
5. Adopt: Can the client run it without us?
What it is: We hand full ownership to the client and save what we learned.
How we run it:
Flip the pairing. The client engineer drives. We watch and step in only if asked.
Prove they can run it alone. The client engineer ships one change end to end.
Hand over ownership: the code, the budget line, the alerts, and the test set.
Review value with sponsor. Compare the result to the target and the starting line.
Save the pattern to our shared library, and set check-ins at 30 and 90 days.
That value review matters.
In IBM’s 2025 CEO study, CEOs said only 1 in 4 of their recent AI projects paid off.
Checkpoint:
We test it with the client on real work.
We agree with the client on the plan to roll it out and grow it.
It reaches all the users it’s meant for, and the client formally takes ownership.
What it produces:
A change the client shipped and undid on their own
Ownership formally handed to the client
A finished value review, and a client who agrees to be a reference
The pattern saved, with check-ins set
How we measure it:
On track: The client ships at least one change end to end, undo included.
Done: The client runs it live without us for an agreed time. All handover items have moved. The value against the starting line meets what is in Scope.
Putting it all together
Remember the gap we started with?
Most companies use AI. Fewer than half of those are scaling it.
These five phases are how we aim to close that gap:
Technical Qualification finds the right problem.
Scope shrinks it to one win we can finish.
Build gets it working safely on real data.
Deploy proves it holds up in real work.
Adopt hands it to the client for good.
Each phase ends with proof, not a guess.
A demo shows it can work. This path helps make it last.
Try this with your team
If your team is working on AI right now, ask two questions:
Which phase are we really in?
What proves we’re ready for the next one?
If you can’t answer the second question yet, you aren’t ready to move on.
I call the work in phase one problem-finding.
Next, I’ll show how we trace the work, measure today, and agree on the problem.
Next up: AI FDE Role: The Problem-Finder
Disclosure: I work at IBM as an AI Forward Deployed Engineer. I write here in my personal capacity, and the views are my own. This is my interpretation of the role, not an official IBM publication. The example above is fictional and contains no client-confidential information.