Jira Report for Leadership: Client Projects at Risk

Jira has no native executive report, so you build a leadership view of at-risk client projects from native parts. Tag every issue with its client, write one rule for what "at risk" means, and save filters that apply that rule the same way to every engagement. Put those filters on one dashboard, then write a short weekly summary from it that names each at-risk client, the cause, and the decision or help needed.

Can Jira show leadership which client projects are at risk?

Leadership gets a usable view when you combine saved filters, a shared dashboard and version reports, then apply a written at-risk rule to what they show.

The native parts you can use are easy to list. Atlassian's reports page describes advanced search that turns work across projects into reports you can save, share, or add to dashboards. The same page covers dashboards built from gadgets, and a release burndown that tracks the projected release date for a version. Grandia adds the Version Report and CSV export to that list. What none of these do is decide what counts as at risk. You have to supply that rule.

What should "at risk" mean across every client?

"At risk" should mean a client project fails one written rule that every project lead applies the same way: a forecast date slipping past the committed date, critical work blocked too long, or a sponsor decision left outstanding. Tempo's advice is to agree the definition before the report goes live.

Keep two questions apart. "Already late" means work is past its due date. "Likely to be late" means the forecast date has moved past the date you promised. Leadership needs to see both.

Rule template to agree with your project leads:

RED if any of these is true:
- Forecast delivery date for a committed milestone is more than [X] working days past the committed date
- An issue on the critical path has been blocked for more than [Y] working days
- A sponsor decision or review has been outstanding for more than [Z] working days and a milestone depends on it

AMBER if any of these is true:
- Forecast date is up to [X] working days past the committed date
- Open overdue issues exceed [N] for this client
- New scope added since baseline exceeds [P] issues or [P] estimate units without a change agreed with the sponsor

GREEN otherwise.

Committed date = the date agreed with the sponsor, recorded on [the version / milestone epic] on [baseline date].
Forecast date = taken from the source agreed for that milestone (see below).

The red and amber tests only work if every lead takes the forecast date from the same kind of place. Agree it per milestone:

1. Where the milestone is a Jira version, use the release burndown, which Atlassian says lets you track and monitor the projected release date for versions.
2. Where there is no version, the lead records a forecast date on the milestone epic, next to the committed date, and updates it before each leadership review.
3. Where neither exists yet, show the milestone as "data incomplete" rather than guessing a colour.

Fill in the blanks together in one meeting, write the result into your delivery handbook, and don't change it in the middle of a reporting period.

How do you tag every Jira project by client?

Tag every open Jira issue with exactly one client value, using a project category, a Client custom field, or an agreed list of each client's projects, so saved filters can group work by client. Without a client value, a portfolio view shows projects, and leadership still has to work out which client each belongs to.

Pick one method, and write the matching client clause once. Every filter in the next section uses that same clause.

1. One or more projects per client, grouped by category: put each client's projects into a project category named after the client. Client clause: category = "[Client]"
2. Several clients in one project: add a single-select custom field called Client and make it mandatory, if your site's field settings allow it. Client clause: "Client" = "[Client]"
3. A short list of projects per client, no categories: keep an agreed list of each client's project keys in your delivery handbook. Client clause: project in ([Client project keys])

Run the clause on its own in advanced search and check that it returns every open issue for that client. Then ask each project lead to confirm that every open issue has a client value before the first leadership review.

Which JQL filters find overdue, blocked and slipping client work?

A small set of saved JQL filters covers the signals in an at-risk rule: overdue work, work due soon that hasn't started, blocked work, work waiting on a sponsor, open work in unreleased versions, and scope added since baseline. Change the field and status names to match your site, test each filter in advanced search, then save it.

These are example queries, not tested recipes. Check every field name, status name and function against your own site in advanced search before you save a filter, and replace [client clause] with the one clause you chose above.

# 1. Overdue work
[client clause] AND duedate < now() AND statusCategory != Done ORDER BY duedate ASC

# 2. Due soon and not started
[client clause] AND duedate >= now() AND duedate <= "[n]d" AND statusCategory = "To Do"

# 3. Blocked work (use the flag or the status your site uses for blocked work)
[client clause] AND (Flagged is not EMPTY OR status = "[Blocked]") AND statusCategory != Done

# 3b. Blocked for longer than the rule allows (check this status-history clause on your site)
[client clause] AND status = "[Blocked]" AND status changed to "[Blocked]" before -[n]d

# 4. Waiting on the sponsor
[client clause] AND status = "[Waiting for sponsor]" ORDER BY updated ASC

# 5. Open work in versions not yet released
[client clause] AND fixVersion in unreleasedVersions() AND statusCategory != Done

# 6. Scope added since baseline
[client clause] AND created >= "[baseline date]" AND issuetype in ([Story, Task])

If a query returns nothing when you know matching work exists, the field or status name is the usual suspect. Fix the name rather than the logic, so every client's filter stays the same.

Filter 5 tells you how much is still open. To see whether a version will make its date, open the release burndown, which Atlassian says lets you track the projected release date for versions and act if work is falling behind. StonikByte names the same signals for its risk question: blocked and aging issues, alongside RAG indicators.

How do you build the leadership dashboard?

Build the leadership dashboard as one shared Jira dashboard holding the saved client filters, with counts grouped by client and the longest blocks listed first, so a partner can see which clients need attention without opening a ticket. Share the dashboard and its filters with the same leadership group.

1. Create a dashboard named [Practice] client delivery: leadership.
2. Add a gadget that shows filter results grouped by a field, choosing whichever your site offers. Point it at a copy of filter 1 with the client clause widened to cover every client, grouped by client.
3. Repeat for filters 3 and 4, so blocked work and sponsor waits are counted per client.
4. Add a list gadget for filter 3, sorted oldest first, so the longest blocks are at the top.
5. Share the dashboard with the leadership group, and share its filters with the same group.
6. Add a text note at the top that links to the written RAG rule.

The dashboard shows counts and causes, not the colour. A person still applies the rule.

What data has to be in place before leadership trusts the report?

A leadership report on at-risk clients needs complete data first: a client value on every open issue, a committed date on every milestone, and one shared status for blocked work, waiting on the sponsor, and done. Check these fields for every client before the first review, then spot-check them before each later review.

• Every open issue has a client value.
• Every committed milestone has a due date or a fix version with a release date.
• Every milestone has a forecast date from its agreed source: the release burndown or the lead's written forecast on the epic.
• The committed date is recorded once and not edited quietly afterwards.
• Blocked work uses the same status or flag in every project.
• "Waiting for sponsor" is a real status, not a comment.
• Estimates exist for the work in the next milestone, if you forecast from them.
• Done means done: resolved issues sit in a Done-category status.

If a project fails the check, show it as "data incomplete" instead of green.

Where do native Jira reports fall short?

Native Jira reports show the symptoms, such as late, blocked or added work. Those reports don't show the reason or what leadership needs to do. Grandia says the questions executives ask are on track, at risk, and what needs a decision, and that last one rarely lives in Jira.

Expect these gaps:

• A sponsor-side blocker such as a missing sign-off or a late review shows up only as a status, with no context.
• Predicted completion dates beyond the release burndown's projected release date come from apps, such as the forecast reports eazyBI describes in its own app.
• The colour depends on a human applying the rule, so it needs an owner.

This guide sticks to dashboards, saved filters and version reports. If your team uses Advanced Roadmaps (Plans) or Atlassian Analytics, apply the same at-risk rule and data checklist there.

The counterpoint is fair: a reporting app or BI tool can do more of this automatically. StonikByte notes that BI tools like Power BI often require data pipelines, maintenance, and additional expertise. Get the rule and the data right in native Jira first. Any tool you add later depends on both.

How do you turn the dashboard into an exec summary each week?

Write the weekly exec summary straight from the leadership dashboard: each project lead adds one line per red or amber client naming the cause, the decision or help needed from leadership, and the owner, and the head of delivery approves the colours. Green clients share a single line, so nobody exports data or builds slides.

Template:

Client delivery summary, week of [date]

RED
- [Client]: [milestone] forecast [date] vs committed [date]. Cause: [blocked issue / sponsor decision / scope added]. Needed from leadership: [decision or help], by [date]. Owner: [name].

AMBER
- [Client]: [one-line cause]. Next step: [action] by [date].

GREEN
- [Client], [Client], [Client]

Data incomplete
- [Client]: [missing field]. Fixed by [date].

Put every line in the same order: cause, then the decision or help needed, then the owner. If a sponsor decision is the cause, the lead sends a clear request to the sponsor before the review, not after it. Unblockd includes asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.

How should the leadership review run?

The leadership review is a short meeting that covers only the red and amber clients and ends with a named owner for every next step. Tempo notes that most organisations review late lists weekly at a program level and monthly at a portfolio level, with explicit ownership.

1. Open the dashboard and the summary side by side.
2. Go through red clients first: cause, decision needed, owner.
3. Go through amber: confirm the next step and its date.
4. Note any data-incomplete projects and who fixes them.
5. Send the decisions to the project leads straight after the meeting.

Start by booking the meeting where you agree the RAG thresholds. Everything else in this guide follows from that rule.