Insights
Most organisations buy strategy and implementation as two different things. Two procurement categories, two suppliers, two moments in the year. The strategy arrives first, gets approved, and sets the milestones. The implementation partner is selected afterwards, and their first job is a discovery phase.
Discovery is where the systems get examined properly for the first time. By then the plan has a budget, a board endorsement and a date. When discovery turns up something that changes the shape of the work, and it regularly does, the plan has already hardened around assumptions that nobody was in a position to test at the time they were made.
That sequence is a common way for a sound strategy to become a late programme.
The wasted fees are the smaller cost. The larger one is the executive attention already committed to the plan, which does not refill on demand. Each programme that stalls also raises the internal price of the next one. Middle managers who have watched two transformations get announced and quietly rescoped will treat the third as weather rather than direction.
For a PE-backed business the arithmetic is tighter. A five-year hold has room for one serious operational programme, possibly two. A plan that loses its first year to a discovery finding does not get that year back before exit.
“Use AI to triage inbound requests” is a recommendation that costs six weeks in one company and the better part of two years in another. The wording is identical in both cases. The difference sits in whether customer records share an identifier, whether the historical decisions are labelled, and whether anyone still owns the systems in question.
None of that is visible in a strategy document, and none of it can be established from outside the systems. A team that has built and run production software can form a view on it within the first fortnight. A team that has not will describe the opportunity accurately and price it wrong.
This is the mechanism underneath the pace gap we wrote about in From AI urgency to AI capacity. Boards and CEOs who disagree about speed are often working from different unstated assumptions about readiness, with nobody in the room in a position to settle the question.
A consultant asks what the business should do. An engineer asks what would have to be true about the systems for that to work. Both questions are necessary, and the sequence matters: asked in week one, the second question changes which options reach the shortlist at all.
It also produces answers that strategy analysis alone does not reach. Frequently the constraint that rules out one option makes an adjacent one nearly free, because the data it needs already sits in a single system. That opportunity lives in a schema, and market analysis will not surface it.
A firm that staffs both disciplines is usually smaller than a pure strategy house, and that has consequences worth stating directly.
Benchmark depth is thinner. A large firm may have run your transformation in your sector forty times and holds the comparative data to prove it. Where the question is primarily one of benchmarking, buy it from someone who has that data.
Deep sector specialists are harder to field. No firm can hold genuine expertise in every industry alongside genuine engineering capability, and claiming both is usually a sign of neither.
Building a product carries its own risk. Firms that write their own software can end up with distracted consultants and a mediocre platform. Any firm claiming this advantage should be asked whether its platform has external customers or only internal ones.
Hybrid teams can also lose altitude. Building is concrete and satisfying, and a team capable of shipping is tempted to treat delivery as evidence that the strategy was correct.
Three mechanisms do the work, and none of them is an organisation chart.
One commercial result. A single statement of work covering both the recommendation and the first delivered increment. Where the fee is tied to the milestones the plan itself set, nobody can invoice for a plan that turns out to be unbuildable, and the estimate gets made carefully the first time.
A systems review inside the first fortnight, running alongside the strategy work instead of after it. Someone reads the schemas, the integration points and the data quality while the options are still open.
Engineers present while the options are generated. Validation at the end of the process catches problems too late for them to be useful.
All three are visible in a proposal before any work starts, which makes them straightforward to check.
Before approving the next transformation plan, ask who is accountable when it meets the systems, and at what point that examination happens. If the answer is a discovery phase run by a different supplier after the plan is signed off, the milestones in the document are estimates made without evidence.
Choose a preferred time slot and tell us what you would like to explore. We will confirm the meeting and send you the invite.