Your project status was green for weeks and suddenly turned red. What would have prevented the surprise?

Weekly written updates based on a forecast (not feelings), with risks and owners listed, so the status changes as soon as the forecast slips — plus early escalation with options.

What are the four parts of a good weekly project update?

Status and forecast (with any change at the top), progress against the goal, risks with owners, and decisions needed with deadlines — plus what's next.

How do you deliver bad news to stakeholders about a slipping date?

Early, in writing, with the new forecast, the main cause, two or three options with their trade-offs, and a date by which you need a decision.

Status Updates Stakeholders Trust — The Tech Lead Handbook

Scenario

Example team: the payments migration has three stakeholders: the CFO's office, the support lead and the head of engineering. Each asks the tech lead for status separately, in meetings and chat. Updates say "on track" until two weeks before the deadline, when they suddenly say "at risk".

What you see on the team

Frequent ad-hoc status requests interrupting engineers.
"Green" status for weeks, then a sudden "red".
Stakeholders hearing about problems from others first.
Decisions stalled because the people who must decide don't know a decision is needed.

The common mistake

Reporting activity ("we worked on X") and optimistic colour codes, instead of progress against the goal, risks and decisions needed.

Why it happens

Bad news feels like failure, so it's delayed until it's certain. Activity is easy to report; progress against an outcome requires a forecast. Without a regular written update, stakeholders fill the gap by asking — interrupting the team. Many companies with remote or distributed teams default to written, asynchronous updates for this reason; GitLab's public handbook is an example of working in writing by default.

The playbook

Send one written update on a fixed cadence (weekly for active projects), to one place. Keep it under a page:

Payments migration - week 7 update
Status: AT RISK (was ON TRACK)  |  Forecast: 85% by 14 Nov (was 31 Oct)

Progress: 38 of 60 items done (+6 this week). Reconciliation dry run passed.
Risks:
 - Identity API field not yet scheduled; blocks the final 8 items. Owner: Marco.
 - Card network test window only on Tuesdays; adds ~1 week if missed.
Decisions needed:
 - By Fri: accept the 14 Nov date, or drop partial-refund support from v1? (CFO office)
Next week: dual-write enabled for 10% of traffic.

Lead with the change and the ask. Status changes and decisions needed go at the top.

Use forecasts, not feelings (see Forecasting Delivery Honestly).

Escalate early with options, not just problems.

Make it skimmable: same structure every week, numbers over adjectives.

What to say

Delivering bad news early:

"We've moved from on-track to at-risk: the forecast is now 85% by 14 November, two weeks later than planned, mainly because of the identity dependency. Two options: accept the date, or drop partial refunds from v1 and keep 31 October. I need a decision by Friday."

Trade-offs

Writing weekly takes time; it saves more in interruptions and meetings.
Early "at risk" can feel alarming; pairing it with options keeps it constructive.
Too much detail gets skimmed; keep it under a page and link to the details.

Signals it's working

Ad-hoc status requests drop.
Status changes gradually, not from green to red overnight.
Stakeholders make decisions on time because they see them coming.
The team spends less time in status meetings.

Key points

One written update, on a fixed cadence, in one place, under a page.
Report progress against the goal, risks with owners, and decisions needed — not activity.
Use forecasts with confidence levels; change status as soon as the forecast changes.
Escalate early, with options and a decision date.