The nimble project manager views a project and all of its parts as unique. When it comes to the key element of status reporting, nimble PMs find a solution that fits their audience.

We have discussed strategies for gathering status report information and outlined how to facilitate the sharing of that information within the team. This final installment in our series on status reporting offers effective ways in which a PM can provide status to stakeholders and sponsors.

Status reporting: The series

Part 1: “The nimble project manager’s approach to status reporting”
Part 2: “Effective status reporting for dispersed teams”

A nimble project manager must face the reality that PMs don’t get to make all the rules. Every organization demands compliance to one set of practices or another, and nimble project managers are smart enough to know when to, at least, make it look like they’re following the rules. So, when the project sponsor wants status in writing, once a week or once a month, PMs comply for the sake of form while, at the same time, determining what real communication needs must be met on top of the formal status report.

Agile development methods advocate having the customer representative as a fully participating member of the project team, which is a practice nimble project managers have adopted with great enthusiasm. In most cases, this day-to-day rubbing of shoulders eliminates the need for a formal weekly status report, since the people who require “real time” information are receiving it through direct participation. What this participation doesn’t eliminate is the need to communicate with the broader community of end users in cases where the project is going to affect a lot of people.

Stakeholder status information should focus on user issues
Communication to end users should always be focused on issues that impact them. Publishing or e-mailing a weekly status report, or even a monthly status report for longer projects, might be a waste of time if it doesn’t give the end users any meaningful information. The nimble PM also takes the time to consider whether this information should be available on a “push” or a “pull” basis.

The decision to use the push method of communication should always be based on the time sensitivity of the data and the fact that something in the communication requires either action or response from the person receiving it. Littering up an end user or stakeholder e-mail basket with chatter only compels the person to delete messages unread. If, on the other hand, the person knows that an e-mail from the project manager contains something that will have a direct impact in the near term, the person will most likely read it and act accordingly.

On one project, I sent out a biweekly letter to 80 site managers letting them know the status of our efforts to deploy a new cost-estimating package. The letter let them know which sites we had completed in the prior two weeks and included anything of interest we had learned that might affect their adoption of the software. I also included a two-page Excel schedule so that they knew when we would reach their site, tailoring the approach to suit the audience. I’ve been on some projects where a biweekly e-mail would have been considered spam and on others where more in-depth information would have been required.

If you employ a pull basis, the user decides when to access the information. An example is a Web page that reads, “We are currently working on this module, when it’s done and implemented (which will be in April 2003) you will be able to do the following things…” The nimble project manager knows that this type of communication is one of the most important tools in the toolbox, especially during a longer project, because it helps to keep the current system and the new system aligned. One of the reasons IT projects often end up cancelled prior to deployment is that the requirements have changed so significantly between the design of the new system and what the legacy system has been kludged to do in the interim. As a result, the new system is now more out of date than the legacy system. By communicating useful information to the broader community of end users, the nimble project manager knows that the chances of keeping both the legacy and the new system in alignment go up significantly because the functionality of the new system is much more visible to more people.

Targeting the sponsors
This leaves us with one last audience for our old “best practice” status report—our sponsors. And, as I said earlier, since they’re signing our paychecks, they can have anything they want. One approach nimble project managers might take to communicating with their sponsors is to meet with them at the beginning of the project and discuss what kind of communication options work best for them in their role as project overseers. The answers usually vary by whether or not they give a written status report to their boss, and by how much time they are planning to invest in the project themselves. The toolkit the nimble project manager uses includes:

  • Weekly e-mail with a quick summary of any issues and concerns and how they’re being handled.
  • Weekly one-on-one meeting with the sponsor.
  • A weekly status meeting between the project managers and the sponsor (seems to work well on high priority, geographically dispersed projects).
  • Formal phase gate or quarterly progress review meeting with sponsor and selected stakeholders.
  • An open-door policy (in addition to, or in lieu of, a formal one-on-one).
  • On-demand briefing sessions.
  • A formal written weekly, biweekly, or monthly status report.

A nimble project manager should always remember that the sponsor is usually facing personal or financial risk based on the outcome of the project. Hiding things, misrepresenting things to buy time, or generally not revealing the full extent of known issues is always a mistake. On the other hand, inundating the sponsor with excess detail can be just as bad. The goal of communicating status to a sponsor, in whatever form the PM and the sponsor agree on, is to ensure that timely and accurate information is available and structured in a manner that the sponsor can help as needed.

The nimble PM’s best practice
The original goal of the “best practice” status report was to ensure the timely transmission of information about what is happening on a project so that problems wouldn’t escalate and jeopardize a project’s budget or timeline.

The nimble PM works with the project team to establish the best way to get updates on task status, problems, and issues and is flexible on how the reports are delivered. The nimble project manager also makes sure that teams effectively communicate with each other. Finally, the nimble PM invests the team in preparing communication to sponsors and stakeholders that stays focused on the real issues and needs of each constituency and that helps keep the scope of the project in sync with the real requirements.

The nimble project manager knows that the true best practice isn’t filling out a weekly status report in an attempt to be compliant. The best practice is facilitating open and honest communication between all parties impacted by the project in whatever manner suits them the best.