by: Christopher R Goldsbury

Project status reporting can be, and often is, a gut-wrenching experience for a project manager.  The litany of pertinent, but tough questions from stakeholders, superiors, and key leaders may seem more like an inquisition than a level headed discussion about the state of the project and its future course.   Even in cases where the status is all green the project manager can face doubt, skepticism and pointed remarks from the audience.

So what causes this, and what can be done to remedy project status reporting so that it’s outcome is constructive?

Bad Status Reporting

Reporting the status of a project is a nuanced activity.  On the surface it would seem straightforward.  Just fill out a scorecard with the appropriate information and then give your stakeholders an overview and opinion of where the project is at and where it’s going.   But there are common mistakes with reporting status that lead the inexperienced project manager into trouble and result in a quick loss of confidence.  Here’s a short list:

1. The numbers are wrong.

This is a frequent problem.  Commonly, it’s caused by a PM misunderstanding how numbers are reported in an organization.  There are usually assumptions and unwritten organizational rules about systems, time periods, and data quality that require exploration and understanding.   The mistake can be as simple and harmless as assuming the time reporting system is accurate and up to date, but it’s necessary for the PM to ask questions around these numbers up front.  A PMO can usually help out with this by standardizing and educating the PM on organizational peculiarities.  Where a PMO is lacking find a trusted, experienced mentor.

2. There are never any issues/problems.  Project is always green.

A sharp stakeholder will see through this.  The less astute will glow over how ‘perfect’ the project is.  Frequently, the root cause of this problem is within the project manager.  Seeing a yellow or red status as a value judgement on his/her ability, the project manager avoids reporting reality and glosses over the truth.   The result of always reporting a green status and no issues?  Ironically, it conveys you don’t need a project manager.   The PM should report the truth and what he/she is doing about the truth to make it more in line with goals and objectives.  By centering a project team on reality, the plan is more likely to succeed.

3. Too little detail.

Another expression of fear from the project manager is the avoidance of providing detail.  Instead, the PM will put down some very basic, high level statements and ‘let the numbers speak for themselves’.   Usually, the PM doing this has been badly burned in the past with reporting status and rather than go through that experience again…they opt to leave it up to interpretation.  This is difficult to get over.  Trust is the main barrier, and it may represent a fundamental breakdown between the PM and his/her stakeholders.  Less common is that the PM sees reporting status as unimportant and puts very little effort into this activity.

4. Too many adjectives.

The opposite problem from #3 is a PM that is too flowery.  This project manager may use language that is more opinion than fact:

“The project is going very well.   Our development team has done a magnificent job at the first iteration work.  Kudos to Jim, John, Mary and Rashid!!!  There should be no problem completing this project as planned.”

While such statements may be motivational and show a positive attitude; they have no place in reporting status.  Project status isn’t about hopes, personal opinions not shaped  by facts, and team building.  It’s just an assessment of the current situation as represented by the facts, and the strategy the project manager intends to employ to align those facts with the project goals and objectives.  The florid wording of this PM’s status is hard for any stakeholder to immediately deride, but in time it will serve to undercut the PMs credibility.  As issues and problems inevitably arise, the question will be asked:  “Why didn’t he/she didn’t see this coming?”

5. Send as an attachment instead of a link.

Attachments should be avoided at a all costs.  If you made an error on the status, and you sent it as an attachment then you’ll need to resend it.  That means many copies of your status are now being sent around in email.  Inevitably, someone will make an assessment off an old, errored status report and then the confusion starts.  By keeping your status reports organized by date on a wiki, sharepoint or other CMS type system; you avoid the confusion of what is the latest, most correct report.

6. Assuming the scorecard speaks for itself ( no status meeting ).

Another common problem with reporting status is to just send out the scorecard without any meeting to discuss it further.  A project manager should never assume that everything he/she wrote down was clear.  Furthermore, the status meeting should be a discussion and analysis by all parties affected by the project.  Rather than a one-way expression of data and information it should be a collaborative juncture to thoroughly understand the project’s current state, expected future state, and how that plays out in a wider organizational context.

Summary

Good project status reporting leaves your stakeholders with few questions, or concerns irrespective of the color: red, yellow, or green.  The assessment you discuss should demonstrate your competence in understanding the nuances of managing projects.  A good status report will:

1. Clearly and in detail report the facts of the budget, schedule, scope, risks and issues.
2. Avoid opinionated language that isn’t rooted and backed up by the facts.
3. Communicate the implications of issues, and risks in terms of schedule, scope and budget.
4. Demonstrate that you understand the inter-relationship of project deliverables.
5. Map a strategy towards success by making tough decisions, and recommendations.

Christopher R Goldsbury is a software development manager and professional with 15 years experience in various flavored technologies as well as experience in production/operations management, project management, enterprise & software architecture, operational risk management, and human motivation. You can read his experiences and ideas at his blog or connect with him on LinkedIn or on Twitter by following @goldzee.

More by this author:

• That’s Great… But How Does Agile Benefit Our Shareholders?
• This Daily Standup is a Joke
• An Axiom of Project Success