PMP Project Status: Metrics, Earned Value, Burn Charts and Status Reporting

A good project metric answers a question a decision-maker actually has, is collected objectively and cheaply, and leads to action when it moves. Before adding a measure, agree what it is for: tracking delivery, predicting trouble, or showing whether the project is producing the value it was funded for. This is the first enabler of the task, develop project metrics, analysis, and reconciliation.

Output versus outcome

An output metric counts what the team produced (features released, story points completed, defects closed, documents delivered). An outcome metric shows the effect the output has on the business or its users (calls deflected from a service desk, adoption, cycle time saved, revenue, error rates in operations). Output metrics show the team is busy; only outcome metrics show the project is delivering the benefit in its business case. A report made only of output figures can show a busy team while saying nothing about whether the benefit in the business case is arriving; answering that needs an outcome measure tied to the stated benefit.

Leading versus lagging

Most standard project reports (variances, completed milestones, closed defects) are lagging. A status view built only from lagging measures confirms problems after the fact; leading indicators, which track the upstream conditions that cause variances later, give the early warning.

Metrics that mislead

• Vanity metrics look good but drive no decision, such as page views of a repository or the number of documents produced.
• Goodhart's law: once a measure becomes a target, people optimise the measure rather than the result. Turning velocity into a quota invites point inflation, not more delivered value.
• Velocity is a team-specific planning measure. Each team sizes stories on its own relative scale, so velocities cannot be compared across teams, and normalising points does not fix that. Compare teams, if at all, on delivered outcomes, quality and predictability.
• Single metrics hide trade-offs. Pair a speed measure with a quality measure (velocity with escaped defects, throughput with rework) so one cannot improve at the other's expense unnoticed.

Scope note: forecasting the final cost (EAC, ETC, TCPI) belongs to the finance task, and choosing communication channels belongs to the communications task. This lesson reads current status and reports it.

Progress should be credited by a rule agreed in advance, not by asking people how far along they feel. Subjective percent complete is cheap but unreliable: earned value swings every time someone revises a guess, and work tends to sit at "90% complete" for weeks. The standard earned value measurement methods, set out in PMI's earned value practice standard, let the project manager pick the most objective method each kind of work allows.

Two patterns are worth remembering. A long package measured 0/100 shows no earned value for months and makes a healthy project look behind; splitting it into weighted milestones credits progress as each stage is verified. And level of effort never shows a schedule variance, so it should be kept to genuine support work, or it hides problems in real deliverables.

Agile work: done means done

In agile delivery a user story earns credit only when it meets the definition of done and is accepted by the product owner, effectively 0/100 per story. Partly coded stories earn nothing, however many hours went into them. Velocity likewise counts only accepted work: whatever a tracking tool marks as finished, the figure that counts is the work that met the definition of done and was accepted, and anything that fell short returns to the backlog.

Earned value management (EVM) shows current schedule and cost status by comparing three figures: planned value (PV), the budgeted cost of work scheduled to date; earned value (EV), the budgeted cost of work actually performed; and actual cost (AC), what that work really cost.

Schedule status always compares earned value with planned value; cost status always compares earned value with actual cost. Comparing actual cost with planned value says nothing about efficiency, because it ignores how much work was done. For example, with PV of 800, EV of 880 and AC of 1,000 (in thousands), SPI is 1.10 and CPI is 0.88: the project is ahead of schedule but over budget, because it is buying its extra progress at a higher cost than planned.

Where the indices mislead

• SPI is blind to the critical path. It totals value across all activities, so noncritical work running ahead can produce a favourable SPI while a critical-path activity is weeks late and the finish date is at risk. Always read SPI alongside the critical path and milestone dates.
• SPI drifts to 1.0 at completion. When all work is done, EV equals the total budget, which equals PV, so SPI returns to 1.0 even on a project that finished months late. Late in a project, trust the dates; earned schedule is the technique that corrects this distortion.
• A good CPI with a poor SPI often means work has not been performed rather than money saved: work that has not started has not cost anything yet, so the apparent underspend is mostly spending still to come, not efficiency.
• Look at trends, not just cumulative values. A cumulative CPI moves slowly; a falling period-by-period CPI is the earlier warning.

Burndown and burnup charts show agile progress against time; the difference is how they handle scope. A burndown plots work remaining, so added scope and completed work cancel each other out and the line can look flat while the team is delivering. A burnup plots completed work and total scope as two separate lines, so stakeholders can see both progress and scope change.

Forecasting a release from velocity

Velocity is the amount of accepted work a team completes per iteration. To forecast a release, divide remaining work by observed velocity, and give a range rather than a single date: dividing by the highest and lowest recent velocities brackets the likely number of iterations (for instance, 150 points at 25 to 30 points per iteration is five to six iterations). Stating the basis (the velocity range and the assumption that scope stays stable) lets stakeholders decide with a realistic view of uncertainty, rather than an optimistic average.

When velocity changes

A velocity drop, or a rise alongside worsening quality, is a signal to investigate with the team, not a figure to set as a target. Responses that manage the number rather than its cause, such as targets, re-estimation or extra capacity added before the cause is understood, treat the symptom. Explore causes (impediments, absences, technical debt, larger stories, rising defects) and act on what the team finds.

Flow metrics measure how work moves through a workflow, which suits kanban teams and continuous support work that does not run in iterations or estimate items. The core measures are:

The cumulative flow diagram

A cumulative flow diagram (CFD) stacks the number of items in each workflow state over time. The vertical thickness of a band is the work sitting in that state; the horizontal distance from the first in-progress band to the done band approximates average cycle time (measured from the first, request band, it approximates average lead time). A band that widens steadily marks a bottleneck: work is arriving at that stage faster than it leaves. The fix starts at that constraint, by investigating it with the team and limiting WIP there, not by pushing more work in upstream.

WIP, cycle time and forecasting

Little's Law links the three: average cycle time equals average WIP divided by average throughput. With throughput flat, more WIP simply means each item waits longer, so lowering WIP limits is how a team shortens cycle time without working faster. For forecasting without estimates, use history: the distribution of past cycle times for similar items gives a probabilistic answer ("85% of items like this finish within 9 days"), which is more honest than story-point velocity or a bottom-up estimate the team does not normally make.

Measuring is only useful if the project manager analyses the results before acting: compare against thresholds, look at the trend, find the cause, and check that the data is consistent. This is the enabler measure, analyze, and update project metrics, with the reconciliation part of the first enabler.

Thresholds versus trends

Variance thresholds in the management plans (for example a percentage on a control account) define when a formal response or escalation is required. A variance inside the threshold is not automatically fine: a variance that worsens every period will breach it soon. Analyse the cause of a worsening trend while it is still inside the threshold, then choose a response. Formal escalation or a request for more resources follows the analysis; it does not replace it.

Root cause before corrective action

Whatever the metric, the sequence is the same: confirm the data, analyse the cause (with the team that does the work), then act and update the forecast. Related metrics should be read together; if throughput climbs while rework or customer-reported defects climb with it, the gain may be coming from cut corners, and that link needs exploring before the result is praised or corrected.

Reconciling conflicting sources

Different sources often disagree: a timesheet-based estimate and a count of verified units, a supplier's progress claim and inspection records, a programme schedule and a team's own forecast. Before reporting, the project manager reconciles them:

• compare the sources and find why they differ (different definitions of complete, timing, scope changes);
• rely on the most objective evidence, such as acceptance or passed tests, rather than self-reported progress;
• agree objective completion criteria with whoever reports progress, so the conflict does not recur;
• then report one consistent figure with its basis, and forecast from it.

The principle is to analyse and reconcile first: any report, escalation or change decision should rest on the reconciled figure, not on whichever source arrived first.

On a hybrid project, status for governance combines predictive measures (schedule milestones, float, earned value) with adaptive ones (burnups, velocity, accepted scope) in one view, without forcing either side to change how it tracks its own work. The roll-up translates each stream's own forecast onto the shared milestones the steering committee cares about.

• Percent complete for an agile component is accepted work divided by the current release scope. Measures of time or effort spent show consumption, not progress, opinion is not evidence, and the denominator must reflect the backlog as it stands now.
• Cadence is not convergence. Holding every planned iteration on time says nothing about whether the remaining scope will be done by the milestone. The release-level forecast, built from accepted work and current scope, is the truer picture, and any disagreement between the schedule and that forecast is reconciled before reporting.
• For a joint milestone, combine each stream's forecast: milestone status and float from the predictive schedule, and the release burnup forecast mapped to the same date. Low-level detail from either stream does not tell the committee whether the date holds; the mapped forecasts do.
• A joint milestone is only as early as its latest critical dependency. If the software forecast is ahead but a predictive dependency it needs has slipped with no float, the joint date is at risk, and the slipping dependency is the driver to report. Being early in one stream does not offset a slip on the critical path in another.

A status communication tells its audience where the project stands against plan, where it is heading and what they need to do about it. An activity list ("what we did this week") does not answer the question sponsors actually ask: will we meet our commitments?

Useful status content includes:

• Progress against the plan or baseline: milestones, scope delivered and accepted, schedule and cost performance.
• A forecast with its basis: the expected finish or release date (as a range where uncertainty is real) and the data or assumptions behind it.
• Trends, not just snapshots: is performance improving or worsening?
• Causes and responses for significant variances: what happened, why, and what is being done.
• Material risks and issues, especially those affecting the critical path or key commitments.
• Decisions or support needed from the audience, with the date they are needed by.

Steering-level reports stay at the level of decisions: granular effort data and exhaustive metric dumps bury the message, and a baseline is never quietly moved to absorb a delay, because a rebaseline is a change that needs approval, not a reporting convenience.

Honest status, reported on time

Status must reflect reality when it happens. A slip on the critical path is reported now, together with the recovery plan and how confident the team is in it, not hidden behind a green rating while the team hopes to recover. Optimistic "watermelon" reporting (green outside, red inside) removes the sponsor's chance to act while options are still open, and it conflicts with PMI's Code of Ethics standard of honesty. Honesty also means proportion: report the facts, the response and the confidence, and let the agreed thresholds and change control decide the rating and any rebaseline.

Project artifacts are the templates, documents, outputs and deliverables a project creates to plan, track and record its work. A common grouping, used in the PMBOK Guide 7th edition, is strategy artifacts (business case, charter, roadmap), logs and registers, plans, hierarchy charts (WBS, organisation charts), baselines, visual data and information (burn charts, dashboards, CFDs), reports, agreements and contracts, and others.

Identify and tailor what the project needs

Each project should produce the artifacts that add value for its approach, size and governance needs, and no more. A heavyweight artifact set designed for large predictive programmes can cost a small adaptive team more than it returns, yet dropping governance templates unilaterally is not the answer either. Agree a tailored artifact set with the PMO or governance body that still gives them what they need. Tailor by scope as well as approach: where a regulator requires evidence (for example an evidence trail for a privacy or financial-control requirement), apply full rigour to that regulated scope and keep everything else lightweight.

Logs and registers that are easy to confuse

Created, reviewed, updated and documented

Artifacts stay trustworthy when:

• each one has a named, accountable owner (ownership follows accountability, so a product backlog belongs to the product owner; the project manager supports owners in keeping artifacts current rather than taking them over);
• there is one authoritative copy under version or configuration control, with change history, because duplicate copies drift apart;
• approved changes flow to every affected artifact: after the change control board approves a change, the scope statement, WBS, schedule and other baselines are updated under configuration control, with the approval itself as the authority for those updates;
• artifacts are reviewed when the decisions behind them change, so stakeholders do not plan from an out-of-date roadmap.

An accessible artifact reaches every person who needs it, in a format they can use, with access that matches their role. Documents kept on one person's laptop and emailed on request are not accessible: distributed teams work from outdated copies and wait for replies.

• One shared repository with access rights replaces emailed copies and keeps everyone on the current version.
• Role-based access: give people what they need and no more. Stakeholders who only need to see progress get view access sized to that need; an external party sees what its agreement allows and nothing more.
• Accessible formats: text-based dashboards and documents work with screen readers; images of charts do not. Meeting one need (wider visibility) must not break another (confidentiality or accessibility).

Continually assessing artifact management

Artifact management is effective when the artifacts are used, current and trusted, not when there are many of them. Good indicators are that decisions trace to current, approved versions; people find what they need without asking the project manager; and artifacts are updated when things change. Counts of how much exists or how often it is opened say little about whether it is useful.

Act on what the assessment shows. When people repeatedly ask for information an artifact already holds, find out how they use it before changing the artifact or how it is distributed. When an artifact costs effort to maintain but no longer informs anyone, confirm that no stakeholder, contract or audit obligation still depends on it, then retire it; keeping it out of habit and deleting it unchecked are both poor artifact management.