The Dashboard That Disagrees With Itself

Two things are happening, and only one of them is the PMO's fault.

• Status equates. Workfront project statuses are grouped into equates (typically Planning, Current, Complete, Dead), and a filter on 'Current' matches the equate, not the label. Projects sitting in Planning equate are correctly excluded from a Current filter. If the PMO intends 'all in-flight work,' Current is the wrong filter.
• The custom status. 'On Hold - Client' was created with whatever equate its author chose. If that equate is Planning (a reasonable choice at the time), it is invisible to a Current filter. If it were equated to Current, it would appear - and would also inflate every other Current-based report in the system.

What the PMO misunderstood: a status label is a word, an equate is behaviour. Every custom status silently joins an existing bucket and changes the population of every existing filter.

Practical guidance: agree a definition of 'active' first - for most PMOs it is not complete and not dead - then implement it as an equate-based filter rather than a list of labels. A label-list filter breaks the next time someone invents a status.

Reports do not grant access, they reflect it. Unless a report is configured to run with a specific user's access rights, each viewer sees only the rows their own permissions allow - projects they are on the team for, or that their access level plus sharing permits. Executives see 55 because they can see the portfolio; those two PMs see 30 because 25 of those projects are invisible to them.

Options, with honest trade-offs:

1. Run the report with elevated access rights. The report then shows identical rows to everyone it is shared with. This is the right answer for a portfolio-count metric, and the wrong answer for anything containing details the viewers should not see. Keep elevated reports to aggregate counts and status, not to staffing or financial detail.
2. Fix sharing, not the report. Add the PMs to the relevant projects or teams if they legitimately need visibility. Slower, but it fixes the underlying cause rather than masking it.
3. Change the audience. If a PM should not see the other 25 projects, then 30 is the correct number for that person and the dashboard is working. Say so explicitly, because otherwise someone will 'fix' it by over-sharing.

The defensible position is to state, per report, whether it is intended to be a portfolio truth (elevated, filtered to aggregates) or a viewer-scoped view (permissioned, never quoted as a total).

Blank bars in a grouped report almost always mean the grouping key is empty, not that the data is missing.

Likely cause: the report is grouped by Project Owner. The departed manager's account was deactivated and, depending on how the account was handled, the projects may now have no owner, so they collapse into the 'No value' group - which often renders as an unlabelled or empty band that readers mistake for zero hours.

Diagnose before fixing: filter the underlying report to those six projects and check planned hours, actual hours, and owner directly. If hours exist and the owner is blank, it is a grouping artifact; if planned hours are empty, the issue is upstream in the projects themselves.

Durable fixes:

• Reassign ownership of the orphaned projects to a current owner with portfolio responsibility. Never leave projects ownerless; ownership drives reporting, approvals, and accountability.
• Handle departures as a checklist item, including reassignment of owned projects, tasks, issues, and proofs.
• Add an exception report - projects with no owner, no planned hours, or no planned completion date - to the PMO's own view so these surface before a steering meeting rather than during one.
• Never group executives' headline metrics on a field that can be empty without an explicit 'Unassigned' bucket, so the gap is labelled rather than invisible.