Herding Cats: Status Reports

Status Reports

Brad Egelandhas a post about status reports. This is a topic near and dear to myheart, along with many others. Brad has a nice list of items that shouldbe 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 fromEnterprise IT, heavy construction, defense and space, industrialprojects, and other domains.

Fundamental Reason for a Status Report

Astatus report should do just what it says - report the status of theproject. 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

Statusreports should report progress to plan. Tasks and the execution oftasks are not measures of progress. The production of deliverables arethe measure of progress. So Brad's list of tasks in progress, upcomingtasks, 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.

Sothe status report must state in clear and concise terms, what resultswere accomplished during the period of measurement. But not just anyresults, 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.