Blog: A strategic framework for monitoring project health

A blueprint for project health monitoring using weighted milestones, Fibonacci estimation, and risk-informed progress tracking.

Every project manager (PM) gets asked the same question: Are we going to finish this project on time and on budget? To answer it, they usually would rely on delivery plans, burn charts, milestone trackers, and team estimates...

And whilst these tools are useful, they rarely provide the PM with a single, structured view that brings together delivery progress, budget consumption, and delivery exposure in a way that supports consistent judgement. Experienced PMs often develop a strong instinct for when something is drifting. That instinct is real and earned. But instinct alone is difficult to evidence, difficult to transfer, and difficult to defend when delivery confidence needs to be explained. That is the structural gap this framework addresses.

The PM is accountable for assessing delivery confidence, but depends on signals owned by others. The team estimates effort. Finance tracks cost. Stakeholders define priorities. The PM interprets these signals, forms a view, and is expected to explain whether delivery remains viable.

This judgement often remains undocumented, not auditable, and not easily replicated consistently across different PMs or projects.

The Weighted Delivery Index (WDI) introduces a structured way for the PM to interpret delivery signals through their own documented judgement. By combining weighted milestone progress, budget consumption, and delivery exposure, it creates a consistent, auditable view of project health that supports earlier intervention and clearer governance.

Why existing frameworks fall short

Earned Value Management compares planned value, earned value, and actual cost to indicate whether spending aligns with delivery. Agile metrics such as velocity and burndown show how quickly work is being completed.

Both are genuinely useful. But both carry limitations that matter at project level.

Earned Value relies on percentage-complete assumptions that are often subjective and hard to validate. It also assumes that the pace and complexity of work will remain roughly constant across future phases, an assumption that rarely holds in practice, especially as projects move from definition into delivery, or from build into close-out.

Agile metrics have a different problem: they were designed for iterative delivery cycles, and within sprints they work well. But discovery and end-of-project activities don't fit neatly into sprint cadences, which means velocity and burn down can tell an incomplete story across the full project arc. Budget tracking adds another layer of complexity that sprint-level frameworks weren't really built to carry.

Across both approaches, the same gap remains. They describe what is happening but neither gives the PM a structured way to express how much meaningful project progress has been achieved relative to the budget consumed, or a structured way to translate that into a clear health assessment.

A project-level interpretation of scrum thinking

The WDI is not a replacement for Scrum. It is a deliberate adaptation of its core principles, relative estimation, continuous re-assessment, and transparency, applied at the project level rather than the sprint level.

In Scrum, the team estimates backlog items using relative sizing, typically story points on the Fibonacci scale. The logic is not to predict effort precisely, but to express relative complexity and uncertainty in a way that can be compared and tracked over time. The WDI applies exactly the same logic to milestones.

In Scrum, estimates are revisited as the team learns more. Velocity shifts. Backlog items are re-pointed. The sprint plan adapts to reality rather than defending the original assumption. The WDI applies the same discipline at the project level: milestone weights are updated as the project reveals itself, and every change is documented with a reason.

In Scrum, the sprint review and retrospective create a regular moment of honest assessment: what was delivered, what was learned, what changes. The WDI creates the same cadence at project level, replacing subjective status updates with a structured, evidence-based view of delivery confidence.

What the WDI adds, and what sprint-level Scrum was never designed to provide, is a mechanism for connecting delivery progress directly to budget consumption across the full project lifecycle.

How the framework works

At project start, the PM defines the key milestones across the project lifecycle, which is a familiar exercise. It also makes sense for the PM to specify what a milestone actually is: a meaningful delivery outcome that can be assessed as either complete or incomplete. Not a task, not a phase, a clear, binary signal that something of substance has been delivered.

Each milestone is assigned a relative weight using the Fibonacci scale - 1, 2, 3, 5, 8, 13 - based on its delivery significance. This is the same relative sizing logic used in Scrum, applied to the project milestone map rather than the sprint backlog.

Four considerations drive each weight: complexity, uncertainty, dependency, and delivery exposure. Low weights reflect familiar work with manageable unknowns. Higher weights signal milestones where successful delivery depends on unresolved risks, external dependencies, or conditions that aren't yet clear.

A milestone weighted 13 doesn't mean the project is in trouble, it means delivery confidence on that piece of work has not yet been established. That's acceptable, but it should trigger action. A milestone at 13 should always carry an associated mitigation plan, and as a rule it's not advisable to begin execution until that weight can be brought down. The expectation is that the PM acts to reduce exposure before work starts.

As the project progresses and more becomes known, the PM can reassess and update milestone weights to reflect the current reality. Just as a Scrum team re-estimates the backlog at the start of each sprint, the PM re-weights the milestone register as the project reveals itself. This keeps the framework live rather than static, a running expression of what the PM actually knows, not just what was assumed at kick-off.

That's what makes the weighting process both an assessment tool and a planning discipline.

A typical digital project breaks down like this:

Calculating Project Health

Once the milestones are weighted, the PM has the baseline needed to produce a meaningful project health signal, they calculate Total Project Weight which is the sum of all the weights assigned to the milestones and they have the Total Budget. the gap between the two provides an early indication of whether the project may be drifting from its original assumptions.

At any stage when the project starts, project health can be evaluated calculating:

Delivery Progress % = Completed Weight ÷ Total Project Weight

This gives the PM a structured view of how much of the project’s weighted delivery significance has been achieved.

For example, if the total project weight is 40, and milestones worth 10 have been completed:

Weighted Progress = 25%

It means that 25% of the PM’s weighted delivery baseline has been achieved.

And budget consumption:

Budget Burn % = Cost Incurred ÷ Total Budget

This shows how much of the project budget has been consumed.

The difference between the two measures indicates whether the project is drifting:

Drift % = Budget Burn % – Weighted Progress %

Here is when we evaluate the impact of drift on project health:

• A positive drift means the project is consuming budget faster than weighted delivery progress is being achieved.
• A negative drift means delivery progress is ahead of budget consumption.

This provides an early signal that the project may be moving away from the assumptions on which the original weighting was based.

That signal gives the PM an opportunity to intervene before the budget position becomes critical.

A worked example: Reading the register mid-project

The table shows a project at the midpoint of development: Discovery and Design fully closed, Sprint 1 done, Sprint 2 in flight, everything else ahead.

The numbers suggest a potential concern: 46% of budget has been consumed, while only 35% of weighted delivery has been achieved. That's an 11-point drift, not a crisis, but a signal. And crucially, the heaviest milestones are still ahead: client acceptance sits at 13 with no mitigation plan yet, UAT resourcing is unconfirmed, and go-live infrastructure hasn't been provisioned.

That is the kind of exposure this framework is designed to surface, not "are we behind?" but "where is the exposure, and do we have time to act on it?"

The discipline of re-estimation

Just as a Scrum team re-estimates the backlog as they learn more, the PM updates milestone weights as the project reveals itself. A risk that looked like a 13 gets resolved and becomes an 8. A milestone that seemed straightforward surfaces unexpected complexity and moves up. That's not a flaw in the framework, that's the framework working.

What it requires is that every change is documented. A weight that moves needs a note: what changed, when, and why. What it doesn't tolerate is a revision without a reason. A 13 that quietly becomes a 5 because the phase is about to start isn't an updated assessment, it's optimistic bias with a different label.

Over time, the register becomes something more than a tracker. It becomes the PM's end-to-end story of the project, original assumptions, revisions, reasons, and the decisions that followed. By the time the final milestone closes, the PM has a complete documented account of how their thinking evolved from day one.

Conclusion

The WDI model applies the logic of Scrum, relative estimation, continuous re-assessment, and structured transparency, at the project level, connecting delivery progress directly to budget consumption across the full project lifecycle.

It does not replace team estimates or financial controls. It sits above them: a PM-owned view of delivery confidence that is explicit, auditable, and trendable through every stage of the project.

When the difficult conversation comes, and it always does, the PM isn't reconstructing a narrative from a cost report that no longer reflects reality. The story is already written: what was believed at the start, what changed and why, where action was taken, and where it should have been taken sooner.

The WDI model provides a structured PM-owned view of delivery progress, cost consumption, and remaining delivery exposure, making delivery confidence explicit, auditable, and trendable through the project lifecycle.

If you're using something similar or have questions about how the framework applies to your context, we'd welcome the conversation.