Brad Egeland has a post about status reports. This is a topic near and dear to my heart, along with many others. Brad has a nice list of items that should be in a status report.

• Project title
• Project description
• Contact information for key project personnel
• Quick view high-level status on project, budget, and schedule
• Recent tasks completed
• Tasks in progress
• Upcoming tasks
• Status of all change requests
• Detailed budget status
• Issues status
• Risks status

Here's my experience in a variety of project domains, ranging from Enterprise IT, heavy construction, defense and space, industrial projects, and other domains.

Fundamental Reason for a Status Report

A status report should do just what it says – report the status of the project. So what are the primary elements of the project status?

• Are we on schedule?
• Are we on budget?
• Are the deliverables we said we would deliver compliant with their technical performance measures?
• Do we have all we need to stay on budget, on schedule, and meet the technical performance requirements?
• Do we know the risks and do we have a plan to mitigate or retire them?

This is the status of the project.

Here's the real problem with Status Reports

Status reports should report progress to plan. Tasks and the execution of tasks are not measures of progress. The production of deliverables are the measure of progress. So Brad's list of tasks in progress, upcoming tasks, and completed tasks are no measures of progress.

This is a common mistake of confusing effort with results. “We're completing all these tasks, so we must be making progress.”

It's results that measure progress, not the effort.

So the status report must state in clear and concise terms, what results were accomplished during the period of measurement. But not just any results, but the Planned Results. So this means we must know what results were planned. This means we must have a Plan. A Plan that says what is “planned” to be accomplished.

Here is the original: Herding Cats