Tag Archives: pilot

9 Reasons Digital Transformations Stall After the Pilot

Why Do Digital Transformations Stall After the Pilot? (Short Answer)

Most digital transformations stall after the pilot because leaders confuse technical proof with organizational readiness. A successful demo shows something can work. Scaling requires named owners, redesigned work, aligned incentives, data and integration, change capacity, the courage to kill shadow processes — and the political will to live differently. The pilot was never the hard part.

The nine common reasons transformations stall are: (1) proof mistaken for readiness, (2) no named owner of the new way of working, (3) work redesign skipped, (4) incentives still reward old metrics, (5) data and integration debt, (6) change treated as communications, (7) shadow processes never killed, (8) pilot heroes ≠ scale reality, and (9) fear of the political cost of winning.

The Pilot Was Never the Hard Part

I have watched too many rooms celebrate a green pilot as if the transformation were already over. The interface worked. The select users smiled. The slide said “validated.” Then Monday arrived for everyone else — average managers, messy data, conflicting KPIs, and a legacy workaround that refused to die.

Human-centered change treats that gap as designable, not mysterious. Below are nine stall patterns I see repeatedly, what each looks like, and what real transformers do instead.

Reason	Common sign	What to do instead
1. Proof ≠ readiness	“It worked” used as scale approval	Require an adoption/scale scorecard
2. No durable owner	Project ends; BAU orphaned	Name a workflow owner with rights
3. No work redesign	New tool, old handoffs	Redesign jobs and decisions first
4. Old incentives	KPIs punish new behavior	Align metrics to transformed outcomes
5. Integration debt	Pilot used clean workarounds	Fund data/integration as scale work
6. Change = decks	Training without practice time	Build change muscle and coaching
7. Shadow process lives	Old path still easiest	Kill legacy paths on purpose
8. Heroics don’t scale	A-team pilot, average-team crash	Design for the median user
9. Political avoidance	Endless “learning”	Govern winners/losers in the open

1. Proof Mistaken for Readiness

What it is: Treating a successful pilot as proof the organization is ready to scale.

The stall: “It worked” becomes a funding sentence. Feasibility gets confused with operability. Leaders skip the boring questions about volume, exceptions, support load, and who changes how they spend Tuesday.

What to do instead: Separate technical validation from operating-model readiness. Before scale money, require an adoption and scale scorecard: owners, workflows, incentives, data path, support model, and stop rules for the old way.

2. No Named Owner of the New Way of Working

What it is: The transformation has a project manager — and no durable operator once the project ends.

The stall: Sponsorship was energetic in kickoff season. Then the program office demobilizes, and business-as-usual inherits a half-changed process with no one empowered to keep improving it.

What to do instead: Assign a named workflow owner with decision rights before scale funding. If nobody owns the new way after applause, you do not have a transformation. You have a temporary exhibit.

3. Work Redesign Skipped — Tool Bolted onto Old Process

What it is: Installing new technology on top of unchanged handoffs, policies, and approvals.

The stall: Same friction, prettier screens. People invent local workarounds because the system still asks them to do impossible coordination. Digitization accelerates the old mess.

What to do instead: Redesign jobs, handoffs, and decisions first. Technology should serve the human system you intend to run — not freeze the system you meant to leave.

4. Incentives Still Reward the Old Metrics

What it is: Asking people to adopt new behaviors while KPIs, bonuses, and recognition still pay for the old ones.

The stall: Managers optimize what still gets measured — speed-to-close, local utilization, ticket deflection theater — even when those metrics punish quality, collaboration, or customer effort in the new model.

What to do instead: Align metrics and recognition to transformed outcomes: adoption quality, end-to-end cycle time, customer/employee effort, first-time resolution, revenue or risk outcomes tied to the journey — not activity that photographs well.

5. Data and Integration Debt Comes Due

What it is: Pilots that succeed on clean samples, manual stitches, or heroic data wrangling collapse under production reality.

The stall: Scale exposes fragmented systems, inconsistent definitions, and brittle interfaces. The “digital” experience becomes a queue of exceptions.

What to do instead: Fund data quality and integration as first-class scale work — not a vague phase two. If the pilot needed spreadsheet glue, assume production needs architecture, not optimism.

6. Change Capacity Treated as Communications

What it is: Substituting town halls, slide decks, and one-time training for the real work of building new skills and habits.

The stall: People were informed. They were not enabled. Managers never got coaching time. Role anxiety filled the gap that practice should have filled.

What to do instead: Build change muscle: champions, spaced practice, protected learning time, manager enablement, and clear stories about how roles evolve. Communication is necessary. It is not capacity.

7. Shadow Process Never Gets Killed

What it is: Leaving the old spreadsheet, email path, or “temporary” workaround alive “just in case.”

The stall: Adoption stays optional. The easy path is still the legacy path. Leaders wonder why usage is soft while the organization quietly runs two operating systems.

What to do instead: Write stop criteria for shadow processes. Make the new way the only easy way. If you cannot turn something off, you have not finished the design of scale.

8. Pilot Team ≠ Scale Team — Heroics Don’t Industrialize

What it is: A hand-picked A-team succeeds in the pilot; average teams inherit complexity without the same support.

The stall: What worked for enthusiasts fails for the median user and median manager. Support tickets spike. Leaders blame “resistance” instead of design for the middle of the bell curve.

What to do instead: Design for the median. Staff enablement and operations for steady state. If only heroes can run it, it is not a transformation asset — it is a dependency on burnout.

9. Fear of the Political Cost of Winning

What it is: Avoiding scale because success would force real tradeoffs — turf, vendors, pet projects, or status stories that cannot survive daylight.

The stall: The organization stays in luxurious “learning mode.” Another pilot. Another vendor bake-off. Another steering committee. Progress becomes a lifestyle of almost.

What to do instead: Surface winners and losers early. Govern tradeoffs in the open. Use kill criteria as leadership hygiene. Transformation is not only a technology journey. It is a power redesign with manners.

How Do You Scale a Digital Pilot Without Stalling?

Before you fund the next wave, run a soft-landing go/no-go. Say no — or not yet — unless you can answer yes to these:

Who owns the new workflow after the program ends?
What human behavior must change for scale to count as success?
What old path will we turn off, and when?
Is integration and data readiness funded as core work, not hope?
Do incentives and manager routines reinforce the new way?

A pilot proves possibility. Transformation proves the organization can live differently. If you want digital change that lands with customers and employees, stop celebrating demos as destinations — and start designing the human system that has to carry the future on a normal Tuesday.

Frequently Asked Questions

Why do digital transformations stall after the pilot?

They stall when leaders treat technical pilot success as organizational readiness. Scaling fails without durable owners, redesigned work, aligned incentives, data/integration, change capacity, retired shadow processes, design for average users, and political willingness to make tradeoffs.

What is the difference between a successful pilot and a scalable transformation?

A successful pilot proves something can work under controlled conditions. A scalable transformation proves the organization can run the new way of working in production — with owners, incentives, data plumbing, adoption support, and the old path intentionally shut down.

How do you scale a digital pilot successfully?

Name a workflow owner, redesign jobs and handoffs, align metrics, fund integration and data quality, build real change capacity, kill shadow processes, design for the median user, and govern political tradeoffs openly before expanding volume.

What are common reasons digital transformation fails after a pilot?

Nine common reasons include mistaking proof for readiness, lacking a durable owner, skipping work redesign, keeping old incentives, hitting data/integration debt, treating change as communications, leaving shadow processes alive, relying on pilot heroics, and avoiding the politics of winning.

What should leaders check before funding digital transformation scale-up?

Leaders should confirm ownership after the program, the human behavior that defines success, which legacy paths will be turned off, whether integration/data work is funded, and whether incentives and manager routines reinforce the new operating model.

Image credits: Google Gemini

Content Authenticity Statement: The topic area, key elements to focus on, etc. were decisions made by Braden Kelley, with a little help from Google Gemini and Cursor to clean up the article, add images and create infographics.

Sign up here to get Human-Centered Change & Innovation Weekly delivered to your inbox every week.

11 Questions to Ask Before Funding Any Innovation Pilot

What Should You Ask Before Funding an Innovation Pilot? (Short Answer)

Before funding any innovation pilot, ask whether you have a named human problem, a clear beneficiary, a behavior-based success measure (not theater metrics), a durable owner after applause, decision rights to change something real, kill criteria, a path beyond the A-team, a plan to retire the old way, clarity on whose interest is optimized, guardrails against a hard landing, and a useful “no.” Most wasted pilot spend fails at the funding gate — not the tech gate.

The eleven questions: (1) What human problem are we funding? (2) Whose life gets better? (3) What behavior will we measure? (4) Who owns this after applause? (5) What can we change if we learn something uncomfortable? (6) What is the kill criteria? (7) How does this scale beyond the A-team? (8) What old way will we turn off? (9) Whose interest is optimized? (10) What hard landing are we refusing? (11) If we say no, what do we still owe?

The Pilot Is a Decision, Not a Hobby

I have watched organizations fund pilots the way people buy gym memberships in January — with optimism, a logo on the slide, and almost no plan for Tuesday in March. Then they act surprised when the demo works and the operating model does not move.

Human-centered innovators treat the funding meeting as the first design decision. A pilot is not a hobby with a budget code. It is a bet that should either earn the right to change how people work — or be stopped cleanly so capacity returns to a better problem.

If you cannot answer the eleven questions below, you are not being agile. You are underwriting theater.

Question	Red-flag answer	Fundable answer
1. Human problem	“Explore AI / innovate”	One sentence: person + stuck job
2. Beneficiary	“The business”	Named role + felt success
3. Success measure	Demos, idea count	Behavior change you can observe
4. Owner after applause	“Innovation team / vendor”	BAU workflow owner with rights
5. Decision rights	Cannot touch policy or process	Pre-agreed levers to move
6. Kill criteria	“We’ll keep learning”	Time box + fail threshold + stopper
7. Beyond A-team	Heroes + manual glue	Median user + debt named
8. Turn off old way	“Run both forever”	Retire date or condition
9. Whose interest	Deflection / savings only	Human success + economics
10. Hard landing	No failure mode	Named harms + guardrails
11. Value of a no	Only yes-path thinking	Learning returned; next bet clearer

1. What Human Problem Are We Actually Funding — in One Sentence?

Why it matters: Pilots without a named human job become feature tourism. The slide says “innovation.” The calendar says “wandering.”

Red-flag answer: “Explore generative AI.” “Test the platform.” “Build our innovation muscle.”

Fundable answer: One sentence with a person, a moment, and a stuck job — e.g., “First-line agents cannot resolve billing exceptions without three systems and a supervisor.” If you need a paragraph, you do not have a problem yet. You have a vibe.

2. Whose Life Gets Better If This Works — Customer, Employee, or Both?

Why it matters: Orphan beneficiaries become orphan adoption. “Efficiency” without a face is how pilots optimize the spreadsheet and punish the humans.

Red-flag answer: “The business.” “Shareholders.” “Everyone, eventually.”

Fundable answer: A named role and what success should feel like — less shame, less rework, more confidence, more time for judgment. If both customer and employee gain, say how. If only one gains at the other’s expense, say that too. Honesty is cheaper than a failed rollout.

3. What Will We Measure That Is Behavior — Not Theater?

Why it matters: Activity metrics fund costume. Ideas generated, demos held, patents filed, “innovation NPS” — applause instruments, not proof.

Red-flag answer: Engagement with the pilot. Number of prompts. Workshop attendance.

Fundable answer: Observable human behavior on a journey — completion in one attempt, abandoned workaround, lower effort, faster time-to-confidence, fewer repeat contacts, retained customers, managers using the new path without shadow process. If you cannot name the behavior that changes when you “win,” do not fund the costume.

4. Who Owns This After the Pilot Applause Ends?

Why it matters: No durable operator is how you buy pilot purgatory. Projects end. Vendors leave. BAU inherits a half-changed Tuesday.

Red-flag answer: “The innovation lab.” “The vendor.” “We’ll figure out ownership at scale.”

Fundable answer: A named workflow owner in the business with decision rights — someone whose job still exists when the ribbon-cutting is over. If that person is not in the funding meeting, you are funding an exhibit.

5. What Are We Empowered to Change If We Learn Something Uncomfortable?

Why it matters: Methods without mandate are innovation cosplay. Sticky notes cannot move policy, incentives, or process they are forbidden to touch.

Red-flag answer: “We’re just testing technology.” “No process changes in phase one.”

Fundable answer: Pre-agreed levers — which policy, metric, handoff, or script can move if evidence says the current way is the problem. Learning that cannot change anything is entertainment with a SOW.

6. What Is the Kill Criteria — and Who Has the Courage to Use It?

Why it matters: Endless “we’re learning” is luxury consumption. Without stop-rules, pilots become pets.

Red-flag answer: No end date. No fail threshold. “The steering committee will decide later.”

Fundable answer: A time box, an evidence threshold, and a named person authorized to stop. Killing a weak pilot is not anti-innovation. It is how you protect the next good bet.

7. How Does This Scale Beyond the A-Team — or Are We Funding Heroics?

Why it matters: Hand-picked enthusiasts, clean data, and spreadsheet glue prove almost nothing about the median Tuesday.

Red-flag answer: “We’ll harden it later.” “Our best people will run it first.”

Fundable answer: Design assumptions for the median user and median manager. Integration and data debt named as costs in the pilot ask — not as a surprise after the applause. If only heroes can run it, you are funding burnout with a demo.

8. What Old Way Will We Turn Off If This Works?

Why it matters: Shadow paths keep adoption optional. Dual operating systems drain trust and attention.

Red-flag answer: “We’ll run both for a while” with no end condition.

Fundable answer: An explicit retire date or trigger for the workaround, spreadsheet, or legacy path. If you cannot turn something off, you have not finished designing the bet — only the brochure.

9. Whose Interest Is This Optimizing — Human Outcome or Cost-Containment Theater?

Why it matters: Pilots that succeed only on deflection, speed, or savings often fail on trust. Customers and employees keep score in their bodies.

Red-flag answer: Success equals containment, handle time, or “AI adoption” alone.

Fundable answer: Human success and economics in the same sentence — resolve completely, reduce effort, preserve dignity, and improve cost-to-serve or revenue quality. If the pilot cannot say who is optimized, assume it is the slide.

10. What Hard Landing Are We Refusing — and How Do We Prevent It?

Why it matters: Soft landings are designed at the funding gate. Hard landings are what you get when efficiency is the only value on the dashboard.

Red-flag answer: No failure mode for customers or employees. “We’ll monitor.”

Fundable answer: Named harms you refuse — loop traps, denser busywork, surveillance personalization, blocked escalation, rubber-stamp humans — plus guardrails: undo, consent, handoff, protected deep work, decision rights. If you cannot describe the hard landing, you are not ready to fund the soft one.

11. If We Say No, What Do We Still Owe the Organization?

Why it matters: A good no is innovation hygiene. Fear of looking “anti-innovation” is how bad pilots get yeses.

Red-flag answer: Only a yes-path. Silence after rejection. Political punishment for stopping.

Fundable answer: Even a no returns something — documented learning, clarified problem, freed capacity, a sharper next bet. Leadership that can only fund yeses will eventually fund theater.

How Do You Decide Whether to Fund an Innovation Pilot?

Run the eleven questions in one meeting. Score each green, amber, or red.

Three or more reds: Do not fund. Fix the ask or kill it.
Ambers: Fund only with written conditions and a named owner for each condition.
All green or green-with-conditions: Fund the smallest bet that can falsify the idea — not the largest deck that can impress the room.

Funding a pilot without these answers is not agility. It is underwriting theater. Real innovators do not fear the questions. They fear spending a year proving something that was never designed to land with humans in the first place.

Frequently Asked Questions

What questions should you ask before funding an innovation pilot?

Ask what human problem you are funding, whose life gets better, what behavior you will measure, who owns the work after applause, what you can change if you learn something uncomfortable, what the kill criteria are, how it scales beyond the A-team, what old way you will turn off, whose interest is optimized, what hard landing you refuse, and what you still owe the organization if you say no.

How do you decide whether to fund an innovation pilot?

Score the eleven funding questions green, amber, or red in one meeting. Three or more reds means do not fund. Ambers require written conditions. Fund only the smallest bet that can falsify the idea when answers are green or conditionally green.

What is kill criteria for an innovation pilot?

Kill criteria are the pre-agreed time box, evidence threshold, and authority to stop a pilot that is not earning the right to continue. Without them, “we’re learning” becomes an excuse to keep funding pets instead of progress.

Why do innovation pilots waste money?

Most wasted pilot spend fails at the funding gate: no named human problem, vanity success metrics, no durable owner, no decision rights, no kill criteria, A-team heroics, dual operating systems, and optimization for slides or containment rather than human outcomes.

Should you fund an innovation pilot without a scale plan?

Not if “no scale plan” means no owner, no path beyond heroics, and no intent to retire the old way. You can fund a small learning bet — but only with kill criteria and clarity about what operating-model questions the pilot must answer before more money arrives.

Image credits: Google Gemini

Sign up here to get Human-Centered Change & Innovation Weekly delivered to your inbox every week.

Overcoming Resistance to Change

Offering Strategies and Techniques for Identifying and Addressing Resistance to Change, Ensuring Smoother Transitions

Overcoming Resistance to Change

GUEST POST from Chateau G Pato

Change is inevitable in any organization, and yet many leaders find themselves battling resistance when attempting to implement new initiatives. Resistance to change stems from a variety of reasons, including fear of the unknown, lack of trust in leadership, and perceived threats to job security. However, with the right strategies and techniques, leaders can effectively identify and address resistance, leading to smoother transitions and increased organizational success. In this article, we will explore two case study examples to provide practical insights into overcoming resistance to change.

Case Study Example 1: The Sales Department’s Shift to Digital Platforms

In a mid-sized retail company, the sales department was reluctant to embrace digital platforms for customer engagement, despite the clear advantages it offered. Many sales representatives were comfortable with traditional methods and feared that digital adoption would render their roles obsolete. To address this resistance, the leadership implemented the following strategies:

1. Effective Communication: The first step was to communicate the benefits of digital platforms for both the company and sales representatives personally. Leaders explained how digital tools could enhance sales efficiency, generate more leads, and open doors to new markets. Additionally, interactive workshops were conducted to alleviate concerns and answer questions, creating a safe space for open dialogue.

2. Training and Support: Recognizing that resistance often stems from a lack of knowledge or skills, the company provided comprehensive training on digital tools. This training empowered sales representatives with the necessary skills to navigate the new platforms confidently. Ongoing support, including real-time troubleshooting and feedback sessions, further fostered a sense of security among the sales team.

As a result of these strategies, the sales department gradually embraced digital platforms, and their sales performance improved significantly. Representatives recognized the increased potential that digital tools offered, leading to a more harmonious transition and a boost in overall productivity.

Case Study Example 2: Restructuring for Agile Project Management

In a large software development company, a resistance to change emerged when transitioning from a traditional hierarchical management structure to a more agile project management approach. Some employees were skeptical, believing that the new structure would lead to increased workloads, decreased job security, and diminished autonomy. To overcome this resistance, the company employed the following strategies:

1. Empowering Leadership: To gain employee buy-in, the leadership openly communicated the reasons for the change, emphasizing the benefits of increased collaboration, faster response times, and greater innovation. Leaders ensured that team members felt involved by seeking their input and incorporating their ideas into the new structure. This approach helped build trust and alleviate concerns.

2. Pilot Projects: Instead of an immediate, company-wide implementation, the company initiated pilot projects in selected teams. This allowed small groups of employees to experience the benefits firsthand and share their success stories within the organization. By highlighting positive outcomes and lessons learned, the resistance began to diminish.

By effectively overcoming resistance through these strategies, the company successfully transitioned to the agile project management approach. Employees experienced increased job satisfaction, stronger teamwork, and the ability to adapt quickly to changing client needs. The organization as a whole became more responsive, competitive, and achieved higher client satisfaction rates.

Conclusion

Overcoming resistance to change requires proactive strategies to address the fears and concerns that accompany transitions. By implementing effective communication, training, support systems, empowering leadership, and pilot projects, organizations can achieve smoother transitions and garner employee support. The case study examples provided demonstrate the effectiveness of these strategies in tackling resistance to change. Leaders who implement these techniques will not only increase the likelihood of successful change implementation but also foster a culture of adaptability and growth within their organizations.

SPECIAL BONUS: Braden Kelley’s Problem Finding Canvas can be a super useful starting point for doing design thinking or human-centered design.

“The Problem Finding Canvas should help you investigate a handful of areas to explore, choose the one most important to you, extract all of the potential challenges and opportunities and choose one to prioritize.”

Image credit: Misterinnovation.com

Sign up here to get Human-Centered Change & Innovation Weekly delivered to your inbox every week.