project-status

# Draft a project status update A status update is read by people who will not open a single issue. It has to survive being the only thing they read: **is this landing, what changed, and what do you need from them.** ## 1. Read the movement, not the snapshot Percent-complete is the number people reach for and the one that lies. A project can sit at 70% for a month while the last three issues get harder. What tells the story is what moved since the previous update: issues completed, issues added, and target dates that shifted. Fetch the project's issues plus its previous status update. Without the previous one you are writing a summary, not an update, and the reader cannot tell what is new. ## 2. Judge the trajectory honestly Pick one and commit to it. Hedging every sentence is how a project stays green until the week it ships late. | Call | What justifies it | | --- | --- | | **On track** | Remaining scope fits the remaining time at the current rate | | **At risk** | A dependency, an unknown, or a rate that has to improve to land | | **Off track** | The date will move, or scope has to be cut — say which | If you cannot tell, the answer is at risk, and the reason is that nobody can tell. ## 3. Name risks as things that could happen "Backend integration is risky" gives the reader nothing. "The export endpoint is not built, we cannot finish import until it is, and the owner is on the payments migration until the 14th" tells them what to move. A risk is a specific event...