You bought a transformation but funded a project

Post-mortems say: scope creep. Poor requirements. Vendor underperformance. Weak change management.

All real. None of them are the actual cause.

Here’s what I’ve seen in every significant transformation failure I’ve been close to: the organization bought a transformation but funded a project.

Two very different things

A project is time-bounded, with a defined deliverable. It ends. Someone signs off. Success means delivery.

A transformation is a sustained shift in capability and behavior. It doesn’t end at go-live. Success means adoption, and adoption typically takes 18 to 36 months after deployment.

When you fund a transformation like a project, predictable things happen:

• Governance is built to approve deliverables, not sustain behavior change
• The budget runs out at go-live, exactly when the hardest work begins
• The team that built it is redeployed before adoption takes hold
• Accountability ends when the final milestone is signed

I watched this happen with a $14M ERP. It went live on time, on budget, green across every milestone. Eighteen months later, 40% of target users had built workarounds to avoid it. The outcomes the CFO was promised never materialized, and nobody was accountable, because the project was “complete.”

The post-mortem said “adoption challenges.” The real cause: they bought a project when they needed a transformation, and nobody told them the difference before they signed.

Most transformations fail before they start

Here’s the uncomfortable part. Digital transformation usually fails in the planning phase, not the execution phase.

The typical sequence: six months selecting a technology. Three months negotiating the contract. Then an implementation team is hired and told “go.” Nobody asked the harder question before the purchase order: what does successful adoption look like in 90 days?

Not successful deployment. Successful adoption. There’s a fundamental difference between a system going live and a system producing value. Most transformation roadmaps are built around the first milestone and hope the second happens naturally.

It doesn’t.

The organizations I’ve seen extract real ROI start at the outcome and work backward, before the vendor demo, before the RFP, before the budget approval. They define what “working” looks like for the business, in plain language rather than technical specs, and then evaluate technology against that definition.

Sounds obvious. Almost nobody does it this way.

The gap between what’s sold and what’s real

The funding problem gets worse because the timeline everyone budgets against is usually the one on the sales slide.

What gets sold	What usually happens
6 months to go-live	11 months to functional deployment
ROI in year one	First measurable business outcome in month 14, if the adoption plan was solid
Minimal IT lift	About 2 FTEs of configuration, integration, and data migration that wasn’t in scope

I’m not criticizing vendors. This is structural. Vendors scope what they can control. They can’t control your organization’s decision speed, your data quality, your change management maturity, or the four stakeholders who weren’t in the room when the requirements were written.

The gap between sold timeline and real timeline isn’t dishonesty. It’s an accountability gap on both sides of the contract.

Funding the thing you’re actually buying

What bridges the gap:

• An internal owner who understands both the technology and the business
• A realistic implementation model that includes the “invisible” work
• Governance checkpoints that surface problems at week 8, not month 8
• A definition of “done” that includes adoption, not just deployment

The technology didn’t fail. The pre-work did. What does your post-go-live accountability model actually look like?