Feasibility-Driven Planning

I didn't set out to design a planning framework. Over three years in engineering planning at a large, matrixed global organisation — having arrived with no planning background — I kept being handed pieces of the same puzzle: standing up engineering S&OP, feeding its data into footprint and strategy decisions, repositioning delivery centres into execution hubs, shaping an IBP concept, running a cross-functional diagnostic, and building integrated execution schedules.

Each initiative taught me something about the same underlying system — what data we held, what decisions it drove, and where it broke down. Feasibility-Driven Planning emerged from connecting those threads, not from a clean problem statement handed down from above.

When I needed to explain why it mattered, I framed it against value: an organisation loses value not mainly in execution, but at the moment of commitment — when plans are made without an integrated view of whether they can actually be delivered. An internal analysis traced a substantial share of value erosion to feasibility gaps surfacing too late.

The organisation plans around three primitives — demand, capacity, and time — and plans each one well in isolation. The problem is that they're planned separately, by different parts of the org, on different cadences. Demand is planned by phase; capacity by function; time by horizon — and these don't flow into one another unless a diligent manager manually keeps the numbers consistent across separate tools.

The symptom was unmistakable: many plans, many tools, and still no one who could say with confidence whether a whole project would be delivered on time. This wasn't a people problem; it was a system problem. Planning wasn't incorrect or absent — it was fragmented.

If fragmentation was the disease, alignment was the cure. A plan you can trust has to hold demand, capacity, and time together at once. I called that property feasibility: the ability to deliver what's committed, when it's committed, with the capacity available.

The three are interdependent. Demand decisions drive capacity decisions; available capacity constrains what demand can responsibly be committed; and neither means anything except against time. Projects are where it converges — the natural integration anchor for horizons, functions, and phases, where feasibility shows up as cost, schedule, and risk.

The breakthrough was realising that execution is a matrix, not a table — and then that it needed a third dimension. In a matrixed organisation, demand and capacity sit on two different axes and execution lives in the grid between them. Then time forced a third axis: every demand and capacity decision is made against when. A matrix couldn't hold that, so the model became a cube.

Demand Plan = f(Demand, Time). Capacity Plan = f(Capacity, Time). Supply = f(Demand, Capacity). Together they form the Supply Plan = f(Demand, Capacity, Time) — the feasible plan, with its constraints and dependencies. The same logic holds at every horizon; only the granularity changes.

Feasibility is then maintained through decision-centric reviews, each tied to a horizon and consuming the matching level of detail — S&OE for short-term stability, S&OP for medium-term demand–capacity alignment, and IBP for long-term strategic tradeoffs. The same data flows to all three at different granularity, so a constraint surfaced on the floor can travel up to the decision that resolves it.

A model is only useful if it can be run without breaking the business already operating. The principle: fixed where it matters, flexible where it must be. A fixed spine — the feasibility logic, a core data structure, clear system boundaries, and a consistent review architecture — gives the enterprise one shared definition of feasibility. Around it, each function keeps full flexibility in how it executes and which tools it uses.

To pressure-test the idea, I took one module — engineering — deeper, working through definition, process, data, tool, and governance in that order, deliberately settling the logic before evaluating any platform.

The implementation is modular — Lego blocks that snap into place. Creating a single integrated execution schedule isn't just sequencing tasks; for it to function as a block within the spine, it has to be built with a clear understanding of three things: its process interfaces match what comes before and after it, so blocks snap together instead of needing rework at the seams; its data is anchored to the same work breakdown and the same demand–capacity–time fields, so nothing is lost when it rolls up; and its tool is compatible with enterprise scale-up, so blocks built across functions consolidate without translation.

A block built this way — inside the spine, compatible at its edges, complete in its data, scalable in its tool — is the precondition for everything that follows. The rigour of building one block correctly is what lets the whole assemble.

The framework was the easy part.

Synthesis. The value was seeing several problems I'd solved separately as one problem in disguise.

Translation. A structural insight has to be retold in the language of the people who fund things.

Sponsorship. A sound idea, well argued, still stalls without an owner who has authority and incentive.

A portable way of thinking about planning in any matrixed organisation — and a reminder that systems design, business translation, and stakeholder alignment are three parts of the same job.