One Page Project Reporting

According to Second World War historians, Winston Churchill wanted all of his progress reports on only one sheet of paper. Given the huge challenge ahead of him at that time, it’s understandable that he did not want to be distracted with large amounts of paper!

Perhaps we could learn from his practices. Although a lot of reporting takes place through automated tools nowadays, it is advisable to keep the reports on the status of projects for which the PMO is responsible, as concise as possible.

A reporting format that has been successful with some companies in keeping paperwork to a minimum and report on just four key areas

Basic Information

Here we find a description of what the project entails, information about the sponsorship, who is working on the project (like the PM, BA and the primary SME’s).

Normally this information should stay static. Only when people are changing jobs, or if a major change request is granted, would this part change.

Accomplishments

Both what already has been accomplished and what is still to be done should go here.

Particular focus should be given here to entering only the accomplishments, and not being worked on.

So a good example of an accomplishment would be: “Completed the Business Requirements document”, a bad example would be: “Work continues on documenting the business requirements”.

On the accomplishments still to be completed, a good example would be: “Started work on the Functional Specification to be completed by 04/04/10”

Key Milestones and Deliverables

Here also, keep it short and sweet. The deliverables should be briefly described, like “Business Requirements document”, with a start date, target/planned completion date, percentage complete and the status (green, yellow, red).

If a deliverable is slipping and will be delivered late, the original date as well as the new completion date should be recorded. Once a deliverable is complete, remove it from the report when the next version of the report is issued.

Key Issues and Risks

If your organisation maintains a risk register by product, like the PMBOK® suggests, extract the major risks and identify the one that potentially could delay the project.

Be short on the description of these risks and mention their severity level (show stoppers, etc.).

If you use colour coding for risks, avoid using green, if something is a risk, how can it be green? Unless everybody understands that green means that the risk has been resolved (but then it would be no longer needed in this chapter!)

Adding the name of the person who owns the risk is the only other item that should be noted in this part of the report.

These 4 headings should be put on one sheet of paper, preferably without using the reverse side of it.

Make Winston proud!