Portfolio Risk Radar
Route: /org/risk · Permission: View risk radar
Module: Task Management · Entry points: Global search "portfolio risk" · Cockpit → Risk Radar tile · Risk Radar panel
What this is. Delivery risk across every project you are on, in one screen. What it is for. Seeing the trouble that no single project's radar can show you. The problem it solves. A person at 90% on three projects looks fine on all three and is 180% committed in reality.
1. What the page shows
Four things, in order of how often they change a decision:
- Headline totals — projects scored, projects at risk, tasks at risk, milestones about to slip, and how many people are over capacity.
- Project health — a card per project, worst first, with the deterministic explanation of why.
- Milestones about to slip — across every project, with the P80 finish date where a delivery forecast exists.
- Load across projects — the number this page exists for. See §3.
Opening the page computes nothing and costs nothing. It reads the snapshots the nightly job already wrote.
2. Who sees what
| You are | You see |
|---|---|
| A project member | Only the projects you are an active member of |
| A super admin | Every project in the organization |
A project the nightly job has not scored yet is listed as not scored, not quietly omitted — so "3 of 5 projects scored" is the truth rather than a flattering subset.
3. Load across projects — read this bit
Each project's radar computes a person's capacity as their daily hours × the days in the horizon. Every project does that independently, so every project claims the same real hours.
This page does not add those capacities together. If it did, someone at 90% on three projects would still read 90% — and the one number this page exists to surface would be invisible.
Instead it adds up the work and divides by one calendar:
Asha has 36 hours left on Alpha and 36 on Beta, each against a 40-hour horizon. Each project sees 90%. This page sees 72 hours of work against 40 hours of time — 180%.
Anyone over 100% here is over-committed no matter how comfortable each individual project looks. Their worst single-project severity is kept too, so a critical on one project is never masked by slack on another.
4. The trend
The bar chart is tasks at risk over the last 30 days, from a daily org-wide rollup the nightly job writes. It answers "are we getting on top of this, or is it growing?" — a question no single snapshot can.
The rollup is derived from the same stored snapshots the page reads, so the trend and the page can never disagree with each other.
5. The cockpit tile
A Risk Radar tile appears on the cockpit for anyone with View risk radar, showing the three worst projects with their one-line explanation. It hides itself entirely until something has been scored, rather than sitting there empty.
6. Administrator setup
| Step | Where |
|---|---|
Apply migration 001171 | Release-0.1.6/ |
| Enable Task Risk Radar Daily | Super Admin → Jobs |
Grant View risk radar (task.ai.risk.view) | Settings → Roles |
No new permission is introduced — the page reuses the risk radar's own.
7. Downstream
- Each project card links to that project's Risk Radar panel
- Milestone rows show the P80 finish once the forecast has run
- The cockpit tile reads the same data
8. Don't confuse this with…
| This | That |
|---|---|
| Portfolio risk — every project you are on | Risk radar — one project, in detail, with AI interventions |
| Combined load — one person across all their projects | Team load on a project's radar — that project's slice only |
| Projects scored | Projects that exist. The gap is projects the nightly job has not reached |
9. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| "None of your projects has been scored yet" | The nightly job has never run | Enable Task Risk Radar Daily, or press Recompute on one project's radar |
| A project is missing | You are not an active member of it | Ask to be added; super admins see everything |
| The trend is empty | Fewer than two days of rollups exist | It fills in as the job runs; migration 001171 must be applied |
| Someone reads over 100% but looks fine on each project | That is the point — see §3 | Rebalance across projects, not within one |