Scope Creep Issue #1: The Tool Isn’t the Problem. The Decision That Led to the Tool Is the Problem.

This piece first appeared in Scope Creep, our LinkedIn newsletter about why work breaks down and what fixes it. Every edition runs here on the blog eventually, but LinkedIn subscribers get it the day it publishes. Subscribe to Scope Creep on LinkedIn and skip the wait.

There’s a tone of voice executives use when they describe a PM tool eighteen months into the rollout. It’s the same tone people use to describe a relationship that’s not working but isn’t bad enough to end. “We’re making it work.” “It does what we need most of the time.” “The team is adjusting.”

Translation: nobody’s actually using it and nobody knows what to do about that.

When the project finally gets killed and someone starts a new evaluation, the diagnosis is almost always the same. The tool was wrong. We should have picked a different one.

This is, in nearly every case, the wrong conclusion.

Gartner’s number for enterprise software rollout failure is 70%. Zylo’s 2026 SaaS Management Index puts shelfware at 53% of all licenses. Pendo found that only 49% of features in the average enterprise tool ever get used. WalkMe surfaced a 1,789% gap between what executives believe their software is doing and what it’s actually doing.

The number I can’t stop thinking about: 21% of workers say their tools are adequate. 88% of executives say the same. (Same WalkMe study, second linked above.)

That isn’t a tool problem. That’s a buying process that’s been broken for so long the people inside it have stopped noticing.

What hospitals already know

Pick a hospital system. Ask them how they evaluated their last clinical communication platform. Here’s what happens.

A cross-functional team gets stood up. Clinical leaders, IT, procurement, finance, end users. Workflows get mapped. A gap analysis gets written. An RFP goes out. Vendors get scored against weighted criteria. Site visits happen. Reference calls happen. Some procurement specialist spends three weeks comparing how four different vendors handle HL7 integration. The whole thing takes six to nine months because everyone agrees that’s the appropriate weight to give the decision.

Then someone in operations decides the marketing team needs a project management tool. Same hospital system. Same finance signature. The PM tool gets bought after a thirty-minute demo and a recommendation pulled off G2.

It is, to be clear, structurally strange that this is the default. When the clinical platform underperforms, there’s a postmortem and a vendor review. When the PM tool underperforms, someone in the next QBR says “the team didn’t really adopt it” and everyone nods and a new RFP gets queued up for a different vendor.

This isn’t a budget issue. The annual license cost of the PM tool is a rounding error against the operational waste of half the marketing department and half the facilities team running their own shadow spreadsheets. It’s a category problem. Clinical software gets the rigor because the consequences are visible and named. Operational software doesn’t, because the consequences (delayed launches, two departments unknowingly running the same project, the slow attrition of the one person who quietly knew where everything was) take eighteen months to surface and almost never get traced back to the buying decision.

Aviation safety has a term for this

It’s called a latent failure. The plane crash isn’t caused by the moment of impact. It’s caused by a decision made months earlier by someone who never sat in the cockpit. The investigation, if it’s any good, traces the chain backward to find the call that quietly determined everything that followed.

Most PM tool failures are latent failures. The decision that determined whether the rollout would work was made before training started, before the implementation kicked off, before the integrations got scoped. It was made in the room where someone wrote a feature checklist instead of an adoption plan.

The most useful question for any operational software evaluation isn’t “what features do we need.” It’s “what does adoption have to look like for this to work, and what specifically is going to make that hard here?”

Clinical evaluations answer that question by default. The end users are in the room. The workflows are mapped. The integration points are known. The case for adoption gets built before the case for purchase.

Most operational tool evaluations skip the question entirely. The buyers score features against a checklist they wrote in the same conference room where they’ll make the decision. The people whose Tuesday afternoons will be different because of this purchase aren’t there. The workflows the tool has to live inside haven’t been documented. The decision gets made on what the tool can do, not on how the organization is actually going to use it.

So when the rollout fails, the diagnosis is always the same. The tool was wrong. Pick a different one.

The next one will fail the same way, until the buying process changes.

One thing to do this week

If you’ve had a PM rollout that didn’t take in the last three years, the productive move isn’t a new evaluation. It’s an audit of the last one. Who was in the room. What got asked. What got skipped. Whether the end users were consulted. Whether the actual workflows got mapped. Whether anyone wrote down what “adoption” was supposed to look like at month six.

The audit is uncomfortable because it usually points at someone who’s still in the building.

That’s the work.

The tools have always been the easy part.

---

The thing the failed evaluations have in common is that they treated every team like the same team. So when we write buyer’s guides, we write them one industry at a time: hospital teams, marketing teams, manufacturing, banks and credit unions, nonprofits. Find the one written for how your team actually works.

Browse the guides