The One-Screen Project Status Every Client Deserves

Start with the outcome, not the activity

Put the intended outcome at the top in one or two plain sentences. An outcome describes the useful condition the project is trying to create. “Customers can request service online and staff can respond from one queue” is an outcome. “Build forms, configure email, and connect the CRM” is a list of activity.

This distinction keeps a project from looking healthy merely because many tasks are moving. It also gives the client a stable reference point when the implementation changes. The Scrum Guide similarly distinguishes a longer-term Product Goal from the work selected to move toward it. Poygan’s recommendation is to translate that idea into language any client can evaluate.

If the outcome has changed, do not quietly replace it. Show the revision in the change log and identify who accepted it.

Describe the current state in one honest sentence

The current state is a compact assessment, not a percentage pulled from intuition. Use a small, defined vocabulary such as on track, attention needed, blocked, or complete. Follow the status with a sentence explaining why it applies.

For example: “Attention needed: the intake form is working in the test environment, but launch depends on the client approving the final routing list.” This tells the reader more than “80% complete.” It identifies what is real, what remains uncertain, and what could change the schedule.

Define the terms once. “Blocked” should mean that useful progress on the next committed action cannot continue. “Attention needed” can mean work is moving but a known issue may affect scope, timing, or quality. Consistent definitions make the status comparable from one update to the next.

Connect the last completed item to the next action

Two short fields create the project’s narrative: last completed and next action. The first supplies evidence of movement. The second turns the update into a commitment.

Write completed work as an observable result: “Test submissions now create contact records with the correct source and owner.” Avoid vague entries such as “Worked on CRM integration.” If verification is still pending, say so.

Make the next action small enough to own. “Poygan will test duplicate handling with five synthetic records by September 29” is clearer than “Continue testing.” A synthetic record is invented test data, not information from a real customer.

This pair also exposes drift. If the same next action appears repeatedly without becoming the last completed item, the team has found something worth discussing.

Name the owner, blocker, and decision separately

These fields answer different questions. The owner is the one person responsible for moving the next action forward. Other people may help, but shared ownership often makes the handoff harder to see.

A blocker is a condition preventing the next committed action. Name the condition and its effect: “Production access has not been granted, so deployment cannot begin.” Do not use the blocker field to assign blame.

A decision needed is a choice that someone must make. Include the decision owner, the available options, the practical consequence, and the date by which the choice begins to affect the plan. If no choice is pending, write “None.” An empty field makes readers wonder whether the question was overlooked.

The Scrum Guide assigns accountability for work and calls for impediments to be identified and addressed. The one-screen format applies those principles to a client-facing update without requiring the client to adopt Scrum terminology.

Date the snapshot and preserve a small change log

A status report is a snapshot, so give it an “as of” date. Also include the next planned update date. This prevents an old screenshot or forwarded email from masquerading as current information.

Below the snapshot, keep a short change log for changes that affect the outcome, scope, schedule, cost assumption, responsibility, or important technical approach. Each entry needs a date, a concise description, and the person or group that accepted the change.

Do not turn the change log into a diary of every task. Its purpose is to preserve the decisions that would otherwise be explained differently a month later. Routine task history can remain in the project system.

A copyable one-screen status format

The following is a hypothetical example for a fictional website inquiry project. It does not describe a Poygan customer or a measured result.

Outcome: Website inquiries reach one staff-owned queue with enough information for a useful reply.

Current state: Attention needed. The form and routing workflow pass synthetic tests, but the production recipient list is awaiting approval.

Last completed: Verified that valid test submissions create a queue item and confirmation message.

Next action: Morgan will approve or revise the production recipient list by September 29, 2026. Jake will then run the launch checklist on September 30, 2026. Owner: Morgan owns the approval; Jake owns the subsequent launch check. Blocker: Production routing cannot be enabled until the recipient list is approved. Decision needed: Choose whether billing questions go to the general queue or directly to accounting by September 29, 2026. Status date: September 25, 2026. Next update: October 2, 2026. Change log: September 24, 2026, added billing-question routing to the launch scope; accepted by the fictional project owner and provider lead.

Keep the screen useful on both sides of the relationship

The service provider should update the page before a status conversation, not reconstruct it during the call. The client should correct inaccurate outcomes, name decision owners, and challenge words that hide uncertainty.

If the update no longer fits on one screen, link to supporting material instead of shrinking the type or packing every task into the summary. The status is the front door. The task board, requirements, test evidence, budget details, and meeting notes can live behind it.

Finally, use the same field order every time: outcome, current state, last completed, next action, owner, blocker, decision needed, date, and change log. Familiar structure reduces the effort required to spot what changed. The best status page is not the one with the most data. It is the one that lets both parties see the next responsible move.