A strategy says where an organisation is trying to get to and, more usefully, what it has decided not to do. A project is one of the mechanisms for getting there. Alignment is the claim that this particular project moves the organisation towards that destination, and it is a claim that can be tested rather than asserted.
What a real connection looks like
The test has three parts, and a project that can answer all three has a connection somebody can check. Name the strategic objective the project serves. Name the measure that objective is tracked by. State the contribution this project is expected to make to that measure, with a size and a date.
Most projects fail this test in the same way, by connecting through a phrase broad enough to accommodate anything. Improving efficiency, enhancing customer experience and modernising the estate are categories rather than objectives, and a project justified by one of them can be compared with nothing and judged against nothing later.
The layers above the project
Each layer decides something the layer below has no standing to decide for itself, which is why an escalation that skips a layer usually comes back. Alignment has to hold at all three, and it can fail at any one of them while the other two look healthy.
Portfolio decides what gets done at all. Its currency is investment and capacity, it compares work that has nothing else in common, and its most valuable output is the list of things it declined. A portfolio that approves everything put in front of it has delegated prioritisation to whoever shouts.
Programme coordinates several projects towards an outcome none of them delivers alone. Its currency is benefits and dependencies, and it exists because the benefit lives in the gaps between the projects rather than inside any one of them.
Project delivers a defined output within constraints, and hands it over.
A well run project inside a programme whose outcome nobody wants any more is still consuming capacity that something else needed, which is the everyday form this failure takes.
Perfect delivery against an obsolete objective
A project that delivers exactly what was specified, on the date agreed, for the budget approved, against an objective the organisation abandoned eight months ago, has failed while producing excellent status reports throughout. This is common rather than exotic, and the mechanism is dull. The specification is written once and then defended. The strategy is reviewed every quarter. Nothing in the standard reporting cycle brings the two into the same room.
The stage gate is the forcing mechanism, provided the question asked there is the right one. Whether the project is on track is a management question. Whether the objective it serves is still one the organisation is pursuing is the governance question, and it is the one that gets skipped when the delivery news is good.
Choosing between projects that want the same people
The scarce resource is usually something more specific than money. It is a particular team, a named specialist, a test environment, a supplier with a queue. Approving more projects than that capacity supports does not cause any of them to be refused. It causes all of them to be late, and it hides the choice inside a hundred small scheduling arguments instead of making it once, visibly, in a room with the authority to decide.
Useful bases for the choice are the contribution to the strategic measure per unit of the scarce capacity, the cost of delay for each candidate, the dependency order where other work is waiting, and a separate lane for anything protecting the licence to operate. Compliance work belongs in that separate lane, because scoring it on value puts it in a competition it was never entering.
When the strategy moves under you
It will, on anything running longer than a planning cycle. The wrong response is to keep delivering the original scope quietly and hope the original sponsor is still in post at handover. The right one is to restate the case against the new objective and bring the answer up, early enough that somebody can still act on it.
The recheck has a small number of possible findings, and each has a different owner.
| What the recheck finds | Whose decision it is | What the project manager does |
|---|---|---|
| The project still serves the new objective | Sponsor confirms it | Reissue the case against the new wording, and record the date it was rechecked |
| It serves the new objective only in part | Sponsor | Bring options, with a cost and a date against each, and a recommendation |
| It serves a different objective now, so the benefit lands in another area | Sponsor with the new receiving area | Renegotiate the benefit and the named owner before the handover assumptions harden |
| It serves no current objective | Portfolio board | Present the cost to complete against the remaining benefit, with stop, redirect and mothball as the options |
| The objective holds and the measure or the target has moved | Sponsor | Recheck the contribution figure and say plainly whether the project still delivers it |
Two things are worth noticing about that table. Every row belongs to somebody above the project manager, and every row still requires the project manager to have done the analysis first. Raising it early is also the only version of this conversation that reflects well on anybody.