The gap is usually structural
A strategy document can be sound and still fail in the first quarter of execution. The usual cause is not a weak recommendation. It is that the recommendation was written as a set of conclusions rather than a set of operating changes.
If the plan requires a different approval path, a new data owner, or a changed reporting line, those are design decisions. They need to be made with the people who will operate them, before the technology work is scoped.
What handover loses
When the advisory team and the delivery team are separate firms, the reasoning behind the plan is rarely transferred. The build team receives requirements, not context. The client then spends the programme reconstructing decisions that were made months earlier.
- Assumptions that were never written down become requirements by default
- Trade-offs are reopened because the reason for the choice was not recorded
- The operating model is designed around the software rather than the work
- Adoption is treated as a communication task instead of a design constraint
Design the system and the work together
We treat the operating model, the data, and the application as one design problem. That does not mean every engagement includes a build. It means the recommendation states what has to change operationally and what the system has to support, in language both sides can use.
Where a client already has a delivery partner, we work alongside them. Where the work is ours, the same people who shaped the recommendation remain accountable through delivery.
A test for any plan
Ask three questions of a strategy document: which decision changes on Monday, who owns it, and what system or record makes it visible? If the answers are not on the page, the plan is not finished — it is a position paper.
This publication presents analysis and perspective as of its date and does not constitute investment, legal, or tax advice. See our Risk Disclosures.