Lesson 6.3: Status updates people actually read
A status update that nobody reads protects nobody. Learn to lead with the bottom line, use a fixed format, report honest colours and ask for decisions.
By the end of this lesson you will be able to write a weekly status update that busy people read in two minutes and act on. You will learn to put the bottom line first, a fixed seven-part format, an honest way to use colours and trends, a method of tailoring updates to different readers and a habit of making every update end in a request. You will see a weak update rewritten into a strong one, three updates for three audiences and a simulator that shows what long updates cost the people who read them. This lesson follows 6.2, where you learned to deliver difficult news. Here you learn the steady, ordinary communication that makes difficult news rare and easy. You need no technical background.
The status update is the least glamorous task in the role and one of the most important. It is how the customer's sponsor knows the project is alive, how their management knows what to expect and how you create a record of what was said and decided. A good one costs a little over an hour a week and saves many hours of calls and questions. A poor one, long, vague and unread, costs the same hour and achieves nothing, and worse, it gives you a false sense that you have communicated. The test of an update is not whether you sent it, but whether the reader understood the state of the project and did what you needed.
Why updates go unread
Most unread updates share the same faults.
They start at the beginning. They open with background and a list of activities, and the reader must hunt for the point, which is often buried in the fourth paragraph.
They are about activity, not progress. "Held meetings, continued data analysis, worked on the integration" says what you did and nothing about where things stand.
They are too long. A page of dense text, sent every week, trains the reader to skim and then to stop.
They have no shape. Each week looks different, so the reader cannot find the same thing in the same place.
They hide trouble. Problems are mentioned softly in the middle, or left out, so that the report looks calm.
They ask for nothing. The update ends with a general "let me know if you have questions", and the reader has no reason to respond.
Each fault has a remedy, and they fit together as a single method.
Bottom line first
The most valuable habit in writing for busy people is to lead with the conclusion. It is often called BLUF, short for "bottom line up front", a rule that is traced to US military writing guidance, which argued that the great weakness of ineffective writing is that it does not quickly deliver a focused message. The same principle appears in business writing as the idea of starting with the answer and then giving the reasons and the details.
The reasoning is about the reader's time and attention. A reader who stops after two lines should still know the state of the project and what you need. A reader who goes on should find the evidence. A reader who wants the detail can have it at the end. The update is built as a pyramid: conclusion at the top, support below, detail at the base.
In practice this means that the first two lines of every update say three things: whether the project is on track, the single most important thing that has changed and what you need from the reader. A sentence such as: "On track for the 29 November decision. The data extract arrived and the first results look good. I need the compliance reviewer named by Wednesday." tells a busy reader everything they need in twenty seconds.
Predict first: your update this week has a lot in it: five tasks completed, two problems found, one decision needed and a change to the date. You have room for two lines at the top. What goes in them? Decide before reading on.
The top two lines should hold the overall state, which includes the date change since that is what the sponsor will care about most, and the one decision you need. For example: "On track except for the date: the pilot start moves from 15 to 22 November because of the extract delay. I need your decision on starting with a partial file by Wednesday." The five completed tasks go lower, in a short list, and the two problems go in the risks section with what you are doing about them. If the top two lines are right, the sponsor can act without reading the rest.
A seven-part format
A fixed format makes an update fast to write and fast to read, because everyone knows where to look. The following seven parts work for most projects. Keep them in the same order every week, and keep the whole thing to one page.
1. Headline. Two lines: overall status, the main change since last time and what you need.
2. Status and trend. An overall colour for the project, and perhaps one for each major area, with an arrow showing whether it is improving, steady or worsening.
3. Progress against the plan. What was completed, measured against the milestones in the one-page plan from Lesson 2.4. Short, specific and checkable: "Nightly load running for 18 of 24 branches" is better than "continued work on the data load".
4. The metric. The success metric from Lesson 2.3, with the baseline, target and the latest value, or the leading indicator if the final result is not yet known. If there is nothing to report, say so.
5. Next steps. What will happen before the next update, with names and dates.
6. Risks and blockers. The two or three that matter most, each with what you are doing about it and what you need.
7. Decisions and requests. A numbered list of what you need from the reader, who must decide and by when. This is the part that makes the update worth reading.
The order matters. The headline gives the conclusion. The next three parts support it. The last three look forward and ask. A reader who reads only the first and last gets most of the value.
Colours and trends: telling the truth
Many updates use a traffic light: green for on track, amber for at risk and red for off track. It is a useful shorthand, if it is honest. Three habits keep it so.
Define the colours. Agree with the customer what each means. A useful definition is: green means we expect to meet the date and the target with no help needed; amber means we expect to meet them only if something happens, such as a decision or a delivery, and we have said what; red means we will not meet them without a change to the plan, the scope or the resources. With definitions, a colour is a statement. Without them, it is a mood.
Do not hide red inside green. A familiar failure is the report that is green on the cover and troubled in the detail, sometimes called a watermelon: green outside, red inside. It comes from reluctance to give bad news, and it destroys the value of the colours, because the reader learns that green does not mean green. If a milestone is at risk, say amber on the day you know, not after it is missed. The advice on early news in Lesson 6.2 applies directly.
Show the trend. A colour is a snapshot. A trend shows direction: amber and improving is very different from amber and worsening. A small arrow, or the words "better", "same" or "worse than last week", gives the reader the sense of movement.
An honest update is not an alarming one. A project that reports amber when it is amber, and green when it is green, is a project whose green can be trusted. Customers learn quickly which reports to take seriously, and they remember who told them early.
Write for the reader
Within the format, a few writing habits make each part clear.
Short sentences, plain words. Say "load" and not "ingest". Say "late" and not "behind the baseline".
Numbers and dates. "Eighteen of twenty-four branches" and "by Friday 22 November" are better than "most" and "soon".
Names for actions. "Priya to confirm the template by Wednesday" is an action. "Template to be confirmed" is a hope.
Specific, checkable progress. Describe results, not effort. "Reduced the number of rows set aside from 412 to 40" says something. "Worked on data quality" does not.
One idea per bullet. If a bullet needs a semicolon, it is two bullets.
Define unfamiliar terms once. Not every reader is technical.
Be the same each week. The same format, the same order, the same place to look. A reader who knows where to find the date does not have to hunt.
When you have written it, read the first two lines and ask: if this were all the reader saw, would they know the state and what I need? If not, rewrite them.
Different readers, different updates
A project usually has several readers, with different needs, and one update rarely serves all of them. A common and efficient pattern uses three layers.
The executive note. Three to five lines, sent to the sponsor and their management, with the headline, the trend, the metric and any decision needed. It can often be the top of the full update, forwarded.
The weekly update. The seven-part page, sent to the project group: the sponsor, the day-to-day contacts, the data owner and the compliance reviewer.
The working channel. A shared chat or a task list where small questions and daily progress live, which does not need to be summarised in the update.
The executive note is what people forward upwards, and it is often the only thing the sponsor's own manager sees. Write it so that it makes sense without the rest, and so that the sponsor would be comfortable sending it on unchanged.
Choose the channel to fit the news. Routine progress goes in the weekly update. A serious problem is a call, followed by a written note. A quick question goes in the working channel. A decision should be recorded in writing, in the update or in a short email, so that there is a record.
The update is a request
The most important difference between a read update and an unread one is that the first asks for something. Every update should end with a numbered list of requests, each with a name and a date. This list does several jobs.
It gives the reader a reason to read to the end.
It makes it clear who must act, which reduces the chance that everyone assumes someone else will.
It creates a record: when a decision was needed and when it was made. If a date slips because a decision was late, the record shows why, without blame.
It lets you follow up with confidence: "In last week's update I asked for the reviewer to be named by Wednesday."
If you have nothing to ask for, say "no decisions needed this week", which tells the reader they can relax. A habit of using that line, when it is true, makes the reader take the lists seriously when they appear.
Cadence
How often should you send an update? The best rhythm is regular and predictable, not too frequent. For most pilots, one a week, on a fixed day and time, is right. A customer who knows the update arrives on Friday morning will look for it. Increase the frequency only when the project is in a critical phase, such as the week of go-live, or in an incident, and say that you are doing so.
Two exceptions are important. Send bad news immediately, outside the schedule, as Lesson 6.2 explained. And send an update even when there is little to say. "No change this week; the extract is still due on the 22nd" is useful, and the absence of an update makes readers wonder what you are not saying. A project that goes quiet is a project people start to worry about.
Worked example 1: the update that was not read
Here is the opening of a weak weekly update from the lender's pilot, of the kind often written in good faith.
"This week the team continued work on the data pipeline and held several meetings with stakeholders to discuss requirements. We made progress on the integration with the messaging platform and also looked at some data quality issues that were identified. There were some delays on the extract, which we are monitoring. Next week we will continue with the above activities and begin planning for the pilot."
Everything in it is true, and the reader learns almost nothing. There is no status, no date, no number and no request. The important fact, that the extract is late, is buried and softened. The sponsor, after a few of these, stops opening them.
Here is the same week, rewritten.
"Headline: Amber. The pilot start moves from 15 to 22 November because the data extract is a week late. I need a decision by Wednesday on whether to start with a partial file.
Progress: nightly load running for 18 of 24 branches (target 24 by 20 November); message templates submitted for compliance review (two-week review, due 20 November); 412 rows set aside for date problems, now 40 after a rule change.
Metric: baseline 41 per cent of first-band accounts paying within seven days; target 48; no pilot data yet.
Risks: extract delay (data team has committed to 22 November); language missing for 38 per cent of borrowers (defaulting to Hindi, review with the head of collections).
Next week: finish the load for the last six branches; test the grouping on a full day's file; rehearse the first run.
Decisions needed: (1) Start with the partial file covering 70 per cent of accounts, or wait for the full extract: Head of Collections, by Wednesday. (2) Name a compliance reviewer for templates: Compliance officer, by Wednesday."
It is about the same length as the weak version and says far more. The sponsor can read the first line and know what she must decide.
Worked example 2: three updates for three readers
On the same Friday, the engineer writes three things about the hospital pilot.
For the chief operating officer, a four-line note: "Green and steady. The bed screen is live in two hospitals; median time to find a bed is 9 minutes against 18 before. One decision: approve adding the next two hospitals, which needs an hour from each IT lead. Full update attached."
For the project group, the one-page weekly update with the seven parts, including the accuracy check at 96 per cent and a risk that the third hospital's definition of a free bed is still not agreed.
For the nurse managers, a short message in their group chat: "The screen now shows reserved beds separately, as you asked. Please tell me if any of tonight's numbers look wrong."
Each reader receives what they need and no more. The COO's note can be forwarded upwards as it is. The nurse managers see that their request was acted on, which keeps them engaged. The engineer writes the three in about forty minutes, because they all come from the same facts.
Worked example 3: the colour that lost its meaning
On another project, the weekly status has been green for nine weeks. In week ten, the engineer reports red, and the sponsor is shocked: "It was green last week." The engineer explains that the data problem had been growing for a month.
The sponsor's reaction is not about the problem. It is about the green. She says, "Then green meant nothing." Over the following weeks she asks for the raw numbers behind every colour and re-reads every update closely, and the engineer finds that the time saved by a short report is now spent on calls.
The review of the project finds that three of the earlier greens were really amber: a milestone had slipped by a few days, a risk had emerged and a dependency had not been confirmed. Each was small, and each was reported as green because it had not yet affected the date. Used honestly, the colours would have shown a gradual slide, and the red in week ten would have been no surprise. The lesson is that a colour is only worth the trust that its history has earned, and that amber is the honest word for "I am worried but it is not yet broken".
The third example is easier to see on a chart. The line shows the colour the engineer reported each week and the colour an honest report would have given, on a scale of three for green, two for amber and one for red.
What long updates cost
It is easy to treat the length of an update as a matter of style. It is also a cost. Every reader spends time on it, every week, and the total across a project is large. Suppose twenty-five people on the customer's side read each update, taking five minutes, four times a month. That is more than eight hours of reading each month, and if the update is unclear, much of it is wasted.
The simulator below turns this into numbers. Set the number of readers, the minutes the update takes to read, the number of updates a month and the cost of an hour of the readers' time. It shows the reading hours per month and their cost, and the hours that would be saved by cutting the length by a chosen share. It plots the total reading hours by the length of the update.
The figures are illustrative. They do not capture the value of a good update, which is much larger than its cost. But they make a point that writers often forget: a longer update is not free. It borrows the time of everyone who reads it, and the shorter, clearer one is a kindness as well as a courtesy.
Try three experiments. First, keep the defaults and read the hours. Second, cut the reading time from five minutes to two and see the saving. Third, double the number of readers and see how fast the cost grows, which is why the executive note, sent widely, must be the shortest.
At the defaults, twenty-five readers at five minutes, four times a month, spend about 8.3 hours reading, worth about ₹8,300 at ₹1,000 an hour. Cutting the length by 40 per cent saves about 3.3 hours a month. The numbers are small for one project and large over a company. More important, a shorter update is read more fully, so the message gets through.
Common mistakes
Starting at the beginning. Put the bottom line, the main change and your request in the first two lines.
Reporting activity. Say what is finished, measured against the plan, and what the metric shows.
A different shape every week. Use the same seven parts in the same order.
Colours without definitions. Agree what green, amber and red mean, and show the trend.
Green that hides red. Report amber on the day you are worried, not after the date is missed.
One update for all readers. Use an executive note, a weekly update and a working channel.
No request. End with a numbered list of decisions, with names and dates, or say that none are needed.
Silence when there is little to say. Send a short update anyway.
Waiting for the schedule with bad news. Send serious news at once.
Key takeaways
A status update succeeds when the reader understands the state of the project and does what you need, not when you have sent it.
Lead with the bottom line: the overall state, the main change and what you need, in the first two lines.
Use a fixed seven-part format: headline, status and trend, progress against plan, the metric, next steps, risks and blockers, and decisions and requests.
Define the colours, show the trend and never hide red inside green. Amber is the honest word for worried but not broken.
Write in plain words, with numbers, dates and names. Layer the update for different readers, with a short executive note.
End every update with a numbered list of requests. Send a regular update on a fixed day, send bad news at once and send something even when little has changed.
Check yourself
1. What should the first two lines of an update contain?
The overall state, the most important change since last time and what you need from the reader.
2. Name the seven parts of the format.
Headline, status and trend, progress against the plan, the metric, next steps, risks and blockers, and decisions and requests.
3. What is wrong with a report that is green on the cover but troubled in the detail?
It teaches readers that green does not mean green, so they stop trusting the colours and ask for the raw numbers.
4. Twenty readers spend 4 minutes on each update, 4 updates a month. How many reading hours a month, and how many are saved if the length is cut by half?
20 × 4 × 4 ÷ 60 = 5.3 hours. Cutting by half saves about 2.7 hours.
5. Why end every update with a list of requests?
It gives the reader a reason to read on, makes clear who must act and by when, and creates a record you can follow up.
Try this
This exercise takes about forty minutes and gives you a real update. Use a project you work on, or imagine one.
1. Write down what happened this week in plain notes, without worrying about order.
2. Decide the overall status, using colours you define in a sentence each, and the trend.
3. Write the first two lines: state, main change and what you need.
4. Fill in the seven parts. Make every progress item specific and checkable, and every action carry a name and a date.
5. Write a numbered list of decisions and requests, each with who and by when. If there are none, write "no decisions needed this week".
6. Cut it to one page. Remove anything the reader does not need to act.
7. Write a four-line executive note from it that could be forwarded unchanged.
8. Give it to one person who has not seen the project. Ask them to tell you, after two minutes, the state of the project and what you want from them. Revise until they get both right.
A good result is a one-page update, a four-line executive note and a reader who can say what is happening and what you need. It is the weekly document that keeps a customer project honest and calm.
Sources
[BLUF (communication)](https://en.wikipedia.org/wiki/BLUF(communication)), Wikipedia. Used for the "bottom line up front" rule and its origin in US military writing guidance. Other sources describe a related idea in business writing, sometimes called the pyramid principle and associated with Barbara Minto, and the sources I read do not settle which came first.
The three updates, the reader tally and the simulator's figures are the author's illustrations for teaching, not data from real projects or surveys. The seven-part format and the meanings of the colours are practical methods written for this lesson, not industry standards.
Tags: Forward Deployed Engineer Status updates Writing Customer communication Project reporting