The project portfolio is the real target architecture: what budget decisions draw without saying so

The IT master plan was approved three years ago. The target was clear: retire the old core system, build a single customer master, put a shared integration layer in place, exit the legacy data centre. The document was presented to the executive committee, well received, and filed.

Since then, the budget committee has decided on a list of projects every year. A regulatory obligation was handled in the old system, because that was quickest. A sales division got a tool that holds its own customer database, because it met its need. New products were launched on the existing core, because its replacement was not ready. The integration layer was never funded: no division was sponsoring it. Each of these decisions was defensible. None was presented as giving up on the target.

Three years on, the old system is more central than before, there is one more customer database, and the target has not been abandoned: it has simply never been built. An organisation’s real architecture is not the one its master plan describes; it is the one its project portfolio pays for. The target proposes; the portfolio disposes. As long as consistency with the target is not among the criteria that decide funding, the target remains an intention.

Why the target and the portfolio drift apart

The gap almost never comes from a wish to get around architecture. It comes from the way the two exercises are run.

Projects are assessed one at a time. A funding request is judged on its own merits: the need it covers, its cost, its timeline, its risk. What it does to the information system as a whole is not on the grid. A project can therefore be excellent in itself and move the organisation away from its target, with nothing in the file pointing it out.

The two exercises do not run at the same pace. The master plan looks several years ahead; the budget is voted every year, often under pressure. The first is rarely revised, the second always is. Over time, it is the second that counts.

Structuring moves have no sponsor. An integration platform, a shared reference dataset, the retirement of a system: these benefit everyone and belong to no one. In a funding round where each division defends its own projects, they have nobody to carry them. They are postponed, not because anyone thinks them useless, but because nobody puts them forward.

The short route runs through what already exists. Extending a system in place is almost always cheaper, in the short term, than building on its replacement. Regulatory obligations, which are not negotiable, take that route by default. Each investment of this kind makes the next one more likely, and retirement more expensive — this is how technical debt gets funded without ever being decided.

Decisions are made elsewhere. Some structuring choices are made in circuits where architecture is not present — the budget round, procurement, the business division. This is the situation described in when the business decides without architecture: by the time the project reaches IT, what it does to the target is already settled.

Reading a portfolio as a trajectory

A project portfolio is rarely presented as an architecture. Yet it is one: every project creates, extends, replaces or retires systems, and touches business capabilities. Nothing prevents reading it that way.

The exercise is simple. Start from the list of moves the target announces — what must appear, what must disappear, what must be consolidated. Then take the list of projects funded over the period and, for each one, ask a single question: against these moves, does this project bring the organisation closer to the target, take it further away, or make no difference?

The reading needs neither a tool nor an exhaustive model. The business capability map helps position projects and spot those that touch the same capability without knowing about each other. An application inventory, even a rough one, is enough to know which systems each project extends. What matters is asking the question for every project, not only for those architecture happened to review.

The result is almost always more instructive than rereading the master plan. It shows the trajectory the organisation is actually following, and sets it against the one it believes it is following. It is often the first time the two are laid side by side.

Three signals of the gap

Three patterns come up in almost every portfolio held up against its target.

Moves with no project at all. They are nearly always the same ones: shared platforms, reference data, retirements. The target has announced them for several years; no budget carries them. This signal does not say the target is wrong; it says the way the portfolio is put together cannot fund them, since it only funds what a division asks for.

Projects that invest in what the target retires. Each investment is justified on its own — an obligation, a product, an interface. But every budget cycle pushes the retirement date back a year or two, and the system to be retired gets harder to replace each time. Nobody decided to keep it; it is simply extended at every funding round.

This is the most expensive pattern, because it combines both worlds: the organisation funds the replacement and keeps funding what it was meant to replace. The period of coexistence that the trajectory had planned as temporary becomes permanent.

Projects that create what the target consolidates. A new customer database in a business tool, a new point-to-point flow when the target plans a shared layer, a new hosting arrangement outside the cloud trajectory. These projects visibly oppose nothing: they simply add one more item to what the target meant to reduce.

A fourth finding sometimes appears, and it deserves as much attention: major projects with no link to the target at all. This is not necessarily a flaw in the portfolio. Sometimes it is a sign that the target does not cover a real priority of the organisation.

Bringing architecture into the funding decision

The usual answer is to ask for an architecture opinion on every project. It fails for a simple reason: the opinion arrives after the funding decision, or it is delivered by a function with no voice in that decision. What is needed instead is for the effect on the target to be available as information at the moment the decision is made.

A short impact sheet attached to every funding request. A few headings are enough: the business capabilities affected; the systems the project creates, extends or allows to be retired; its effect on the target — closer, no effect, further away; and the future costs it commits to, both running and exit costs, because total cost of ownership is decided at that point. The sheet is filled in by the project sponsor, with architecture, before the funding round — not by architecture alone, afterwards.

A criterion in the prioritisation grid, not a veto. A project that moves away from the target can still be funded: regulatory or commercial urgency sometimes justifies it. What changes is that the gap is visible and has an owner. The committee decides knowingly, and the decision is recorded as an exception, with a review date. It is the logic of the signed exception, applied to the portfolio.

Explicit funding for what has no sponsor. Structuring moves will never be carried by a division. Two mechanisms exist. The first is a dedicated envelope for platforms and retirements, decided as such, with a named owner. The second attaches the move to the project that benefits from it: funding a new system includes the decommissioning of the one it replaces, and the project is not considered finished while the old one is still running.

A reading of the whole portfolio, once per cycle. Beyond individual projects, the exercise in figure 1 is repeated at every annual funding round, across the whole portfolio. It takes little time and answers a question no individual file asks: if we fund this list, where will we be in three years?

Sometimes the target is wrong

Holding the portfolio up against the target does not mean siding with the target on principle. If, cycle after cycle, the committee funds projects that move away from it, there are two possible explanations: either the funding decisions lack information about their effect, or the target does not reflect the organisation’s real priorities.

The second hypothesis has to be taken seriously. A target written without regard to funding capacity, available skills or regulatory constraints will never be built, however good the governance. The portfolio is then the best source of information for revising it: it shows what the organisation is willing to pay for, and what it never funds.

The revision must still be a decision, not a drift. Dropping a move from the target means accepting its consequences — keeping two customer databases, maintaining the old core, giving up on the shared layer — and saying so. What is expensive is not changing the target; it is keeping one on paper while the portfolio builds another.

The target that gets executed

A target architecture only has effect through the projects it steers. Everything else — diagrams, principles, committees — acts only through that channel. That is why the most useful question to put to a master plan is not “is it right?” but “which projects has it changed?”.

An organisation that wants its target to come about does not need heavier governance. It needs the target to be present at the only moment it can carry weight: when the decision is made about what gets funded. The rest of the time, the portfolio draws the architecture in its place, with the same confidence and without ever saying so.