Delivery risk is the chance a project ships late, over budget, or below spec. Execution risk is the chance the project ships exactly as planned and still moves nothing the company currently cares about. Most organisations run a disciplined process for the first and no process at all for the second.
Look at any risk register and the entries follow a pattern. Vendor dependency slipping. Key engineer on leave in August. Scope creep on the migration. Integration testing compressed into the final sprint. Every one of those is a delivery risk: a threat to the plan being carried out as written.
Now ask a different question about the same portfolio. If every single project on that register lands on time and in full, does the company hit its strategy? Nobody has a register for that answer, which is why the answer usually arrives late and by accident.
What each risk actually measures
Delivery risk lives inside the project boundary. It has an owner, a mitigation, a review cadence, and a well-understood vocabulary. Project managers are trained on it, and they are generally good at it. The discipline works.
Execution risk lives on the edge between a project and the goal that justified it. It is the distance between where the strategy says effort should go and where the effort is actually going. It appears when a goal changes and the work beneath it does not, when a project is staffed at a level that does not match its strategic weight, or when a KPI the board watches is being carried by work nobody has flagged as important.
The two risks are independent. A project can be at zero delivery risk and at severe execution risk at the same time. In fact that combination is the common one, because a well-run project with a confident team produces exactly the kind of green status that stops anyone from asking the second question.
Why the register only covers one
Delivery risk is observable from inside the project. The people running the project can see the dependency, the scope change, the resourcing hole. They raise it because it threatens something they are accountable for.
Execution risk is only observable from a position that can see the goal and the work at the same time. The team shipping mid-market features cannot see that the mid-market objective was softened in a leadership session six weeks ago. The executive who softened it cannot see that three sprints of work are still queued against it. Neither party is being careless. The information that would connect them does not exist in one place.
That is the structural reason execution risk goes unmanaged: it does not belong to any single role, and it is invisible in every artefact that a single role produces. This is the effort-to-goal gap in its operational form.
The shapes execution risk takes
Work outliving its rationale. The strategy moved. The projects underneath it did not. Effort continues at full speed against an objective the company walked away from. The initiative that outlived its reason is the cleanest example.
Weight mismatch. A project quietly carries a KPI leadership is watching, but it is ranked as background work and staffed accordingly. Or the reverse: a highly visible initiative absorbs three engineers when it needs one half-time.
Starved priority. A goal named critical at the offsite has almost no real work attached to it. This is cheap to fix in week two and expensive to discover in month three.
Duplicated effort. Two teams building toward the same outcome without either knowing, usually visible only when someone reads across both backlogs.
None of these show up in a percent-complete field, because percent complete is not progress. They show up in the relationship between the goal and the work, which is a relationship most tools do not store.
Putting execution risk on the register
The practical move is to give execution risk the same treatment delivery risk already gets: a defined set of conditions, a review moment, and an owner.
Conditions worth watching, and each one is checkable rather than a matter of opinion:
- A goal whose target or scope changed in the last quarter, with active work still pointed at the prior version.
- A KPI running behind pace where no in-flight work is connected to it.
- A goal with an owner and a target but no tasks underneath it.
- A person carrying assigned effort against four or more objectives at once.
- A project with no activity for three weeks that still reports on track.
Reviewing those conditions monthly costs less than an hour and catches most of what a status meeting structurally cannot. The portfolio review is the natural place for it, as long as the review reads the underlying work rather than a slide summarising it.
The harder part is the data. Each of those conditions needs the goal layer and the work layer joined, at task level, with history. That is exactly what connecting effort to goals provides, and why execution risk becomes a measurement rather than a suspicion once the join exists.
The question to ask in the next review
For each significant initiative, ask two questions instead of one. Will it ship as planned? And if it ships as planned, which goal moves, and is that goal still one the company is pursuing this quarter?
The first question has an owner already. The second one determines whether the first one was worth asking.