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.

PM Toolkit - Meeting Minutes

I am starting off a series of posts on the essential tools needed by a PM in his line of work. It is quite often that we expect PM's to already "get it" as far as what we expect a good PM to be doing. However, this is not always the case. PM's have an idea on what should be done and how its supposed to be done, but quite commonly, PM's have no idea on how to do it correctly and why in the first place. Hence these succeeding posts aims to help the PM in understanding the common tools of the trade. These are common items, such as documentation, templates, or activities/steps that a PM is expected to do, and do quite well at.

Tool : Meeting Minutes
Type: Document

The Meeting Minutes (or MoM) in some circles is probably the most underutilized tool of all. The objective of the MoM is to document two distinct things that occur in a meeting.

1. What has been decided on during the meeting - which should contain who decided on what and why (if needed)
2. What are the next steps / action items - which should include target completion dates and specific people assigned to it. It is important to write down an actual name rather than just "customer" or "project team" since it transfers the accountability to a specific person. If an activity is dependent on certain conditions, include the fulfillment of the conditions as another action item on the list.

Of course, it is also important to include other information in the MoM such as when the meeting was held, who attended, what items were discussed, and so on... but not having the two items above will call into question the whole point on why a meeting took place. If it can't satisfy at least one of the two points, then there is probably no point to having a meeting in the first place.

Note that although some people may argue that some meetings are mainly to convey information (like status reporting meetings, etc.) , it is considered an "agreement" if the receiving party accepts the information conveyed to them. In some cases as well, people have "agreed" to disagree on certain topics during the meeting hence this constitute a relevant meeting that needs to be properly documented.

Meeting Minutes do not end in just being able to write it down. It is important to publish the MoM to the rest of the participants for their feedback and review. It is also important to keep the MoM in a location that can be easily retrievable by all, such as a shared drive, or a similar facility.

A seasoned PM knows that MoM can make or break a project. A lot of decisions happen that change the course of a project during these short and seemingly insignificant "meetings". I believe some of you out there have experienced times wherein somebody said something that we all agreed to do - but later on was "denied" by the person who said it - and we got in trouble because of that. I believe you would all agree that the situation could've come out differently had we documented the situation properly.

Managing Projects is all about managing change. Change can only be managed if you know what are the things that are changing. We can only know what things are changing if we document them. The best avenue to document the changes in a project is via the MoM - hence its significance.

Lastly, as my old boss told me... "Doing the Meetings Minutes gives you the privilege of documenting YOUR version of the truth."

...now isn't that something worth documenting?