A small company hires a developer to build an internal ordering tool. For five weeks the client hears "going well". In week six the developer mentions that the supplier price import needs a file format nobody has provided, and that the launch date will move by three weeks. Nothing dramatic happened in week six. The problem was there in week two, and nobody wrote it down.
This article is for the owner or project lead on either side of a small software project. It describes a short update sent every two weeks, what belongs in it, which decisions to ask for, and how to raise a delay while it is still small.
Why fortnightly, and why short
Weekly updates tend to turn into noise on a small project: not enough has changed. Monthly updates are too late: a month is long enough for a wrong assumption to become a week of rework. Two weeks is usually enough time to finish something visible and short enough to correct course.
The update should take the sender twenty minutes and the reader two. If it is longer, people stop reading it, and the one sentence that mattered is lost.
The structure: done, next, risks, decisions
Use the same four headings every time.
Done. What was finished and checked since the last update. Write it as results the client can recognise ("orders can be created and edited; the confirmation email is sent") rather than activities ("worked on the orders module"). Say how it was checked: demonstrated, tested with real data, or only built.
Next. What will be finished in the coming two weeks. Three to five items is plenty. If an item depends on the client, say so here as well.
Risks. Anything that could move the date, the cost or the scope, even if it has not happened yet. For each: what it is, how likely it seems, and what you plan to do about it.
Decisions needed. Questions only the client can answer, each with a date by which the answer is needed and what happens if it is late. This is the most useful part for the client and the most often missing.
Facts and expectations
Mark the difference between what is true now and what you expect. "The import works with the sample file" is a fact. "The import should work with the live file" is an expectation. Mixing them makes every update sound more certain than it is, and the surprise arrives later.
A simple habit helps: use "done" only for things that were checked, and "expected" for everything else.
Flagging delays early
A delay is easier to handle on the day you notice it than on the day it hits the plan. When something slips, tell the client in the next update, or sooner if the date is affected, and include three things:
- What happened, in one or two sentences, without blame.
- What it changes: a date, a cost, or a feature.
- What you propose: cut something, move the date, or ask the client for something that unblocks the work.
Clients generally accept bad news that comes with a plan. They accept it much less well when it comes as a surprise at the end.
Asking for decisions
"Please give feedback" produces silence. "Please choose by Friday whether invoices are issued per order or monthly" produces an answer. For each decision:
- state the question in one line,
- give the options, with your recommendation,
- say what you need the answer for and by when,
- say what you will assume if there is no answer.
The last point matters: it turns a silent client into a client who has, by default, agreed to a stated assumption.
A one-page example
Update 3, ordering tool, 9 October
Done. Order creation and editing work and were demonstrated on Tuesday. Confirmation emails are sent in the test environment. Supplier import works with the sample file (checked).
Next. User accounts and roles; order list with filters; first version of the monthly report. Import with the live supplier file, expected, depends on the file below.
Risks. The live supplier file has not been provided. Without it the import may need rework (medium). Plan: test with the live file as soon as it arrives; the launch date holds only if it arrives by 16 October.
Decisions needed. (1) Please send the live supplier file by 16 October. If it arrives later, the launch moves by the same number of days. (2) Please choose by 14 October whether managers approve orders above a limit. Recommendation: yes, with a limit you set. If no answer, we build without approval and add it later.
This is an invented example to show the shape; adapt names, dates and wording to your project.
Common mistakes
- "Going well" with no detail. The reader cannot tell what was done.
- Activities instead of results. Hours spent are not progress.
- Hiding risks until they are certain. By then the options are fewer.
- Open questions with no date. They stay open.
- A different format every time. The reader has to search for the point.
- Only good news. The client stops trusting the report.
A short plan for this week
- Pick a fixed day for the update and put it in both calendars.
- Copy the four headings into a template.
- Write the first update from what you know now, including one honest risk.
- List the decisions the client owes, each with a date.
- After the second update, ask the client what they would add or drop.
For the first meeting that sets up this rhythm, see a kickoff meeting for a small software project. A page like this will not make a project easy, but it will keep problems small enough to solve while they are still cheap.
Sources
- Practical guidance based on common small software project practice, offered as a planning aid. The wording, timings and structure are illustrations to adapt to your own project. The opening scenario and the example update are invented. No client results or performance figures are claimed in this article.