The Tools of Communication - Part 3 - The Status Report

There is no other communication tool that management likes better than the Status Report. It is a two-page view of the status of the project. It is very clear and unambiguous in its communication; the project is green, yellow, or red. There is no confusion in that message. What is sometimes confusing is the explanation of a yellow or red status. Below, I will discuss how to make the Status Report the most understood report in a project.

 The Status Report

The Status Report, sometimes referred to as the “Red, Amber, or Green (RAG)” report, is the most common report on a project. In one or two pages (no more than two), this report should provide the project team and senior management the entire picture of where the project stands. However, its brevity is as important as the message that is conveyed. In addition, one of the most important rules in project management comes into play here: no surprises.

If the project is green, or on track, the message should be short and to the point, summarizing what will happen next and which risks will be closely watched in the upcoming period. This is the easiest communication a Project Manager (PM) has to deliver.

If the report is amber or yellow, then the report may be two pages. This report must elaborate why the project is yellow and what will be done to bring the project back into green status. This is where the PM should be specific on what is needed from senior management, the project sponsor and the PM’s Manager (the PM would have discussed this with them prior to the publishing of this report). Most likely, a change order will be needed. This must be presented to the Change Review Board, of which senior management would run or be a participant of.

If the report is red, the PM must communicate critical information to senior management and the project sponsor. The PM would have already warned the project sponsor, senior management, and of course his manager (the PMO and PMO Lead), but the report must detail:

·         The specific problem

·         The solution to the problem

·         How much this solution will cost in time, resources, and scope

After the problem is corrected, there should be a discussion regarding why this problem happened. Questions to ask include:

·         Was the problem flagged as yellow first?

·         If it was, why couldn’t it be resolved then?

·         If it wasn’t flagged as yellow, why did this problem “creep” up as red?

·         Who was responsible for this task(s) that became red?

·         Does this person (for example, an overwhelmed developer) need help, or did the customer miss deliverables they were responsible for?

The problem must be studied separate from the project work and be resolved. If the PM was “blind-sided” by this problem, then he or she must resolve the communication breakdown immediately.

Next

As I have mentioned in my last blog, I look forward to any and all feedback on this article. I ask you for feedback because in my next blog I discuss the remaining documents that are common during a project: meeting minutes, the project risk document, the communication and contact list, the project schedule, and the vacation schedule.

As we continue in these discussions, you can provide your opinion on the specific article or section within the article. I will respond to you via email Benny A. Recine and possibly consider it a topic for another blog.