Updated · All guides
The short answer
A software delivery PMO needs KPIs that predict missed commitments, not just count activity. Track twelve across five areas: portfolio health, predictability, flow, capacity and governance. Report three to five of them to executives, always as a trend, and keep them at project, team and portfolio level. Never use them to rank individual developers.
The targets below are starting points to adjust once you have a few months of your own history, not industry benchmarks.
Portfolio health
| KPI | Formula | What good looks like |
|---|---|---|
| 1. Projects at risk | (amber + red projects) ÷ active projects | Stable or falling over several weeks |
| 2. Average delivery risk | Mean of every project's 0–100 risk score | Falling; investigate any three-week rise |
| 3. Red without warning | Projects that went red without being amber the week before, per quarter | Zero. Every red should have been amber first |
KPI 3 measures the PMO itself: how early it sees trouble. It only works if status comes from consistent signals rather than self-reported colours; see project risk scoring vs RAG status.
Predictability
| KPI | Formula | What good looks like |
|---|---|---|
| 4. On-time delivery | Milestones or releases delivered by the committed date ÷ those due in the period | Rising; pair it with KPI 5 so small slips are not hidden |
| 5. Average slip | Mean days between committed and actual date, for late deliveries | Shrinking |
| 6. Forecast reliability | Projects whose forecast is high, medium or low confidence, based on estimate, due date and assignee coverage | Most projects high or medium before dates are committed |
Always report on-time delivery with the slip: 90% on time with a 60-day average slip on the rest is a different story from 80% with a 5-day slip. KPI 6 tells you whether the dates behind KPIs 4 and 5 were ever trustworthy; see how to forecast a delivery date from Jira.
Flow
| KPI | Formula | What good looks like |
|---|---|---|
| 7. Blocked work | Blocked items ÷ all items, per project and across the portfolio | Below 20% on every project |
| 8. Overdue work | Open items past their due date ÷ open items | Low and not rising |
| 9. Scope growth | Items created ÷ items completed, per week | Below 1 as a project approaches its date |
The most common bottleneck across projects is worth reporting on its own. If blocked work tops the list on half the portfolio, the fix is usually outside any one team, such as a shared environment or an approval step.
Capacity
| KPI | Formula | What good looks like |
|---|---|---|
| 10. People overloaded | People allocated above their capacity across all projects ÷ people allocated | Close to zero |
| 11. Load on available capacity | Total allocation ÷ capacity left after approved leave, for the next 30 days | Roughly 70–85%, leaving room for unplanned work |
Calculate capacity per person first and then aggregate; a healthy team average can hide two people at 150%. The method is in capacity planning when people are on leave.
Governance
| KPI | Formula | What good looks like |
|---|---|---|
| 12. Critical alerts acted on | Critical risks with an owner and agreed action within 48 hours ÷ critical risks raised | All of them |
It is also worth tracking, privately, how many hours the PMO spends compiling status each week. If it is more than a couple of hours, the reporting is manual enough to be late and stale by the time it is read.
KPIs to avoid
- Story points or tickets per developer. Easy to game, discourages helping others, and says nothing about commitments.
- Velocity compared across teams. Story points are not a shared unit; each team sizes differently.
- Utilisation targets of 100%. They guarantee that any surprise causes a slip.
- Number of status reports produced. Measures effort, not outcomes.
- Self-reported RAG counts. They measure optimism as much as risk.
How to report them
- To executives, monthly or in the weekly brief: KPIs 1, 3, 4 and 10, each with a trend line and one sentence of interpretation.
- To delivery leads, weekly: all twelve, per project, with the projects driving each number named.
- Always as a trend. A single month's value invites arguments about the number; three months shows the direction.
- With the cause next to the number. "Projects at risk rose from 3 to 5, both new ones blocked on the shared test environment" is a KPI someone can act on.
The weekly executive status report template has space for the headline KPIs.
Which of these Exentras calculates
Exentras calculates the portfolio health, flow and forecast KPIs automatically from your Jira Cloud projects, team allocation and approved leave: green, amber and red project counts, projects at risk, average delivery risk, blocked and overdue work, the most common bottlenecks across projects, and forecast reliability by project. Team capacity, on Growth and Enterprise, shows who is overloaded across projects after approved leave. The weekly executive brief ranks projects by risk and reports these numbers in one place.
On-time delivery, average slip and alert response depend on your own release and governance records, so track them alongside. See a sample executive brief or compare plans.