Measuring Complexity

A detailed risk analysis is still necessary. But alongside it we need a single high-level indicator of whether complexity was judged correctly when budgets, skilled resources and roll-out timescales were allocated.

If complexity is exponential, we need factors that multiply. Three will do: X × Y × Z. They must be common to all projects, quantifiable to a good approximation by the stakeholders themselves, and powerful enough in combination to be a fair indicator.

1. 1Number of stakeholder groups affected — everyone whose work, service or accountability changes. Include end users, back-office teams, partners, suppliers and citizens or customers.
2. 2Number of business processes affected — count the processes that will have to work differently after go-live, not the number of screens or modules.
3. 3Time to implement, in months — from mobilisation to the point where the new way of working is the only way of working.

The product of the three factors places your project on an exponential scale. It does not represent every risk; it tells you whether the scale of what you have taken on matches the resource, governance and time you have allocated to it — and, for a project already in trouble, whether it can be rescued or needs to be stopped and restructured.

• Low: conventional project management should cope. Governance can be light.
• Moderate: needs a full-time experienced project manager, an active sponsor and genuine user involvement from the start.
• High: phase it. Break the count down — fewer stakeholder groups per release, fewer processes per release, shorter elapsed time to each proof point.
• Severe: do not attempt as a single programme. Restructure into independently valuable stages, or stop.

Note what the model implies about the standard rescue instinct. Adding scope, adding stakeholders or extending the timeline all increase complexity multiplicatively. The only reliable lever is reduction.