Read and interpret a project report¶
A project report brings together current delivery counts, work-state summaries and time-based charts. Use it to decide where to investigate: work awaiting review, blocked items, unmet milestone criteria or outputs awaiting acceptance. The underlying work and approval records remain the place to confirm what happened and what action is needed.
Availability: The backend provides report and history reads. The inspected Final Screens define an intended Report tab with period, grouping and refresh controls. The current frontend includes a Report tab with sample data. It does not yet retrieve a live project report: period/grouping controls and Refresh report do not load new project results in that preview. Opening another project can change the displayed name while retaining the same sample report. These instructions describe the intended design and the meaning of connected report data; they do not establish that a connected report is available in your environment. Some screen labels and sample values need reconciliation, as explained below.
Open and refresh the intended report¶
- Open the relevant project and confirm its reference and title. A report concerns one selected project, rather than the entire portfolio.
- Select Report in the project tabs, alongside Overview, Execution, Milestones, Deliverables and Repositories.
- Use the period control to choose the offered reporting window. The inspected design shows Last 90 days. The backend supports 30, 90 and 180 days.
- Choose the offered time grouping. The design shows Weekly buckets; a bucket means one interval on the chart. Daily and weekly history are supported, but connecting the grouping control to the correct history read remains frontend work.
- Select Refresh report, then check the selected project, period and grouping before interpreting the result.
You need permission to view projects. Refreshing a connected report reads the current source records; it does not complete work, approve a milestone, start a workflow or create a user-managed report version. No export, scheduled email or saved-report selection action was verified in this screen family.
The selected period applies to time-based series. The headline counts and breakdowns describe current records, not only work created or changed during that period. A shorter window can therefore change the chart while leaving those totals unchanged.
Understand the current counts¶
| Measure | Current meaning | Interpretation limit |
|---|---|---|
| Total work | All execution items in the project | Includes states other than active and completed; it is not a count of events within the selected period |
| Active work | Items currently in progress | Does not include every unfinished item; blocked and review-ready work have separate counts |
| Completed work | Items currently completed | Reopening work can reduce this count |
| Review-ready / review queue | Items currently ready for review | These count the same state and should agree for the same report observation |
| Blocked work | Items currently marked blocked | Does not count every unresolved dependency or every cause of delay |
| Evidence-backed review-ready work | Review-ready items with an attributed repository-evidence record | Presence of evidence does not prove its quality, successful build/deployment, acceptance or completion readiness |
| Backlog items / work packages | Separate total, in-progress and completed counts for each work type | Count records, rather than hours, effort or value delivered |
| Active sprints | Groups recorded as active sprints | Closing a sprint does not complete its items |
| Milestones | Total and current approved, pending or criteria-met counts | Criteria met and approved are different; rejected gates remain in the total without a separate rejected counter |
| Deliverables | Total outputs and outputs currently accepted | An accepted output is distinct from a completed work item or closed project |
| Repositories / governance workflows | Linked repositories and saved governance workflow-link records | These are not counts of healthy integrations, successful synchronizations or approvals |
The report also distinguishes the project's primary delivery approach: Agile uses backlog items for its primary-work counters; Plan-driven uses work packages. The screen's sample “Hybrid delivery” label does not establish a third supported primary approach. Counters for both work types can appear in the report without changing that primary approach.
The current state-mix calculation labels the remainder after in-progress, review-ready, blocked and completed work as “Planned.” That remainder can include other states, such as reopened or cancelled work. Do not interpret it as an exact count of items explicitly marked planned until this distinction is resolved in the report presentation.
Separate events, current state and running totals¶
The report contains three kinds of series. They answer different questions:
| Kind of series | Question it helps answer | How to read it |
|---|---|---|
| Events | How many retained completion, achievement or acceptance timestamps fall in each interval? | A value belongs to the interval containing the stored timestamp |
| Current state | How much work is blocked, awaiting review or in another state now? | Only the latest interval contains the current value; earlier zeroes are placeholders, not measured historical counts |
| Running total | How does the reconstructed completed count accumulate across the window? | The series starts from an inferred baseline and adds retained completion timestamps |
For example, if three items are blocked today, the blocked-work series places three in the latest bucket. Earlier zeroes do not prove that no items were blocked last week. Use this series for the current backlog of blocked work, not a trend in historical blocking or an improvement claim.
Agile burnup and Plan-driven completed-scope charts are running totals of completed item counts. They do not measure story points, effort, budget or business value. The Plan-driven “planned scope” series is the current total execution scope placed in the latest interval. It is not a saved baseline schedule or the planned amount for every earlier week.
Understand what history can change¶
The history read reconstructs series from the current work, milestone, deliverable and workflow records. It does not replay a complete event ledger or return the separate report snapshots stored by some operations.
Completion charts use the completion timestamp currently retained on each work item. Reopening an item clears its current completion timing; a later completion supplies a new timestamp. Milestone reevaluation and deliverable outcome changes can similarly change retained achievement or acceptance facts. Attribution added or removed later can change which completed items are classified as evidence-backed.
Consequently, a chart for an earlier period can change when you refresh it later. It must not be presented as an immutable record of what an earlier report showed. For a formal review, record the project, selected period, grouping and observation time through your organization's approved process, and retain the relevant work and approval evidence.
The evidence-backed completion series means a completed-timestamp record has an execution-item evidence attribution. It does not prove that the evidence was already present when the item completed or that the proof was independently accepted.
Read dates and turnaround carefully¶
Daily buckets use UTC calendar dates. Weekly buckets begin on Monday in UTC. The first and last intervals can be partial because the requested period starts a fixed number of days before the current instant and ends during the current day or week. A 30-day daily window spans 31 calendar buckets, including both boundary dates. A 90-day report is not guaranteed to contain exactly 12 weekly buckets.
The latest interval is still open. Its displayed interval end is the end of that day or week, so it can extend beyond the current time. Compare charts using the same window and grouping, and avoid comparing a partial week with a full week as though they were equivalent.
Workflow turnaround is an average elapsed time, rounded to whole hours, from a governance request to the latest outcome timestamp retained on each link. It is grouped by the outcome's interval. It is not a count of workflows, working-hours duration, approval-only measure or guaranteed time to final approval. An outcome update can change it. A zero can mean no recorded outcome in that bucket or a duration that rounded to zero; the report does not supply a sample count alongside that average.
Use breakdowns to ask better questions¶
- Execution groups: Compare current work counts within each sprint or phase. Their status is the group's saved status; it is not an automatic delivery-health judgment.
- Teams: Work is grouped using the assigned person's current department profile. This is not historical team membership, an independently managed delivery team or a capacity model.
- Assignees: Counts describe work assigned to each person. A missing profile can produce an “Unassigned” display fallback even when an assignment identifier exists. Ask for verification before treating that label as evidence that nobody owns the item.
- Milestones: The completion fraction counts satisfied criteria against the configured criterion units. It mixes work thresholds, whole groups, accepted outputs and required approval. Its approval component can count a saved approved workflow associated with the milestone without proving approval of the current criteria or the intended review purpose. It is not a weighted measure of effort or business progress, or proof that the milestone is approved.
- Delivery approach: This breakdown describes the selected project's primary work type. It is not a portfolio comparison of several delivery approaches.
For group, team, assignee and delivery-approach rows, completion means completed items divided by total items. Each item has equal weight. A small task and a large work package are not weighted differently. Empty scope produces zero rather than proof of failure or success.
Team and assignee rows do not return the due dates, escalation labels or health judgments shown in some design examples. Milestone breakdowns return a target date and saved status, but their blocked-item count is not calculated there. Consult the actual work and milestone criteria before acting on a watchlist claim. The intended screen still needs to reconcile these examples and its conflicting active/review sample totals.
Freshness, empty results and recovery¶
Refresh after relevant project changes, then inspect the item, deliverable or milestone behind an unexpected value. Report and history are separate reads and can observe changes at different times. The report does not include a dedicated “generated at” field or a promise that every displayed panel was captured atomically.
An empty history result can mean the project was not found by that read; it does not always mean that an existing project had no activity. A valid report can also contain zero-filled series when no retained timestamps fall in the period. If the report cannot be found, check the selected project and workspace. If access is restricted, ask the workspace administrator to confirm project-view permission.
If numbers disagree, record the project reference, selected window and grouping, observation time, affected measure and exact message. Compare the same work type and state, and distinguish current totals from period events. Do not repeat a work mutation merely to try to refresh a chart. Support should investigate missing data, inconsistent read timing, profile projections and changed historical timestamps separately.
Managers can use these views to prioritize investigation and review. Executives should combine them with verified outputs, approvals and business outcomes before making delivery or performance claims. These counts do not establish individual productivity, utilization, cost savings, profitability or a contractual service level. No report-specific charge or quota is established by these read operations.
Continue with execution and review, milestones and formal governance, repository evidence, or dependencies and shared delivery to investigate the source of a report value.