The most consistent failure mode is moving from a working hypothesis to a vendor conversation without resolving the questions in between. The diagnosis feels solid because it has been tested internally — by people who broadly share the same assumptions, work from the same data, and have adapted to the same organisational constraints. It has not been tested by anyone with a genuinely different vantage point and no stake in the answer.

A related pattern is the sequence going wrong. Operating model questions get deferred until after the vendor is selected, which means the vendor's architecture ends up filling the gaps. Data readiness is assumed rather than assessed, which means the implementation inherits problems that were visible before it started. The business case is built to secure approval rather than to reflect what the investment will actually deliver, which creates credibility problems later when reality diverges from the projection.

A third pattern is what practitioners describe as the normalisation of complexity. The internal team has adapted to the constraints of the environment they are working in. The fragmented ERP landscape, the diffuse demand ownership, the planning process that has drifted into a reporting forum — these are experienced as the normal conditions of the business rather than as design problems that will shape what any investment can deliver. It takes an external vantage point to make them visible as constraints rather than background.

The organisations that navigate planning investment decisions well tend to share one characteristic above others: they sought independent peer challenge before their thinking solidified, not after. That challenge is most valuable at the point where the diagnosis is broadly formed but has not yet hardened into a direction — when the cost of finding a problem is low and the cost of missing one is high.

Specifically, what tends to produce better outcomes is: exposing the diagnosis to practitioners who have resolved comparable architecture decisions in comparable contexts, before any vendor has had the opportunity to anchor the conversation; testing the operating model assumptions before the requirements document is written; and treating the maturity assessment as a hypothesis to be falsified rather than a conclusion to be documented.

The business case question also tends to go better when the investment is framed as a programme rather than a project, and when ROI is used as a design tool — shaping which capabilities to include and in what sequence — rather than a validation exercise applied after the scope is already set.