Implementation, Pilots, and Scaling | Blane Canada

Question 1

Why do AI projects fail even when the technology works?

Accepted Answer

Because most AI failures are not AI problems. They are the software engineering failures the industry has understood for decades: poor requirements, unresolved technical debt, and misaligned expectations between leadership and the teams doing the work. The technology changed. The failure patterns did not.

The AI can be flawless and the result can still be a disaster, because nobody asked the right questions before the build began.

When leaders skip the diagnostic, they end up solving the wrong problem with the right technology. The project technically works and delivers no measurable value. Or worse, it surfaces risks nobody mapped before the tools went live.

The most common specific version of this is a data problem wearing a technology problem's costume. The model performs exactly as advertised, and the information it was pointed at was fragmented, inconsistently formatted, or scattered across systems that define the same thing three different ways. The pilot did not fail. It surfaced a condition that was already there, invisible because people had been compensating for it with effort.

The problems are not new. The speed is. In my experience, what used to take 18 months to go wrong now takes closer to three. And speed without a baseline is how well-intentioned initiatives become the line item nobody wants to explain to the board.

The specific failure has a name worth using with your team: solving the wrong problem with the right technology. The system performs exactly as specified and nothing improves. We have seen it up close. A client was certain they needed generative AI to speed up a complicated workflow, and discovery showed that most of the time was going to locating and matching information they already had. The right answer was a structured database with limited semantic search. Had they gone straight into development, they would have received an elegant application that cost more, carried more risk, and solved the problem less well.

The sequence that prevents it is not complicated. Audit before you build. Align before you automate. We audit, we analyze, we align, and only then do we automate. It sounds slow. It is dramatically faster than doing it twice.

Question 2

Why did our AI initiative stall after such a strong start?

Accepted Answer

Five reasons, and they compound. Tools were bought before problems were defined. Nobody owned it, so it was everyone's responsibility and no one's accountability. Experiments succeeded in isolation and went nowhere. Trust eroded after early inaccurate output. And success was never defined upfront.

A lot of companies entered this period with real hope. The excitement was genuine. Experiments launched, teams were told to be AI-forward, the sky was the limit. For most, those plans quietly stalled. Here is why.

They prescribed before they diagnosed. Tools were purchased before the problems were clearly defined, which meant enthusiasm became the strategy by default. That works for about a quarter, because activity looks like progress from a distance and nobody wants to be the person who slows down an exciting initiative.

Nobody owned it. AI was framed as everyone's responsibility, which made it nobody's accountability. Initiatives lived in the space between departments and quietly died there, and because no single person's performance depended on the outcome, no single person raised a hand when it stopped moving.

Experiments succeeded in isolation and went nowhere. A proof of concept worked beautifully in one corner of the business and never reached operations. The gap between "this works in a demonstration" and "this runs inside our process every day" is enormous, and almost nobody scopes the work required to cross it.

Trust eroded early and never came back. Teams that got burned by inaccurate output in the first weeks formed an opinion that no later improvement dislodged. The skeptics did not have to win the argument. They won by default, because the people who might have defended the work had stopped paying attention.

And the single biggest reason: success was never defined upfront. With no baseline and no target, there was nothing to measure, nothing to defend when budgets tightened, and nothing to build the next phase on. The initiative did not get cancelled. It just stopped being mentioned.

Every one of those is preventable, and not one of them is a technology problem.

Question 3

Should we fix our broken processes before automating them?

Accepted Answer

Yes, always. AI multiplies what you already do. If a process is inefficient, automating it means producing waste faster and at greater scale. Before you add AI, subtract the inefficiency.

There is no point adding AI to broken operations, and yet we see this constantly. Companies chase capable tools without ever mapping what is actually slowing them down.

The audit is what uncovers the blockers. Then the work is redesigning for flow rather than for appearance. That is the difference between a cost center and a return that compounds.

Every operational audit we run turns up the same category of finding: teams bleeding hours through invisible inefficiency. Duplicate workflows. Manual data checks. Systems held together with workarounds nobody documented. You do not need more software. You need clarity about where the time is actually going.

It is not exciting work. It is also where the money is. An audit tells you exactly where AI can give you time back and what that time is worth to your bottom line.

The questions that make this concrete are worth asking out loud with the people who run the process. What is this workflow actually trying to accomplish? Which steps create value? Which ones exist only because an old system could not do something? Where is information being re-entered or checked by hand? Frequently the largest return comes from eliminating or redesigning steps before automating whatever remains. AI multiplies capability, and it multiplies waste on exactly the same terms.

Audit first. Automate second.

Question 4

What does a phased AI rollout actually look like?

Accepted Answer

Phase one builds measurement and a data foundation. Phase two adds intelligence on top of that foundation, surfacing what matters automatically. Phase three closes the loop from observation to action. Each phase earns the right to the next one.

Here is the shape of it, drawn from an active engagement.

Phase one: see the operation clearly. We built weekly performance reporting for every driver in a fleet, refreshed throughout the day. Stops hit, time on site, miles driven, hours on duty, depot return. Underneath each week, an efficiency score: after a driver completes a run, we feed the same stops to a route optimizer and compute what the best possible sequence would have been. A direct comparison between what was driven and what optimal looked like.

The important part is invisible in the report. Every metric is stored as a permanent record, one row per driver per day, with the chronological detail of every stop. Not a snapshot. A data asset that gets more valuable over time. That distinction is what made phase two possible.

Phase two: surface what matters without anyone looking for it. A driver running well over optimal mileage gets flagged automatically. The system watches across all drivers and all weeks and brings the signal forward. It also connects to the existing service platform so records update automatically rather than by hand, which eliminates both work and the errors that have to be corrected later.

Phase three: close the loop. When a driver consistently underperforms, the system does not just flag it. It generates a route, dispatches it, and tracks compliance, while the strongest drivers continue to self-route.

This is what implementation looks like when it is built correctly. Not a tool dropped into an operation. A system that observes how the operation actually works, builds a data foundation underneath it, and earns the right to take on more over time.

Question 5

How do we get from a working demonstration to something we can run the business on?

Accepted Answer

Treat them as two different builds. The no-code and low-code tools that make a fast, cheap proof of concept possible are frequently not commercial grade. Prove the value cheaply, then rebuild properly before the system meets real customer volume.

Many AI applications being promoted right now are built on tools that were never intended to carry production load. They can produce a genuinely good proof of concept. They also perform erratically or break when they hit the variability of real volume and real customer interaction.

That is not an argument against them. It is an argument for knowing which stage you are in.

The sequence that works is a rapid, low-cost proof of concept using no-code and low-code tools, which answers the only question that matters early: does this actually produce value? If the answer is yes, you then rebuild it as a commercial-grade solution where real engineering skill matters.

The reason to be disciplined about this is reputation. A system that behaves unpredictably in front of customers costs far more than the build saved. Reputation risk is real for any business owner, and it is the risk least often priced into an AI proposal.

Innovation is enjoyable. Execution is where the value is.

Question 6

What should we measure during a pilot, and when do we expand or stop it?

Accepted Answer

Measure the business outcome the pilot was built to improve, against a baseline you captured before it started. Expand when the value is real and you understand what scaling will require. Stop when the evidence says the case is weak. Define the stop conditions before you begin, while it is still easy.

A pilot should answer a business question, not prove that AI works. The measurement comes from the problem rather than from the technology. If people spend eight hours preparing a recurring report, measure preparation time before and after. If the issue is missed follow-ups, count missed follow-ups. Track adoption alongside the outcome, because a capable tool nobody uses produces nothing. Avoid counting prompts or documents generated, which measure activity rather than value.

Expanding is a higher bar than working. Scale changes the problem. More people means more training, more permissions, more support, and more ways to be wrong. Usage costs rise. A workflow that five enthusiastic volunteers loved can meet real resistance at five hundred users. Before expanding, go back to the business case and ask whether the outcome actually improved, whether users want it, whether the infrastructure holds at volume, whether governance is clear, and whether the economics still work. Scale on evidence, not on how impressive the demonstration was.

Stopping is the harder discipline. The most expensive management instinct is defending an initiative because money has already gone into it. The pilot exists specifically to generate evidence before a larger commitment, so when the evidence is unfavorable, use it. Maybe the problem was not valuable enough. Maybe adoption will not happen. Maybe a straightforward database application solves it better, which we have concluded more than once.

The failure is not ending an experiment. The failure is letting an experiment become a permanent system after its business case disappeared, because nobody wanted to say so.

Question 7

How do we move from disconnected AI projects to a company-wide strategy?

Accepted Answer

Get everything into one view first. Find what is actually in use, connect each item to a business priority, cut the duplication, set common guardrails, and then prioritize. Strategy begins when scattered departmental experiments become coordinated decisions. It does not begin with a plan written before anyone knows what is running.

Almost nobody starts with a strategy. They start with people experimenting, which is the right instinct. Marketing tries a tool. Operations runs a pilot. Someone in finance has quietly been doing their analysis in a personal account for a year. That is normal and it is not a failure of discipline.

The strategic step is assembling those activities into a single picture, and it is usually the first time anyone has one. What is working. What is duplicated. Where the risk sits. Which experiments connect to something leadership actually cares about. What shared infrastructure would make several of these easier at once. That inventory is frequently the most surprising thing in an assessment, because what is running is rarely what leadership believed.

From there you can decide. Some things expand. Some consolidate. Some stop, and stopping should be a normal outcome rather than a defeat. Guardrails become consistent instead of varying by department.

The specific failure to fix is ownership. When AI is everyone's responsibility it becomes nobody's accountability, and initiatives live in the space between departments and die there. Put a name on each priority. Not a committee, not a working group. One person who will stand up next quarter and say what was done and what it produced.

An AI strategy is not one large AI project. It is the coordination of many decisions around a shared view of where value actually is.

Question 8

How can we tell when an AI project is going off track?

Accepted Answer

Watch for drift rather than failure. Success measures that were never defined or keep changing. Users building workarounds. Progress reports about features rather than outcomes. Costs climbing without explanation. When nobody can plainly say what improved, the project has lost its connection to the problem.

Projects rarely announce failure. The signals accumulate quietly, and each one is individually explainable.

People stop using the tool but nobody reports it, because nobody was asked. Employees build spreadsheets around the system to make it usable, which looks like resourcefulness and is actually a symptom. The team talks more about capability and less about the outcome, which is the clearest early tell. Timelines slip for reasonable-sounding reasons. Nobody can explain in one sentence whether value is being produced.

The corrective is a scheduled return to the original assumptions rather than a rescue effort. What problem were we solving? What did we expect to improve, and by how much? What evidence do we have? What has changed since we decided?

The reason this needs to be on a calendar is that the alternative is worse. I watched a client mandate a platform for a use case it was never designed to handle, and the person responsible for enforcing adoption held the line because the platform had AI built in. The executive's own assessment was that it was delivering results about twenty-five percent useful for the purpose it had been forced to serve. Seventy-five percent waste, defended as commitment to a decision.

The most dangerous leadership behavior in this environment is not ignorance. It is the confident, principled defense of a decision that has already failed. Reversing a call at month three costs a fraction of reversing it at month twelve, and the window is shorter now than it used to be.

When did you last reverse a call you knew was wrong?

Question 9

How do we restart an AI initiative that has gone quiet?

Accepted Answer

Three steps. Audit what actually moved, and find the one or two experiments that quietly worked before being abandoned. Pick one operational problem and solve it inside a fixed deadline. Then put one name on it, not a committee.

Audit what actually moved. Go back to the beginning of the year and find the experiments that showed real promise and then got dropped. Not the flashy ones. The ones that quietly worked. Those are your starting point, and they are cheaper to restart than to originate.

Pick one operational problem and solve it before the quarter ends. Not an initiative. Not a task force. One specific problem that costs your team time, money, or mental energy every single week. Assign AI to that problem. Measure the result against the baseline you should capture before you start.

Put a name on it. Every AI priority needs one person accountable for the outcome. Not a committee. Not a team. One person who will stand up at the end of the quarter and say here is what we did and here is what it produced.

The companies that enter a new quarter with momentum are not the ones that spent the previous one waiting for conditions to improve. They are the ones that used it.

Worth asking your team this week: what is the one experiment from earlier this year that deserves a second look?

Question 10

Our consultant changed the plan halfway through. Is that a bad sign?

Accepted Answer

Usually the opposite. A mid-course correction means the team learned something in execution that discovery did not surface, and chose to solve the real problem instead of finishing the scoped one. Technically complete and solving the wrong problem is the worse outcome.

We were three weeks into a Phase 1 delivery when we changed direction.

The original scope was clean. Take the daily job schedule from the client's dispatch platform and convert it into optimized routes for drivers. Clear problem, clear solution. Except that was not how the client actually ran her operation.

She does not schedule day by day. She sends each driver a batch of jobs and they self-route through the week. The dispatch platform gets updated afterward as a record, not used as a plan. It had come up in discovery, but not as a hard rule, and we learned how much it mattered only in execution.

Forcing the original model onto that operation would have created a process she did not need and would not use. Technically complete. Solving the wrong problem.

So we stopped, reassessed what she actually needed given how she actually works, and rebuilt Phase 1 around that reality. The outcome stayed the same. The mechanism changed completely.

Mid-course correction is a feature of this work, not a failure. It is a more accurate read. What you should worry about is a partner who never changes anything, because that usually means they are delivering the scope rather than the outcome.

Question 11

Why do AI projects spiral in scope and cost?

Accepted Answer

Because possibility overtakes practicality. A client shares a challenge, the real issue turns out to be simple and solvable, and then the ideas start. What if we added this? Could it tie into that? Suddenly the original idea is buried under features nobody asked for.

It always starts the same way. A client shares a challenge. We talk it through to isolate the real issue, which is usually something simple, strategic, and solvable. We sketch a possible solution: a tool, a dashboard, maybe some automation.

Then the possibilities unfold. What if we added generative AI? Could this tie into predictive analytics? Why not build a full platform? Before long the original idea is buried under a mountain of features, and the client is quietly wondering whether this is what they wanted or what the vendor wanted.

Anyone who survived the software boom has seen this movie. The lure of possibility overtaking practicality is not new.

Two habits contain it. Project evolution: show a schematic of how the idea grew from the root challenge to the expanded proposal, so the client can see exactly where the scope expanded and make an informed decision about it. Project containment: acknowledge openly that not every feature is necessary today, and if the proposal exceeds budget or bandwidth, scale it back. No ego, no pressure.

Most proposals in this market are delivered take-it-or-leave-it, and that is not how trust gets built. AI work is not about building more. It is about building right, and that starts with the client's priorities rather than the builder's enthusiasm.

Question 12

How much testing should an AI build actually get?

Accepted Answer

More than you think, and more than most builders are doing. In 22 years running a software company we spent more time testing than programming, because a change that breaks something else in the larger system costs more than the feature was worth.

Quality is job one, and the definition of quality has not changed just because the build method did.

One failure pattern deserves naming because it is so common right now: going straight to production, so that every user experiences whatever problems the update introduced. That was never acceptable in the software business and it should not be acceptable now, particularly when the system is making decisions rather than displaying information.

For an executive buying a build, the practical requirements are straightforward. Ask what the testing plan is and who executes it. Insist that testing use real data rather than AI-generated sample data, because sample data does not contain the variability that breaks things. Require a staging environment before production. And define an acceptance standard beyond "it returns a reasonable answer."

The bar should be that it delivers real value to the people who have to use it.

Question 13

Should AI tell my people what to do, or give me visibility into what they are doing?

Accepted Answer

Start with visibility. On one fleet engagement we were asked to improve route efficiency, and the obvious answer looked like a dispatch system that told drivers where to go. The owner did not want route control. He needed to see what was happening. Measurement changed the operation more than control would have.

We thought we were building a dispatch system. We were not.

The original logic was sound on paper. Improve route efficiency, so build something that tells drivers where to go, optimizes their routes, and controls execution. Then we learned how the business actually operated. The drivers self-route. The owner was not looking for control. He needed to see what was happening.

So we pivoted. Instead of dispatching drivers, we started measuring performance. Every completed route compared against an optimized version of the exact same stops. Not to control. To understand.

The results were immediately actionable in a way a dispatch system would not have been. One driver came within one percent of the optimal route on a four-stop day, which tells you he needs nothing from you. Another ran about 17 percent over optimal, which is a coaching conversation rather than a crisis. A third ran two and a half times the optimal mileage, which is a clear signal worth investigating.

The client's response: "This is beautiful. I can see a light at the end of the tunnel."

The pivot did not produce a dispatch system. It produced operational visibility. He is not being told how to run his team. He is being given information he never had, in a format that matches how he already works. Control can come later, once the measurement has earned trust.

Question 14

What changes when a pilot becomes everyday operations?

Accepted Answer

The standard rises sharply. During a test, someone can quietly fix an error or restart a process. Once people or customers depend on the system, those informal saves become unacceptable. Ownership, permissions, monitoring, support, cost tracking, and failure procedures all have to exist before the handover, not after.

Pilots are forgiving in a way production never is, and the gap between them catches capable teams.

In a pilot, the person running it is also the person who notices when something looks wrong. They correct it, adjust the prompt, restart the run, and the result still looks good. None of that is documented, and none of it survives the transition to a system that other people depend on. The informal interventions that made the pilot succeed are exactly what disappears when it becomes everyday operations.

What has to be in place before the handover is mostly organizational rather than technical. One named owner. Training for the people who will now use it without the pilot team standing behind them. Permissions that are right rather than convenient. An escalation path when the output is wrong, and a person with the authority to use it. Cost monitoring, because usage-based pricing grows with adoption and success itself raises your bill. And behavior that can be observed rather than assumed.

If the system can take action rather than just produce information, the controls have to be proportionate to those actions, which is a separate conversation worth having before rather than after.

This is why our builds put a data foundation underneath the first phase rather than delivering a report. A report is what you look at. The stored record underneath it is what makes the next phase possible.

Production readiness is not a developer milestone. It is an organizational one, and both sides have to be ready.

Question 15

Is it okay for some AI experiments to fail?

Accepted Answer

Yes, and an organization that cannot tolerate it will not learn fast enough to compete. A good experiment is designed to answer a question cheaply before real money is committed. The goal is not making every experiment succeed. If the outcome is predetermined, it was not an experiment.

Plenty of organizations say they want innovation while quietly requiring that everything work. Those two positions are incompatible, and people notice which one is real within about a quarter.

Gary Larson described his own creative process as reaching for something and taking risks, sometimes hitting a home run and sometimes coming up with what he called Cow tools. The point that stays with me is that you cannot have the first without risking the second. Across forty years I have launched experiments that worked and experiments that taught me expensive lessons, and I could not have separated them in advance.

What makes failure acceptable is containment rather than optimism. A real experiment has narrow scope, modest cost, clear success criteria set before it starts, and a defined boundary it will not cross. Under those conditions an experiment that fails has done its job, because it bought you information at a fraction of what the same lesson would have cost after full commitment.

There is a limit worth naming. Some tuition is too expensive. Not every mistake needs to be made personally, and the reason to seek counsel is to avoid paying for lessons someone else already paid for. That is the argument for a diagnostic before a build, and it is the same argument.

The dangerous condition is not failure. It is an organization that cannot tell the difference between a contained experiment and an uncontrolled implementation.