How to keep the internal and customer versions of a status report apart.

A plant builder owes the customer a status report at regular intervals. Often it is written into the contract, at every milestone or on a fixed cycle. What goes into it is easy enough to describe. The difficulty is that the same project status has two audiences.

Your own management wants to know where the fires are. The customer wants to see that the project is under control and to learn what they still need to supply.

Anyone who maintains both versions by hand knows the two usual outcomes. Either an internal remark slips into the customer version, or the project manager spends every reporting day pulling together Excel, OneNote and email and then building two documents from it.

This article covers what belongs in a good customer report, what must never be in it, and how to produce both versions from a single status.

What should a customer status report contain?

A good customer report answers four questions. Where are we? What has happened since the last report? What comes next? What do we need from the customer?

Milestones and dates. Design release, ordering long-lead items, start of assembly, FAT, delivery, commissioning, SAT. Each milestone gets its planned date and its current status. If a delivery date moves, it is stated here, with one sentence on the reason as far as it concerns the customer.

Work completed. Be specific. "Design in progress" tells the customer nothing. "Guarding enclosure layout released, conveyor bill of materials handed to purchasing" does.

Next steps. What should happen before the next report and who is involved, including people on the customer side.

Open questions for the customer. The most important part. Missing details from the specification, outstanding approvals, clarifications on a customer change, dates for acceptance. Every question carries the date by which you need the answer.

Agreed changes. Which customer changes apply, with a reference to the revision status of the documents.

What must never appear in the customer report?

Some things are central to the project and still belong only in the internal version.

• Internal risks. "Drive supplier looks shaky" or "commissioning engineer double-booked in spring". These need to be raised internally. In front of the customer they trigger questions or contract discussions before you have a solution.
• Cost status. Budget consumed, additional costs, variation claims in preparation. A variation claim deserves its own letter, not a passing remark in a status report.
• Internal open points. Coordination between mechanical and electrical design, open questions for your own purchasing team, debates about the design approach.
• Internal notes. Views on contacts at the customer, remarks from the project meeting, abbreviations only the team understands.

The rule behind it is simple. The customer sees what they need to know and what they can influence. Everything else stays in-house.

Why does maintaining two versions go wrong so often?

A typical case. The project manager keeps the internal version as a Word file. For the customer she copies it, deletes the risks and the cost section and sends it off. At the next report she updates the internal version, copies it again and this time misses a comment in a table cell, or tracked changes still hidden in the document.

The opposite approach is no better. Maintaining two separate documents in parallel means writing every bit of progress twice. After a few weeks the versions drift apart. Then the customer sees a different FAT date from the one used internally, and nobody remembers which is right.

Underneath sits the real problem. The status is not actually in the report. It is scattered across an Excel schedule, OneNote pages from the site visit and emails in which the customer confirmed a change. Gathering it takes longer than writing it. Our article on project status in Excel, OneNote and email explains why.

What does a good status report template look like?

A template with a shared section and an internal appendix works well. You write the status once and, for the customer, simply cut off the appendix.

Shared section, goes to the customer

1. Header with project, report date, reporting period and contacts
2. Overall status in two or three sentences
3. Milestones with planned and current dates
4. Completed since the last report
5. Next steps until the next report
6. Open questions for the customer with the date an answer is needed
7. Agreed changes and revision status

Internal appendix, stays in-house

8. Risks with assessment and countermeasure
9. Cost status and possible variation claims
10. Internal open points with owners
11. Notes for the team

The fixed order is what matters. If the internal part always comes last, removing it takes one action rather than a hunt for buried sentences. Even so, check the customer version for comments, tracked changes and embedded objects every time before you pass it on.

How do you keep the status current between two reports?

The best template is of little use if the status is only assembled on reporting day. Three habits make the difference.

Record decisions when they are made. An email in which the customer confirms a change belongs in the project straight away, not in the report three weeks later. The article on project decisions from email shows how to do that with Outlook.

Keep open questions for the customer on a running list. Then item 6 of the template is already done on reporting day.

And separate internal from external when you write, not when you send. A note marked as internal from the start never has to be found again later. The article on project status without status meetings shows how a reliable status comes together without a weekly round.

How does KoAssist help with the status report?

KoAssist is an AI project assistant for machine and plant engineering. Its project function is called Project Memory and is currently in pilot operation. It replaces neither MS Project nor your ERP. It runs alongside them.

Project Memory keeps a project's status in one place. The overview shows status, next step, open points, decisions and risks. The schedule holds milestones, dates, deadlines and commitments. Emails from your mailbox are filed in the project with their attachments once you approve them. From emails and minutes, KoAssist suggests changes to the status, and only what someone on the team accepts becomes valid.

From this single status, KoAssist produces the status report as a Word file in two versions. The internal version includes open points, risks and cost status. The customer version leaves those parts out. So you never copy a document and delete sections from it.

KoAssist sends nothing. You open the Word file, read it, adjust the wording and pass it on yourself. Responsibility for what reaches the customer stays with you, and that is deliberate.

For item 6 of the template there is "Questions for the customer". You put open details from the project profile on a list, then copy it into your own email or download it. Here, too, KoAssist sends nothing itself.

How much work goes into your status report today?

If your report currently comes together from an Excel list, a few OneNote pages, your inbox and two Word files, take a look at Project Memory. It shows how the overview, the schedule and the two report versions fit together. If you would rather see it on one of your own projects, book a demo.