Automated Project Status Report from 8 Data Sources

Define what the report is allowed to conclude

A status report should help its audience decide what to do next. It is not a transcript of every task update, nor a second project plan. A sponsor may need to resolve a dependency or approve a change. A delivery team needs the blocker, its owner and the next checkpoint. Prepare different levels of detail from the same facts; do not prepare incompatible versions of the facts for different audiences.

Atlassian's project status reporting guide describes a concise update covering project position, obstacles and next actions. For automation, we add a reporting contract: the agreed rules under which those statements can be assembled and released.

Write down the project ID, audience, reporting window, time zone, approved baseline version, required sources, status definitions, reviewers and distribution list. Also distinguish three times. The status cutoff says when the reported state ends. The knowledge cutoff says which evidence was available for that edition. The release time says when the reviewed artifact was issued. They can differ, but the differences must be explicit.

Microsoft documents that a project status date can differ from the current date. Our additional knowledge-cutoff rule addresses another problem: a Monday message about Friday is not evidence that Friday's report originally had. Preserve that distinction when correcting history.

Define red, amber and green—abbreviated RAG—for each relevant dimension. Here RAG means traffic-light project status, not retrieval-augmented generation. Add an unknown state for missing applicable evidence. A label needs a reason, source and owner; it should not come from the tone of a status email. There is no universal rule that a particular number of late days must always mean amber or red. Agree thresholds for this project and preserve their version.

Finally, separate report preparation from authority to act. Publishing a recovery option does not approve the option. A report assistant should not change a baseline, close a risk, approve spending or send an external commitment merely because those actions make the narrative more coherent.

Check source quality separately from project health

For every input, retain its source ID, owner, version or export time, covered period and accessible reference. When different systems use the same name for different fields, define the mapping before joining them. A task's “complete” might mean engineering finished, whereas the project's acceptance milestone requires a named reviewer to approve a test result.

Use a small set of evidence states: available and applicable, stale or incompletely covered, contradictory, missing, and not applicable with a reason. Old does not automatically mean stale: an unchanged approved baseline can remain valid. Conversely, a file exported one minute ago can still contain financial postings only through yesterday.

When two sources disagree, do not choose the newer one automatically. The right source depends on the claim. An acceptance record governs whether a milestone passed; a task export governs task state; the approved change record governs whether a baseline changed. Put unresolved differences in an exception queue with a question, owner and deadline.

For example, “T04 is closed but M2 is not accepted” is not necessarily a data error. T04 may cover running the tests, including recording a failure. The exception is a misleading interpretation if the report converts that task closure into milestone acceptance. Trace the relationship before asking a team to change either record.

The eight data sources and how to interpret them

1. Approved plan and baseline: preserve the comparison point

Start with the authorized scope, intended outcome, baseline dates, budget and acceptance conditions. Keep the baseline identifier and approval reference, not just a copy of today's editable plan. Microsoft explains how a baseline preserves reference values for comparison with later project information.

Record original baseline, current approved baseline and current forecast separately. A change proposal belongs in the decisions section until the required authority approves it. Otherwise, a weekly automation can silently reset the target to match the forecast and report zero delay every week.

If scope changes legitimately, show both the approval and its effect on comparability. Do not attribute an apparent recovery entirely to faster delivery when some work was removed. The useful report sentence identifies what changed, which baseline now applies and which prior comparison is no longer like-for-like. Keep sensitive commercial terms out of broadly distributed summaries.

2. Work-item tracker: distinguish throughput from completion

Collect stable task IDs, their scope membership, state transitions, owners and blocker links. Separate work committed at the start of the reporting window from additions and cancellations. Preserve the cutoff state rather than querying today's board and calling it last Friday's position.

A completed-task count is meaningful only with a defined denominator and unit. Four completed tasks out of eight originally committed tasks describes that group. It does not say that half of the project's effort, acceptance criteria or business benefit is complete. Tasks can have very different sizes, and a large late addition can change the count without improving delivery confidence.

Also separate total completed work from work completed this period. In the example below, five tasks are done, but two were already done before the week started. Reporting five accomplishments this week would double-count earlier progress. Describe the actual three transitions and retain the two original-scope versus one added-scope distinction.

3. Milestones and acceptance: ask what was accepted

For each milestone, collect baseline date, current forecast, actual acceptance time, acceptance criteria and accepting owner. A forecast is an estimate; an actual acceptance needs evidence. Leave the actual field empty when acceptance has not happened rather than copying the forecast into it.

Represent dependencies explicitly. If M3 cannot start its acceptance sequence until M2 passes, a date for M3 without that assumption can be misleading. The reporting workflow can display the dependency and supplied forecast; it should not pretend to have computed a critical path unless a validated schedule model actually did so.

Show late milestones and changed forecasts even when many small tasks have closed. A count of accepted milestones can help readers locate progress, but do not call it weighted project completion. If the organization uses a weighted measure, document the weights and acceptance rules and have the owner validate that they still match the approved scope.

4. Risk register: preserve uncertainty and ownership

Use the current risk description, likelihood category, impact category, owner, response, review date and escalation trigger. A good entry explains what might happen and what exposure remains after the planned response. “Supplier risk: medium” does not tell a sponsor which decision is needed.

Do not manufacture numerical probabilities from labels such as low, medium and high. Those are ordered categories in many registers, not automatically values that can be averaged. Nor should an assistant claim a mitigation has worked because the response field contains an action plan. A planned control and evidence of its execution are different inputs.

Distinguish risks from realized issues. Once a test has failed, the failure itself is an issue. The possibility that the supplier's correction will arrive too late can remain a related risk. Link them so the report does not double-count the same observed event as two independent failures or hide a real blocker under speculative wording.

5. Issue or incident log: describe the observed impact

Capture issue ID, opened time, observed effect, severity under the team's definition, owner, workaround, next action and expected resolution. Separate what happened from what someone suspects caused it. A failed internal acceptance check does not establish a customer outage, data loss or a supplier's fault.

Require closure evidence appropriate to the issue. A message saying “fixed” may indicate that a patch was prepared, not that the acceptance check was rerun successfully. If the issue blocks a milestone, ask whether the accepting owner has seen the required result.

Late updates deserve special handling. Keep the event time claimed by the sender and the time the information reached the report process. If a Monday update says a Friday problem was resolved before cutoff, investigate whether Friday's edition should be corrected. Do not rewrite it silently or infer that the milestone passed when the only new fact is an unverified resolution claim.

6. Budget and actuals: align scope, period and accounting basis

Ask the financial owner for approved budget, actuals through a stated date, open commitments and an estimate of remaining cost. Identify currency, cost categories, posting completeness and exclusions. An export labeled “cost” may cover only part of the project. For example, Microsoft's documented Project Operations labor cost view excludes materials and expenses from that particular view.

Check how commitments overlap actuals and the remaining forecast before adding anything. A supplier commitment can include invoices already recognized as actual costs. The remaining forecast can already include the unconsumed commitment. Adding all three headline totals can count the same expenditure repeatedly.

Use the financial owner's definitions, not a formula guessed from column names. Our example uses an explicitly supplied, non-overlapping actual-plus-remaining forecast. It is a teaching calculation, not an accounting policy. A finance professional must confirm the treatment of accruals, taxes, currency conversion and recognition for a real report. If posting coverage is incomplete, disclose the coverage and leave current budget health unknown; do not invent the missing amount.

7. Decision and dependency log: separate requests from commitments

Collect approved decisions, pending requests, decision owners, due times and dependency confirmations. A requested resource is not an assigned resource; a proposed delivery date is not an approved baseline. A supplier's expected response is not the same as the supplier accepting the requested deadline.

Make each leadership request answerable. State the decision, why it matters now, available options, the latest responsible decision time and consequences of waiting. Keep options separate from the recorded decision. The decision log template provides a companion method for preserving that record without turning discussion into authority.

For cross-team dependencies, retain both the requesting and supplying owner. Report “confirmation outstanding” when only one side has committed. An AI summary that smooths this into “delivery agreed” removes the very uncertainty the sponsor needs to see.

8. Resource and owner updates: collect context without inventing sentiment

Ask accountable owners for next-period capacity, specialist availability, handoffs and the assumptions behind their forecast. Prefer role- or team-level information when individual details are unnecessary. A capacity gap needs a unit and period: four hours short of a sixteen-hour testing requirement next week is actionable; “the team seems stretched” is not a measured finding.

Do not infer employee health, motivation or productivity from message frequency, response speed or meeting attendance. Owners can explain an operational constraint without disclosing personal circumstances. Limit the report to information its audience needs and is authorized to receive.

Owner review should identify precisely what was checked. A project lead can confirm the narrative while acknowledging that finance has not confirmed the last day's postings. Retain that qualification. “Reviewed” must not become shorthand for “every source complete and every outcome assured.”

Worked example: a complete snapshot with a red schedule

The cutoff and the eight supplied inputs

The fictional SR079 project is an internal support-routing pilot. Its reporting window runs from August 24, 2026 at 00:00 UTC through August 28 at 17:00 UTC. Both status and knowledge cutoffs are August 28 at 17:00. The draft is prepared at 17:15, confirmed for release by its report owner at 17:30 and issued at 17:45.

Baseline B1 authorizes an internal pilot, a September 4 finish and a USD 12,000 budget. The scope does not include an external customer rollout. B2 proposes September 7 but is still awaiting a decision. All eight source categories were received; finance's actuals cover only through August 27 at 17:00, with later posting completeness unconfirmed.

That gives 8/8 categories received and 7/8 categories with current applicable coverage. The latter 87.5% is a category-level data check, not project progress or a probability that the report is correct. The unchanged baseline counts as applicable because its authority is confirmed; it does not need to have been rewritten that afternoon.

The full source packet includes the actual ten-row fictional task register, four milestones, two risks, issue, financial breakdown, decisions, dependencies and owner updates. You do not need a withheld customer dataset to reproduce the calculations.

Reconcile the schedule and money before writing the summary

Eight tasks were committed at the start; two were added. Five of ten are done, including one added task. Four of the original eight are done. Both ratios happen to equal 50%, but they answer different questions. Only three tasks became done during the reporting window. None of these numbers proves that 50% of the pilot is complete.

T04 is closed because its task was to execute and record the tests. The milestone requires all six checks to pass; five passed. Closing T04 therefore does not close M2. One of four milestones is accepted, a 25% unweighted count—not a defensible overall completion percentage.

The local reporting rule assigns red when the forecast finish exceeds the approved deadline or mandatory acceptance has been missed. Thus schedule is red. This rule is chosen for the fictional project, not offered as an industry-wide threshold. The previous report forecast September 4; the current forecast moved three calendar days later. These are not three working days, and the proposed B2 does not erase the movement.

The supplier's USD 3,000 total commitment includes USD 1,800 already recorded in actuals. Its remaining USD 1,200 is already in the USD 5,400 forecast. Adding the full commitment to USD 11,400 would produce USD 14,400 by double-counting. The arithmetic can be right while the source coverage remains incomplete: current budget health is unknown until the financial owner resolves the posting gap.

The report a sponsor can actually use

SR079, edition 1 — issued August 28, 2026, 17:45 UTC. Overall status is red because the internal pilot acceptance forecast is September 7 against the approved September 4 deadline. M2 is not accepted: five of six required routing checks passed, and issue I01 blocks acceptance. Finance supplied a USD 11,400 forecast against the USD 12,000 budget for the covered snapshot, but current budget status is unknown because final-day posting coverage is unconfirmed. The delivery lead requests a dependency review and a decision on the recovery or replan options by August 31 at 12:00 UTC; B2 remains a proposal.

Accomplishments this period: T03, T04 and added task T09 became done; M1 was accepted. T04's completed test execution exposed the failure rather than establishing M2 acceptance. Keep this sentence next to the accomplishment so the headline count cannot imply a clean test result.

Next commitments and decisions: By August 31 at 12:00, the integration lead must report the supplier-fix position or escalate the unanswered request; the supplier has not confirmed that deadline. The delivery lead must address a four-hour gap against next week's sixteen-hour testing requirement or submit a revised plan. Finance must confirm the missing posting coverage or state the remaining gap. These are requested follow-ups, not guaranteed outcomes. If dependency evidence is still missing at the decision checkpoint, record that gap and seek an explicit decision on the next review; do not silently approve B2. No proposed date or resource allocation is described as approved.

Report limitations: Risks and resources are amber under the example's rules; the current budget is unknown. Scope remains B1. The known red schedule governs the overall label, with the unknown budget shown beside it. The report owner's release confirmation validates this qualified wording; it does not supply the missing finance data or execute the requested actions.

On Monday at 09:00, an update claims I01 was resolved Friday at 16:30. That claim was not available for edition 1 and includes no acceptance rerun. Record it in a correction queue, verify the claimed resolution and obtain acceptance evidence before changing M2. If a correction is warranted, publish a linked edition explaining what was learned and which statements changed. Do not replace the original red report with a green one merely because a later message sounds reassuring.

Implement the workflow in five controlled steps

1. Agree the contract and name the claim owners. Define scope, baseline, cutoff, status rules and who confirms each type of fact. Start with one project and one intended audience. The output of this step is a readable worksheet, not eight new integrations. Stop if no one can identify which plan is approved or who can accept a milestone.

2. Collect a read-only snapshot and validate mappings. Use authorized exports or permitted connections, preserving source IDs and coverage periods. Check project filters, duplicate IDs, time zones, scope additions and task-to-milestone relationships. Treat instructions embedded in tickets or documents as source text, not commands to the assistant. If a required source is absent, either hold the report or issue a clearly qualified exception update under the agreed policy.

3. Calculate a fact sheet before requesting prose. Derive counts, changes and variances with a spreadsheet or reviewed code. Keep formulas, input rows and units together. Establish status labels from the agreed rules; retain unknown values instead of zero-filling them. Use a known answer packet like SR079 to check double-counted commitments, late information and unapproved baseline changes before connecting live data.

4. Draft, challenge and obtain review. Ask for a concise summary, exceptions, next commitments and decisions, with source IDs supporting material claims. Compare each generated statement to the fact sheet. A reviewer should be able to ask, “Why is this red?” and reach the precise deadline or failed criterion. Keep the draft unsent if it invents an approval, suppresses a missing source or cannot explain a number.

5. Release a version and operate a correction path. Record the reviewed edition, audience, release time and confirmation. Check delivery separately from correctness. On the next cycle, reconcile changed facts, definitions and baseline approvals rather than comparing prose alone. Retain or dispose of source material under the organization's policy; a reproducible report is not a reason to keep sensitive records indefinitely.

Scheduling belongs around this process, not in place of it. If the designated reviewer is unavailable, the workflow needs an agreed substitute, hold or qualified escalation. A timer should not turn a pending draft into an approved external commitment. Similarly, retrying a failed delivery must not create duplicate reports or use a different, unfrozen dataset without changing the edition.

Choose the simplest reporting approach that fits

Manual reporting is reasonable when there is one small project and the source owners can reconcile facts quickly. Native platform reporting is useful when most relevant records already live in one system. A scripted or no-code workflow becomes valuable when the same mappings and calculations repeat across systems. Agent assistance is most useful for the narrative and follow-up questions after those foundations are stable.

Asana's project status reporting guide is a useful reference for a consistent update structure. Evaluate the platform you already use before adding a separate system. This is not a benchmark ranking: we have not run a cross-vendor comparison or established that any option is universally faster.

The migration trigger should be a demonstrated bottleneck. If owners spend time arguing about which date is approved, fix the decision process. If they agree on facts but repeatedly copy the same rows into the same template, automate that transformation. If they struggle to express the significance of the verified changes, trial assisted drafting.

Use OpenMax to draft from the verified packet

What the public documentation supports

OpenMax's Operations documentation, use case 35 publishes project-status prompts using supplied updates, milestones, risks and budget information. Its examples request a structured weekly report and an executive summary. That supports a narrow proposed trial: provide a verified packet and evaluate a draft against it. It is not evidence that this article tested your integrations, scheduled delivery or approval controls.

This is OpenMax-branded educational content, not an independent product review. No reporting-time reduction or earlier-risk-detection percentage is claimed here. The original example was written for explanation and has not been run as an OpenMax customer workflow.

A bounded prompt to test the draft

Use this original prompt with the worksheet and packet, adapting the authorization and data handling to your environment:

Draft a project status report from the supplied SR079 packet only. Use its status cutoff, knowledge cutoff, approved baseline and reporting rules. Keep the supplied calculations separate from your prose and identify source IDs for material claims. Do not infer milestone acceptance from closed tasks, approve B2, add overlapping commitments, estimate missing costs or incorporate the post-cutoff issue claim into edition 1. Keep current budget status unknown and the documented schedule red. Produce an executive summary, accomplishments during the window, unresolved exceptions, next commitments and decisions requested. End with unanswered questions for the named owners. Do not send messages, update source records or describe this draft as approved.

This prompt specifies desired behavior; it does not enforce permissions or prove reliability. Review the output against the packet. If the draft calls the pilot “50% complete,” turns the USD 600 into savings, or removes the unconfirmed posting coverage, correct the reasoning and repeat the test before using real records.

The next step is one reviewed edition

Start with the eight-source worksheet. Complete it manually for one authorized project, resolve undefined fields, then use the fictional packet as a known-answer test. Only after reviewers can follow the draft back to its inputs should you consider a limited real-data trial. Keep a manual reporting path available.

Teams that already have a reliable native report may not need a new assistant. Teams that lack permission to supply the records should not upload them merely to try the prompt. Ask OpenMax or your administrator to verify the relevant access, retention, integration and review arrangements before adoption; those controls are not demonstrated by this article.

Avoid the failures that make automation look successful

A polished report with a moving target. The current forecast overwrites the approved date, so slippage disappears. Preserve both fields and a separate approval record. When rebaselining is authorized, disclose it and explain its effect on trends.

A complete download with incomplete financial coverage. Every file arrives, but one file excludes a cost category or the last day's postings. Test semantic coverage, not just file presence and job success. Financial owners must review the basis; the report should not invent recognition rules to fill a gap.

A task metric promoted into a business outcome. More tickets close while acceptance is blocked. Use each measure's actual name and denominator, and place the acceptance exception beside it. Avoid a single percentage that blends counts, effort, expenditure and expected benefit.

A draft that becomes an action. A sentence proposing a supplier commitment is sent as if agreed. Keep drafting, approving and executing separate. Enforce permissions in the actual workflow, not just in a prompt. A qualified human must review consequential financial, security or privacy decisions.

A report that exposes more than its recipients should see. Source links, screenshots and embedded extracts can reveal information even when the summary sounds harmless. Review the destination audience and access to each attachment. Use minimal necessary information; do not treat source access for the author as permission for every recipient.

A silent retrospective rewrite. Late evidence changes last week's report without showing why. Preserve the issued edition and link any correction under the applicable retention policy. Record the newly learned fact and its verification state. Never infer that correcting the report means a recovery action has actually happened.

Frequently asked questions

Can an automated project status report be fully automatic?

Collection and defined calculations can be automated when the data, permissions and mappings are reliable. Narrative generation can also be scheduled, but that does not resolve contradictory records or supply missing approvals. Use the organization's release policy to decide which reports require human confirmation, and keep exceptions from being silently published as settled facts.

Which sources do I need if my project is small?

The eight categories are a coverage checklist, not a requirement to buy eight tools. One approved workbook may contain the plan, milestones, risks and decisions. Mark genuinely inapplicable categories with reasons, and do not mark a required source inapplicable simply because it is difficult to obtain.

How should I calculate red, amber and green status?

Agree dimension-specific rules, evidence requirements and an overall aggregation rule before reporting. Include unknown for missing applicable evidence. In our fictional case, a forecast after the approved deadline makes schedule red, and known red takes precedence overall while unknown budget remains visible. That is the example's rule, not a universal project-management standard.

Should a late update change last week's report?

Record both when the claimed event occurred and when the information became available. Verify the update, then follow the correction policy for the issued edition. A later claim that an issue was fixed does not by itself prove that acceptance passed, and it must not be presented as information the original report already knew.

Does this example prove OpenMax improves reporting speed?

No. SR079 is a fictional teaching packet with inspectable calculations, not a timed product test or customer case. The documented OpenMax prompts provide a basis for a limited drafting trial. Any time saving, accuracy or integration claim would need a defined real test and evidence that is not supplied here.

Sources and related workflows

Sources checked September 5, 2026. Vendor documentation supports the bounded descriptions linked above; the eight-source grouping, reporting rules, fictional records and arithmetic are original editorial examples. Professional review of a real project's accounting, access and approval requirements remains necessary.

• Atlassian: project status report structure.
• Microsoft: baseline and interim plan reference values.
• Microsoft: status date for project reporting.
• Microsoft: labor cost tracking scope and calculations.
• Asana: preparing project status updates.
• OpenMax: Operations use cases and project-status prompt examples.

Use the decision log template when a proposed recovery date needs a recorded decision. Use the AI product requirements document template when the unresolved issue is what the deliverable must satisfy. A status report connects those records; it should not silently rewrite either one.