The dominant planning unit in most enterprises is the project, closely followed by the system or application. Both are convenient because they map cleanly onto how money is released and how delivery is staffed. Both are also poor units for reasoning about strategy, because neither is stable and neither aggregates. A project is a temporary vehicle that dissolves once its scope is delivered, taking its rationale with it. A system is an implementation choice that will be superseded. When the planning conversation is conducted in these terms, the portfolio becomes a shopping list whose items cannot be compared, because a payments modernisation programme and a CRM upgrade are described in incommensurable language and justified by incommensurable benefits.

The practical symptoms are familiar. The same underlying weakness gets funded three times under three project names because no one recognised it as one thing. Investment concentrates where the loudest sponsor sits rather than where the business is most exposed. Duplication accumulates because two departments each build support for an ability that is, in truth, the same ability serving the same customer. And when leadership asks the reasonable question of what a given spend actually buys the organisation in terms of what it can now do better, the answer arrives in the vocabulary of deliverables rather than outcomes.

It matters more now than it did a decade ago for two reasons. First, the pace and cost of technology change have risen, so the penalty for investing in the wrong place compounds faster. Second, the estate is more distributed, mixing legacy platforms, packaged software and cloud services, which makes system-level reasoning even less able to answer a business-level question. Capability-based planning matters because it gives leaders a language that is stable enough to plan against and abstract enough to compare across the whole enterprise.

A business capability is an expression of what an organisation does, held deliberately apart from how, where or by whom it does it. Onboard a customer is a capability. The onboarding portal, the KYC team and the identity-verification service are among the things that realise it. The discipline of keeping the what separate from the how is the whole point, because it is precisely that separation which makes the capability stable while implementations churn beneath it. A well-formed capability is named as a stable noun-oriented ability, it is defined once for the whole enterprise, and it does not encode the current operating model or the current technology.

Capabilities are organised into a capability map, a structured decomposition of the enterprise into levels. Level one holds a small number of coarse groupings, typically between ten and twenty, spanning the entire business. Each decomposes into level two and, where useful, level three, growing more granular without ever crossing into process detail. The map is not a process model and not an org chart. A process describes a sequence of steps over time. An org unit describes who reports to whom. A capability describes a stable ability that many processes exercise and many units contribute to. Confusing these three is the most common way a capability model is spoilt at birth.

The map earns its keep only once it is connected in two directions. Upward, each capability is linked to the strategic outcomes and goals it serves, so that intent can be traced to the abilities it depends on. Downward, each capability is linked to the applications, data, people and processes that realise it, so that a decision about an ability can be traced to everything it touches. With both links in place the capability becomes a join point. A strategic priority resolves into the handful of capabilities it truly rests on, and each of those resolves into the concrete systems and teams that would have to change. The heat map is what makes this actionable: each capability is scored on dimensions such as strategic importance, current maturity, cost, risk and business value, and rendered visually so that the small set of capabilities that are both highly important and poorly served becomes immediately obvious. That intersection, high importance against low performance, is where investment belongs.

Capability modelling is not new, but several developments have moved it from a diagramming exercise towards a live planning instrument. The first is the maturing of enterprise architecture repositories and portfolio tooling into platforms that hold the capability map as a first-class object and bind it to the application and technology inventory. When the map is connected to real data about which applications support which capabilities, at what cost and with what technical health, the heat map stops being a workshop opinion and starts being a defensible read on the estate. The scoring can be partly derived rather than wholly asserted, which is what gives it authority in front of a finance committee.

The second is the alignment of capabilities with value streams and with product-oriented operating models. As organisations reorganise funding away from projects and towards long-lived product teams, the question of what each team is accountable for needs a stable answer, and capabilities supply it. A product or a value-stream stage is grounded in the capabilities it delivers, so the shift from project funding to persistent product funding inherits the capability map as its backbone rather than reinventing scope every planning cycle.

The third is the sharpening of build-versus-buy reasoning as software moves to subscription and cloud delivery. When most capabilities can be satisfied by a packaged service, the strategic question becomes which capabilities are genuinely differentiating and therefore worth building or shaping, and which are necessary but undifferentiated and therefore best bought and standardised. Capability-based planning is the natural place to make that call deliberately rather than vendor by vendor. The fourth development is the arrival of AI and automation as candidate realisations. A capability lens keeps the question disciplined: not where can we bolt on a model, but which specific abilities would materially improve if augmented, and is that ability important enough to justify the exposure. In each case the map is what stops a general trend from being applied indiscriminately.

The difference between a capability map that guides investment for years and one that is quietly abandoned lies almost entirely in design discipline. The first principle is that capabilities describe outcomes, not organisation. If a capability is named after a department or a current system, it will be redrawn the moment either changes, and the stability that justified the whole approach is lost. The map must survive a reorganisation untouched. This is the single hardest principle to hold, because the people in the room naturally describe the business as they experience it, through their own function.

The second principle is a single, consistent level of abstraction within each layer of the map. Siblings should be roughly equal in granularity, so that one branch is not decomposed to fine operational detail while another remains coarse. Uneven decomposition destroys comparability, and comparability is the reason the map exists. The third principle is that capabilities should be, as far as practical, non-overlapping and complete: every meaningful ability of the business appears once and only once. Overlap creates the double-funding problem the map was meant to solve, and gaps hide exposure.

The fourth principle is the deliberate one-to-many relationship between a capability and its realisations. A single capability may be delivered by several systems, and a single system may contribute to several capabilities. Preserving that many-to-many mapping honestly, rather than forcing a tidy one system per capability fiction, is what lets the map surface duplication and fragmentation. The fifth principle concerns the heat map itself: its scoring dimensions must be defined explicitly and applied consistently, and importance must be assessed against strategy rather than against how much attention a capability currently receives. A capability can be busy, expensive and well-staffed while contributing little to strategic intent, and only an honest importance axis will reveal it. Finally, the map must be governed as a living asset with a clear owner, because an unmaintained capability model decays into a historical artefact within a single planning cycle.

The wallpaper map. The most common failure is a capability map produced as a one-off deliverable, admired briefly and then never connected to anything. Without links up to strategy and down to systems, and without a heat map that drives a decision, it is a picture. The test is simple: if no investment choice was made differently because the map exists, the map has failed regardless of how elegant it looks.

The disguised org chart. When capabilities are elicited purely from department heads describing their own areas, the map ends up mirroring the current structure. It reads plausibly but is brittle, and it reintroduces exactly the instability capabilities were meant to remove. The remedy is to name abilities in a way that would still be true if the whole organisation were restructured tomorrow.

The process model in disguise. Teams frequently slide from capabilities into processes, decomposing an ability into its steps. The map fills with verbs and sequences, becomes enormous, and loses the abstraction that made it useful for planning. A capability answers what the business can do; the moment it starts answering in what order, it has become a different artefact.

False precision in the heat map. A heat map coloured by workshop sentiment carries the visual authority of data without the substance. When a capability is marked red because a vocal stakeholder is frustrated, or green because no one complained, the colours mislead. Scores need a stated basis, ideally anchored partly in objective signals such as cost, incident rates or application health, and the scoring rationale needs to be recorded so it can be challenged.

Boiling the ocean. Attempts to model every capability to the deepest level before doing anything with the map exhaust their sponsors long before delivering value. The estate is large, the appetite for workshops is finite, and a fully decomposed map that arrives after the planning window has closed helps no one. The discipline is to model to the depth a decision requires and no further. Ownerless decay completes the pattern: even a good map, once no one is accountable for keeping it current, drifts out of step with the estate and quietly loses the trust of the people it was built to serve.

Nashua approaches capability-based planning as a means to a decision, not as a modelling project with its own reward. We begin from strategy, because a capability map has no importance axis until the organisation's intended outcomes are made explicit. Working with leadership we establish what the business is trying to achieve and, from that, which capabilities those outcomes genuinely depend upon. This keeps the exercise anchored to consequence from the first workshop rather than producing a comprehensive map in search of a use.

We then construct the capability map itself, decomposed to the depth the current decisions warrant. We are deliberate about the design principles: outcome-oriented naming, a consistent level of abstraction, and a map that would survive a reorganisation. We resist the pull towards process detail and towards the org chart, because we have seen how both quietly ruin the result. Where a usable capability model already exists we assess and refine it rather than starting again, since continuity of vocabulary is itself valuable.

The step that turns the map into a plan is the binding of capabilities to the estate. We link each capability to the applications, data and processes that realise it, drawing on the application portfolio and, where the information exists, on real signals of cost and technical health. That mapping exposes duplication, fragmentation and gaps directly, and it lets the heat map rest on evidence rather than sentiment. We score capabilities on importance, maturity, cost and risk with an explicit and recorded rationale, and we render the intersection of high importance and low performance as the shortlist for investment. From there we work with the organisation to translate that shortlist into a change roadmap expressed by capability, so that each initiative states plainly which ability it improves and by how much. Throughout, we are candid about depth and pace, modelling to the resolution a decision needs and treating the map as a living asset with a named owner rather than a document to be filed.

What distinguishes Nashua is the insistence on closing the loop from strategy to capability to system to investment, and on keeping it closed over time. Many organisations can produce a capability map. Fewer can produce one that is bound to their real application estate, scored on defensible evidence, and connected to how money is actually released, so that a change in strategic priority resolves cleanly into a change in where investment goes. That connective work, unglamorous and precise, is where the value of capability-based planning is either realised or lost, and it is where our practitioners concentrate.

There is also a practical corollary that changes what the work is permitted to assume. When an engagement calls for a capability that does not yet exist, it need not wait on a procurement cycle or a vendor's roadmap. The Nashua 360 Enterprise Platform is built to accommodate almost any feature at pace, through extreme vibe coding: what is needed is described in plain language and generated quickly, but always within firm architecture principles and under stringent quality assurance, so that speed never comes at the cost of coherence, security or control. The effect is strategic rather than merely convenient. It moves the make-or-buy line, keeps optionality cheap, and lets the architecture follow the strategy rather than the strategy bending to whatever happened to be on a shelf.

The combination is what matters. A capability map on its own is a diagram, and portfolio tooling on its own is a database of applications with no business meaning. Nashua brings the two together: the enduring view of what the business must be able to do, held against the living reality of the systems, data and cost that realise it, and governed so that the picture stays true as both strategy and estate evolve. The outcome our clients keep is not a deliverable but a capacity. Leadership gains a stable language in which to reason about change, a heat map that points investment at genuine exposure rather than at noise, and the confidence that each euro committed can be traced to an ability the business has deliberately chosen to be better at. That is what it means to invest in what the business must be able to do, and it is the discipline Nashua exists to sustain.