The weekly written status and async habits

A project status report isn't a diary of effort; it exists so its readers can decide something. Each reader has a question: Leo needs the forecast against the opening date, Hanna the money, Roman what lands on his team next.

Danylo's draft for 23 December reads: "Green. Great progress this week! The review is done, demo lessons are going well and the team is working hard. No blockers." Every word may be true, and it is still useless. There is no forecast against 1 February and no state of the buffer. The colour has no reason. There are no risks, although only some candidates have been seen and the tutors' slots are unconfirmed. And it doesn't say whether anyone needs to decide anything.

Length isn't the problem: five short lines are enough. Missing content is. Ask of every status: what can the reader now decide that they couldn't before?

A weekly status needs five lines, in this order:

1. Where we are against the plan: the forecast for the opening date and the state of the buffer.
2. What changed since last week.
3. Top risks, with owners and the next signal to watch.
4. Decisions needed: from whom, by when.
5. Next week: what will be done and by whom.

The order follows the reader. First the answer to "are we on track for the date?", then what moved, then what could break it, then what the reader must do, and finally what happens next. A reader who stops after line one still knows the state of the project.

At Klasna on 23 December the facts fit easily: the draft took 5 days instead of 4, the review 7 instead of 6, and demo lessons started a day after the review, on 17 December, so 3 of the 11 buffer days are used; 8 of 12 candidates seen, 6 passed.

A colour is a summary of the forecast, and the forecast for a chain with one shared buffer comes from one comparison: how much of the chain is done against how much of the buffer is used.

At Klasna on 23 December, two tasks ran over (the draft 5 days instead of 4, the review 7 instead of 6) and demo lessons started a day after the review, so 3 of the 11 buffer days are gone, about 27 %. But about half the chain's planned days are done. The buffer is burning slower than the work moves, so the forecast holds: green is honest.

Write it with its reason: "Green: about half the chain done with about a quarter of the buffer used." Now the reader knows why it is green and what would change it. Two tasks running long isn't a reason for amber or red: tasks landing inside their ranges are exactly what the buffer is for.

Everyone avoids amber because it looks like failure, so colours drift to green until they jump to red. The fix is to agree the meaning once, in writing, tied to the forecast:

• Green: the forecast holds without help.
• Amber: it holds only if a named action or decision happens.
• Red: it doesn't hold without changing the date, scope or money.

The forecast comes from comparing buffer use with progress. Imagine a week where two of the five chain tasks are done, about 40 % of the planned days, but 6 of the 11 buffer days are gone, about 55 %. At that rate the buffer runs out before the chain ends. The date still fits if the demo lessons go as planned, which is exactly amber: name the action that protects the date. Red would be wrong (the date still holds), and green would hide the trend. "No colour until later" leaves the reader with nothing.

A status earns trust by being early, not by being green. Amber early gives the sponsor time to act while options still exist: approve a second round of demo lessons, cut a could item, move a task. The status that destroys trust is the one that stays green week after week and then turns red overnight, when the only options left are changing the date, the scope or the money.

A colour also means nothing without its reason. Hanna puts it plainly: a green diagnostic test that cost 52,000 for 34,000 of work isn't green, whatever the schedule says. Every colour comes with the forecast and the one fact behind it.

So treat amber as a normal working state with a named action, not as a confession. If the team agreed the colour meanings in writing, nobody has to argue whether amber is "allowed".

Klasna's physics team is spread out: Vira in Lviv, two candidates in Poland, scheduled power cuts in Kyiv, air-raid alerts that stop live lessons. A remote team works when its habits are agreed in advance, not improvised during an outage.

• One place, one deadline. The status lives in one shared document, due by 18:00 Kyiv time on Wednesday. Whoever loses power posts when it's back; the document and the deadline stay the same.
• Interruptions are planning inputs, not exceptions. A demo lesson cut by an alert gets a new slot and isn't scored as failed; the dry run checks how a paused lesson is rescheduled.
• Questions across borders are written, with a reply-by time that names the time zone.
• Decisions exist only once written down: one line with the date, the decision, who made it and why, because the people in Lviv and Poland weren't on the call.

Line four of the status, decisions needed, works only if each request can be answered without a meeting. A good async decision request has four parts: the question, the options with what each risks, your recommendation, and a reply-by date.

At Klasna, Leo wants to know before the break whether marketing can publish "classes from 1 February". The request might read: "Decision for Leo by 28 December: publish the date now (risk: four tutors confirm slots only in early January) or publish 'from early February' and the exact date on 11 January (risk: a week less of sign-ups with a firm date). Recommendation: publish now; the buffer covers a late slot."

Leo can answer in one line, from anywhere, and the answer is already written down. A vague "let's discuss" or a call with everyone across outages and borders delays the decision past the date it was needed.

Busy readers read the top and stop. So the first line of a status carries the answer the most important reader needs, which for Leo is: does the date hold, and do I need to do anything?

For 23 December that line is: "Green: opening 1 February holds; half the chain done, 3 of 11 buffer days used; one decision for you by 28 December." Colour, forecast, the reason behind it and the call to action, in one sentence. Everything else, what changed, the risks, next week, supports it for those who read on.

Compare the alternatives: a list of activity ("busy week"), a risk without a forecast, or a friendly greeting. Each is fine further down; none tells a reader who stops after line one where the project stands.

How it fits together: a five-line status with honest colours, async habits and decisions in writing let the whole team see where the project is without a meeting. The case next tests all of module 5 at once: Leo changes priorities every week, and you keep the project steady without fighting him.