To get one view of status across all client projects, agree a small set of status fields that every engagement reports the same way, pull most of them from the tools each team already uses, and replace the written report with a short PM sign-off on health and the reason for it. The roll-up then shows which projects changed, which are at risk, and what is waiting on the client, with a link back to the evidence behind each line.
What should every client project report the same way?
Every client project should report the same few fields: overall health with a one-line reason, the next milestone and its date, open blockers on the client side, decisions waiting on the client, and what changed since the last review. Keep the list short. Each extra field is something a PM has to maintain on every engagement.
The PMI Learning Library stresses using a status format that is the same on every project, so leaders can read all of them at a glance. Here is a starting set to adapt:
| Field | What it holds | Where it usually comes from |
|---|---|---|
| Health | Red, amber or green | PM sign-off, checked against rules |
| Reason | One line explaining the health | PM sign-off |
| Next milestone | Name and due date | Project plan or task tool |
| Client blockers | Open items waiting on the client | Task tool label or tag |
| Decisions waiting | Decisions the client owes, with dates asked | Task tool label, decision log |
| Changed since last review | Milestones moved, health changed, new blockers | Comparing this review to the last |
| Source link | Where to see the evidence | The project's own tool |
Resist adding budget, utilisation and scope fields to the first version. Add them once the core fields are reliable.
The decisions waiting field is often the one that holds a project up longest, so make each decision easy for the client to answer. Unblockd offers asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.
How do you define red, amber and green so projects compare?
Red, amber and green only compare across projects when the firm writes down what triggers each one and every PM uses the same rules. Without rules, a roll-up mixes one PM's caution with another's optimism. The Teamwork.com status report guide builds its executive summary around RAG status but does not say what makes a project red, amber or green, so you need your own.
Copy this into your delivery handbook and fill in the thresholds your practice agrees on:
Green: next milestone on track for [date]; no client blocker older than [period]; no decision overdue.
Amber: next milestone at risk of slipping by up to [period]; or a client blocker open longer than [period]; or a decision overdue but not yet affecting the plan.
Red: a milestone date will move; or a blocker or decision is now delaying delivery; or [budget or scope trigger your practice uses].
A PM may override the rule, but must say why in the Reason line.
The override matters. It keeps judgement in the loop and makes disagreement with the rule visible rather than hidden.
How do you pull status from different tools without migrating?
You pull status from mixed tools by deciding, for each field, where it lives in each project's tool, and using labels or fields there instead of moving the work. Most engagements can keep their own Jira, Asana, Linear or GitHub setup. The roll-up reads from them; it does not replace them.
- List every live engagement and its tool. Note which projects run in the client's own tools, where you may only have read access.
- Map each field to a place in each tool. For example, a label such as [client-blocker] for blockers, a label such as [decision-needed] for decisions, and a milestone or epic for the next milestone.
- Set the same labels in every tool. Ask each PM to add them to their project early in the change, and to the template for new engagements.
- Turn chat into labels. When a client blocker or decision comes up in a Slack channel or thread, the PM adds the matching label to a task in the task tool and links the thread there. The roll-up picks up the label; the chat thread itself is not the record.
- Choose one roll-up place. That can be a shared sheet, a portfolio board in the tool your firm already uses most, or a reporting layer that reads from several tools. Each row is a project; each column is a field.
- Keep the source link on every row. Partners trust a line they can click through to.
Not every field can be read automatically. Milestone dates and labelled blockers and decisions can usually be read straight from the tool, while health, the reason line, and anything in a client's tool where you only have read access are confirmed by hand by the PM at sign-off.
Updating status from the work itself saves the most PM time. The monday.com portfolio guide for tech PMs describes syncing with GitHub and other developer tools "so teams update once and stakeholders see progress everywhere." The same principle works in any tool: if finished tasks and closed milestones drive the fields, PMs stop retyping them.
What does the PM still have to add?
The PM still adds judgement: confirming health, writing the one-line reason, and checking that blockers and decisions are current. That short sign-off replaces the written report. The Teamwork.com guide puts it this way: "The numbers should pull themselves from your project management platform. Your time is better spent explaining what the data means and what to do about it."
Give PMs a fixed sign-off they can complete in the tool, before the delivery review:
Project: [client] / [engagement]
Health: [Red / Amber / Green] Rule-based or override: [rule / override]
Reason: [one line, e.g. "Waiting on [client role] to approve [deliverable] since [date]."]
Client blockers confirmed current: [yes / updated]
Decisions waiting confirmed current: [yes / updated]
Help needed from delivery leadership: [none / what, from whom, by when]
The last line is the one partners act on. Make it easy to say "none".
How often should the roll-up refresh?
The roll-up should refresh the data fields continuously or daily from the tools, and collect the PM sign-off on one fixed rhythm, just before your regular delivery review. Leaders then read a view that is current on facts and fresh on judgement, and PMs know exactly when they are asked to look.
If a project's data has not changed since the last review, flag it as possibly stale rather than treating it as green. Silence in the tools is not the same as progress.
How do you show leaders only what needs attention?
You show only what needs attention by sorting and filtering the view so changed and at-risk projects sit at the top, and stable green projects collapse into a single line. Set up the review view in this order:
- Projects that changed health since the last review.
- Red projects, then amber.
- Projects where the PM asked leadership for help.
- Projects with sponsor decisions or blockers past their agreed date.
- Everything else, collapsed.
Run the delivery review from that view. Spend the meeting on the top of the list and on the help requests, and skip any project that is green and unchanged.
How do you know the roll-up is accurate enough to act on?
The roll-up is accurate enough to act on when spot checks against the source tools match, health agrees with the rules or carries a stated override, and stale rows are rare and flagged. Check it deliberately for the first few review cycles before you retire the old reports.
- Spot check. Before each review, open a few rows at random and click through. Does the next milestone date match the plan? Are the listed blockers still open?
- Compare health to evidence. A green project with an old client blocker is a mismatch. Ask the PM which is wrong.
- Watch overrides. If PMs override the rule often on one kind of engagement, the rule probably needs adjusting for that contract type.
- Ask the people closest to the client. If an account lead is surprised by a problem the view should have shown, find out which field missed it.
- Measure PM time yourself. Ask PMs how long reporting takes before the change and again after. Vendor figures vary: the monday.com services reporting guide cites workflows that "save your team three hours every week", but that is the vendor's claim, not a measure of your firm.
Where does this approach fall short?
A tool-built roll-up only reflects what is logged in the tools. Relationship signals, such as a client sponsor going quiet or a change of stakeholder, rarely show up as a task. That is why the PM's reason line and the help request stay in the sign-off. Projects on very different contract types may also need a field or two of their own; add them to those projects without making every PM fill them in.
The PMI article reports one practitioner's account of an organisation that once had someone visit every active project to build a slide deck, and later used reports integrated at the portfolio level; that practitioner is quoted as saying "no additional reporting time is required." Getting there depends less on the dashboard than on shared fields, clear rules, and a PM sign-off that stays short.