From strategy to delivery

Everyone on the board can recite the strategy. Ask a project lead three layers down why their project is running, and you get a different answer — a deadline, a sponsor, a figure from a dashboard. Rarely the theme the strategy was actually about. That is not because nobody tries. It is because the chain from strategy to delivery loses a link somewhere along the way, and that link is almost never where you go looking for it.

Getting from a theme to an actual project runs through nine steps: theme, objective, idea, prioritisation, decision, project, capacity, delivery, course-correction. Each step on its own is usually handled well enough. What is rarely handled is the handover between them — and that is exactly where strategy stops showing up in what actually happens.

The chain, and where it usually breaks

Theme to idea. A theme sits in a strategy document. An idea arrives through a form, an email, or a comment in a team meeting. Nobody links the second to the first unless someone explicitly adds it — and that usually doesn't happen, because it isn't a required field in whatever people are already using.

Idea to prioritisation. There is often a ranking of some kind — a scorecard, a working group, a weighted list in a spreadsheet. The problem isn't a missing method. The problem is that by the time the real decision gets made, that ranking is already a few weeks stale, or sitting in a different document from the one the decision-maker is looking at.

Prioritisation to decision. This is the link that happens out loud most often. A nod in a meeting, a reply to an email, a thumbs-up in a chat. No record gets created — no who, no when, no why — and six months later nobody can reconstruct why project A went ahead and project B didn't.

Decision to project. Even where a decision did happen, turning it into a project is often a manual step: someone copies the information across, or just starts again from scratch. The link back to the original idea — and through it, to the theme it was meant to serve — gets lost along the way.

Project to capacity. The question "do we actually have the people for this" almost always gets asked too late — after the project has already been committed to, not before. Capacity overviews usually exist, but they live in a different system from the one the decision was made in.

Delivery to course-correction. Status becomes a colour on a dashboard, set by hand. That colour rarely gets fed back to the theme the project was meant to serve, and almost never to the decision that made the project possible in the first place.

What "fixing" this actually takes

You don't close those six gaps with an extra report. They call for three things that are usually missing, in this order.

A decision needs to be a record, not a memory. Who decided, when, and — for a rejection — why. Not to hold anyone to account after the fact, but because a project with no traceable decision behind it is a project nobody can explain any more.
Capacity needs to be visible before the decision, not after. An overview that only shows there's no room once the commitment has already been made arrives too late to change anything.
And the report that shows the whole picture needs to draw on the same data as the place the decision was made — not a separate summary that's a few weeks behind.

What Migreat! already closes today

A few of those links are a built-in part of the system in Migreat! from Promigion, not something you have to organise yourself.

You link an idea directly to a strategic theme and, optionally, to an objective beneath it. What that link actually gives you is covered on the strategic themes and objectives page.

A decision is a record, not a memory. Who decided and when is fixed; a rejection always requires a reason, an approval does not. You can revisit a decision, but not by editing the old one — a new decision is always a new entry, and the old one stays exactly as it was. How a request actually reaches that decision is covered on the from idea to an approved project page.

That approval is also a hard requirement: an idea only becomes a project after a recorded approval. Without that record, the conversion simply doesn't happen.

There's an overview that sets an idea's demand — its estimated hours — against available capacity, visible before a decision gets made. The same overview ranks ideas by that capacity pressure too, alongside priority and deadline.

Progress on a project rolls up to its theme and the objective beneath it, in a single report — including the status you set on it yourself. That status has four values — green, blue, amber and red — and blue means done. You set it yourself; it isn't calculated automatically.

What isn't connected yet

Two things aren't linked to each other yet, and it's more honest to say so here than to let you find out later.

The capacity overview is informative, not a gate. An idea flagged as "waiting on capacity" can still be approved — the system doesn't stop anyone. The overview puts the information on the table; the decision stays with the person making it.

And the report that shows theme, objective and project status together doesn't include the decision itself. Who decided, and why, lives on the idea's own page — not in the overview where you see how a theme is doing.

How to tell whether this is happening in your own organisation

You don't need to open any software to know whether this applies to you. Three questions usually settle it quickly.

Can you work backwards from a live project to the theme it was meant to serve, without phoning someone who still remembers it by heart?
Can you find a record of last quarter's decision — who said yes, and why — or does it only live in someone's inbox?
Did you know there wasn't enough capacity beforehand, or did you find out once the project was already under way?

A "no" to one of the three is normal. A "no" to all three means it's a pattern, not an incident — and that's the actual problem.

Why capacity is visible before a decision but not decisive is covered in the guide capacity management for projects. How this link — from prioritising to a decision — becomes a permanent record instead of a nod in a meeting is covered in the guide prioritising projects. And why a report needs to draw on the same data as the place a decision was made is covered in the guide progress reporting. More on this subject is in the guides. If you sit in executive management and sign off on these decisions, the page for executives and management covers specifically what that decision trail gives you.