PM Toolkit - Status Reports

Tool: Status Reports
Type: Document

When a Project Manager says that he'd like to keep everybody on the same page, that page has a heading saying "Status Report". A status report is an indispensable tool by any PM that must ALWAYS be used. Since projects typically involve various stakeholders with varying interests in the project, there needs to be a central view on what is happening with the project at a specific point in time. Otherwise, we'd all be a bunch of blind people describing an elephant - each by touching a specific part of the animal. The status reports are meant to inform everybody on various aspects of the project so that the appropriate responses/reactions can be elicited from the stakeholders.

When we do status reports however, some things need to be remembered:

• The status report is meant to answer the question "What is happening to the project NOW?" It is important to remember that the status report is meant to report the status of the project. You seldom need to write historical information on the project (such as what happened before or why the project was initially conceptualized, etc.) but rather the newest and latest information on the project NOW. Information should be hot-off-the-press.
• The status report should be delivered on a timely manner. You cannot deliver a status report on what happened two months ago with the project. Its stale information that was probably already communicated in some other form to the stakeholders a long time ago.
• The status report should be regularly published/submitted. There needs to be a regularly defined cycle by when a status report is to be expected. You do not create a status report only when it is asked from you, a status report is EXPECTED from any PM. Note that the frequency of a status report is relative to the amount of work that expected within a project. IF for example a project normally has deliverables on a weekly basis, then a weekly status report might be good. If work takes longer, such as weeks, then a monthly status report might be okay.
• A status report needs to contain an assessment of the Project Manager. The simplest way to do this is to use traffic lights (Green, Yellow, Red) on certain areas of the project such as schedule, cost, quality, etc. A Project Manager needs to know if we are currently doing good with the project or if we need to do something else to get the status back to Green. There are other ways by which a project can be quantified or assessed (such as CPI, SPI, TCPI, etc) but traffic lights typically do the job fairly well since most everybody knows what the color means. Moreover, be consistent in assessing the status of the project. Define what makes a project green, or yellow, or red. This way the stakeholders have a fairly good grasp on the status of the project.

• A status report needs to be complete yet concise. If stakeholders don't seem to be the type that would read long status reports - then by all means change it. A status report is useless if no one is reading it. Always consider the areas that you think the stakeholders would want to ask about the project and work on that.