Home / Project Management / One Page Project Reporting

One Page Project Reporting

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.


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!

If you enjoyed this post, make sure you subscribe to our RSS feed!

About Kik Piney

Kik Piney
Crispin Piney, an instructor with ESI International, has developed and deployed technically advanced—and culturally complex—capabilities and services in both research and business environments for large multinational companies, advising on project management expertise enhancement throughout such organizations.
Mr. Piney is well known for his ability to link the theory of project management to practical examples taken from his work experience and from everyday life. He is a lively speaker who generates enthusiasm and interaction in his audience. He has a bachelor’s degree in mathematics from Imperial College, London, and is anAssociate of the Royal College of Science, London. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®) and is a member of the PMI® France chapter. He is bilingual in English and French.

Discover the new Adaptive Strategic Execution Programme

%d bloggers like this: