Reporting Progress To People Who Will Never Open The Board

You sent your client a login to the project board six weeks ago. They have never opened it. Every fortnight somebody on your team spends two hours writing a progress report by hand instead.

The fix is a one page report that answers three questions and nothing else: what is the date now, what could still break it, and what do we need you to decide. Everything a sponsor or client actually wants is in those three answers. Write the page so it can be assembled from the board you already keep, rather than composed fresh each time.

Why the board login never works

A board is a working surface. It is built for the people who move cards around every day. Someone who touches the project once a fortnight opens it and sees fifty items in four columns with no idea which ones matter.

They also cannot tell what changed. A board shows the current state, not the difference since they last looked. For an executive, the difference is the whole story.

So they stop opening it and start asking you in a meeting instead. That is the meeting you were trying to avoid.

The one page, in order

Put these in this order, on one page, every time. Same order means the reader learns where to look.

• The date. The current expected finish date, and whether it moved since the last report. If it moved, one sentence on why.
• What got done since last time. Three to five lines, in the reader's language, not yours. "Payment screens built and tested" beats "closed SH-4412".
• What is next. The next two or three chunks of work, with rough timing. Two or three rather than ten, for the same reason work in progress limits exist.
• Risks, with a plain sentence each. What might go wrong, how likely it feels, and what you are doing about it.
• Decisions we need from you. Each one with a date by which you need an answer, and what happens if the answer is late.
• Anything we are waiting on. Access, approvals, content, a signature. Name the person.

That is it. No burndown chart. No velocity. No screenshot of the board.

Generate it, do not write it

The reason these reports get skipped is that writing one by hand takes an hour and feels like admin. So make the board carry the fields the report needs.

Three small habits do most of the work:

• Give every item a plain English title that a non specialist could read out loud. If a card title only makes sense to the person who wrote it, the report will need translating.
• Keep a single field for the expected finish date, and change it in one place when it moves. If the date lives in a chat message and a spreadsheet and someone's head, the report will disagree with itself, and a short weekly cleanup pass is what keeps the field honest.
• Log risks and open decisions as items on the same board, not in a separate document. A decision that is not on the board will not appear in the report.

Once those three are in place, the fortnightly report becomes a filter over the board rather than an essay. This is one of the reasons SicherOne keeps project records and HR records on the same set of data: when the report says a piece of work slipped, the reason is often that the owner was away, and a board that knows who is on leave puts that fact right there rather than in a different system.

Keep the cadence boring

Send it on the same day, at the same time, whether or not there is news. A report that only arrives when things are going well trains the reader to fear your emails.

If nothing moved, say nothing moved, and say why. "Two weeks lost waiting on the content you owe us" is a useful sentence. It is also much easier to write in a routine report than in a difficult conversation three months later.

What to do when they still ask for a meeting

Some readers want a call regardless. That is fine. Send the page first, then run the call off it.

The page changes the meeting. Instead of half an hour of you narrating status, you get ten minutes on the decisions section, which is the only part where the other person can actually help. That is the point of the whole exercise.

A short test

Give your last progress report to someone who has never heard of the project. Ask them three questions: when does it finish, what could go wrong, and what does the client have to do. If they cannot answer all three from the page, the page is not doing its job yet.