I've sat in post-mortems for IT transformations that failed on paper but looked fine on a slide. The roadmap was sound. The vendor selection was defensible. The architecture was modern. The timeline was aggressive but not unreasonable.
And then nothing changed.
Not because the recommendations were wrong. Because they were built on the wrong version of reality.
The org chart is a fiction
Every organization has two structures: the one that appears in the org chart and the one that actually governs how decisions get made. Consulting engagements almost universally operate on the first one.
So you interview the CIO. You review the architecture. You benchmark against peers. You deliver a thoughtful, well-researched recommendation — and you miss the fact that the VP of Operations has quietly killed every infrastructure initiative for three years because of a botched implementation in 2021 that nobody on the leadership team will name out loud. The scar tissue is real. It isn't documented anywhere.
Your recommendation lands in that environment. It's technically correct. It goes nowhere.
The board said "modernize." They meant something else.
PE-backed organizations are particularly prone to a specific failure mode: a gap between the stated mandate and the actual one.
The board says modernize. What they sometimes mean is: don't break anything critical in the next 18 months while we prepare for exit. Those are different instructions. One calls for transformation. The other calls for stability and selective polish.
An advisor who doesn't know which mandate they're actually operating under will optimize for the wrong outcome — with confidence, on schedule, and at full billing rate.
Context isn't a luxury. It's the work.
There's a saying — often attributed to Einstein, almost certainly older than that — that if you had an hour to solve a problem, you should spend 55 minutes understanding it and five minutes solving it. Whether or not Einstein said it, the logic holds. A problem that is genuinely understood tends to collapse quickly under a well-aimed solution. A problem that is misunderstood will resist every intervention, often in ways that look like execution failure rather than diagnosis failure.
This is the pattern I see most often in IT transformation engagements that stall. The solution wasn't wrong. The problem definition was.
There's a version of consulting that treats context-gathering as the preamble to the real engagement — the preliminary phase you get through before the actual work begins. That framing is backwards. Understanding the organization is not slower than skipping it. It's faster. Not in the narrow sense of time-to-first-recommendation, but in the only sense that actually matters: time-to-outcome-that-sticks. The wasted motion in a misaligned engagement — the rework, the re-scoping, the initiatives that quietly die before implementation, the executive who stops returning calls — that's where the time goes. Deep context doesn't add to that timeline. It eliminates it.
What this looks like in practice
The agentic AI deployment I'm most proud of didn't come from benchmarking industry adoption rates or importing a best-practices framework. It came from understanding exactly how support tickets were being generated inside a specific 35,000-person organization — the workflows, the failure patterns, the team dynamics, the history of what had been tried before.
That specificity produced a 27% reduction in ticket volume. A context-free version of the same initiative would have produced a pilot program and a lesson learned.
The organizations I've seen get this right share one trait: they treat deep organizational understanding not as a phase to get through, but as a persistent operating requirement. They don't stop learning the business after the first 90 days. They keep learning it.
The question worth asking before you hire anyone
Before bringing in an advisor for any significant IT initiative, ask them this: What's your theory of why the last initiative in this space didn't fully land?
If they don't have an answer — if they haven't asked enough questions to have one — you've learned something important.
The right advisor isn't the one with the best frameworks. It's the one who earns the right to give you advice by first understanding what you're actually dealing with. That kind of understanding doesn't slow things down. It's the only thing that makes the work go fast — and stay done.