The method follows the problem

Most of the problems we are asked about cross departments, contracts and datasets. Before deciding what to do, we want to understand how the system in question behaves and what a better outcome would look like.

Start a conversation See our services

Aerial view of a city centre with construction under way

The five steps

Each step is explained below. Throughout, the evidence and the people who run the operation keep testing the model, so it is updated as results come in rather than fixed at the start.

Each step links to its section below.

Understanding the question

A useful piece of work starts with an agreed question, together with a clear sense of the decision it supports and the outcome that actually matters.

The problem as first described is often a symptom. A cost overrun may trace back to a consent condition agreed two years earlier. A supplier's missed deliveries may follow from a reporting rule set by its client. We spend time early on working out where the difficulty actually sits, which decisions depend on it and who is affected.

Working with experts

The people who run an operation understand it in ways that no dataset records.

Planners, engineers, commercial managers and site teams know where the constraints are, which rules are real and which are habit, and what happened the last time something similar was tried.

We work directly with them, and with independent specialists where the problem needs it. Our role is to bring structure, modelling and technical depth to what they know, so it can be examined, tested and shared, rather than to replace their judgement with ours.

Modelling the system at the right resolution

The level of detail depends on the question, and sometimes a simple model is enough where at other times a detailed simulation is needed.

A model makes the relationships and constraints in a system explicit, so they can be discussed and tested. Through our systems modelling and simulation work we build models at the level of detail the decision needs. A strategic choice may need only the main flows and dependencies. A question about capacity, resources or interactions under pressure may need a detailed simulation.

Two illustrative models show the idea. Airports, optimised as a system follows one peak hour at an illustrative two-runway hub from airspace to the kerb and shows which stage is the constraint. Ports, configured by demand links vessel calls and cargo flow to berth, landside space and cost.

Exploring alternatives

Once the system has been represented, the options can be compared before anyone has to commit to one of them.

We test changes to resources, sequencing, rules or investment, look at who gains and who bears the cost, and identify the constraint that limits the whole system.

Optimisation can help where there are many combinations to consider. Often the more valuable result is simply seeing that the obvious fix would move the problem somewhere else.

Validation and uncertainty

A model is a structured way of reasoning about a system rather than a certain prediction, and we say so.

Assumptions statedEach model sets out what it assumes, so those assumptions can be challenged by the people who know the system.

Uncertainty visibleResults show where the model is sensitive and where the evidence is thin, rather than a single answer on its own.

Validated against evidenceHistorical data, where it is relevant, helps to challenge, calibrate and validate a model. Expert review does the same.

Limits declaredEach model says what it was built to answer and what it should not be used for.

Whether data is good enough depends on the purpose it serves, a point developed in There Is No Such Thing as Good Data. We agree that purpose first, then decide what evidence is needed and how far to rely on it.

Supporting implementation

Analysis is only useful if the change it points to can actually be carried through, so we stay involved while that happens, to whatever extent the client wants.

Implementation may mean redesigning a process through our process and organisational improvement work, connecting information through data, integration and implementation, introducing a new capability through technology and AI enablement, or supporting leadership decisions through strategic and operational advisory. Where our own products fit, such as Project:OS, we will explain why; they are never a requirement.

Major programmes produce a great deal of reporting, yet the most reliable reading of how they are going often sits with a few experienced people, as discussed in People as Proxies for Systems. Part of implementation is making that understanding durable, so it does not depend on who happens to be in the room.

Tell us about the problem

Tell us what is proving difficult or what needs to change. There is no need for a specification; we can help work out where to begin.

Start a conversation