Effective status reporting for dispersed teams

Project managers who are involved with large teams working in multiple offices--or even countries--need to take a different approach to status reporting. Developing a shared communication strategy can narrow the communications gap.

The nimble project manager considers every project unique and tailors the approach and solutions to fit the project.

I once managed a project that required developing an issue management system for a client. Much to my surprise, the dev team I was working with asked if they could adopt the system once we were done. The team had been recording all their open and closed issues in their spec documents, but the system was cumbersome and inadequate. What the team really wanted was a way to open a discussion, thrash it around among the team members until the problem was solved, and then close it out. We ended up building a threaded discussion module where each discussion could be formally opened and closed. The benefits of this system were so many that we lost count. The discussions were visible to our development team in the UK and were asynchronous, so the eight-hour time difference didn’t matter. Everyone’s opinions were duly recorded for posterity, and the most important aspect of this tool was that we eliminated the need to reopen decisions because objections had already been addressed.

This project demonstrated how nimble project managers should tailor the approach to fit the project. This dispersed team required a different set of tools to facilitate shared communication than would be required by a smaller team. (See part one of this series: “The nimble project manager’s approach to status reporting.”) The team was also unique in that they were very familiar with the technology involved and enjoyed significant team interaction. But knowing the strengths and weaknesses of your team is key to developing a communication plan that works.

Peter Senge, in his book The Fifth Discipline, writes that the only way to deal with many of the complex problems organizations (or projects) face today is by promoting a team environment where many minds can focus on the same challenge and then resolve the problem by sharing and building on individual insights. Senge calls this process “team learning”; the nimble project manager simply calls it “getting the job done as a team.”

One way to promote team learning is to offer as many opportunities as possible for the team to share their issues, concerns, and solutions. On smaller projects involving smaller teams, this dynamic happens naturally through coffee room chats or when one member of the team drops by the desk of another seeking help solving a problem. This type of team learning is also a key component of extreme programming (XP) in the concept of paired programming and the design of the XP project work areas. The only negative with this sharing strategy is that it tends to be limited only to the few people directly involved in resolving the problem. Personal conversations are not shared unless there’s some other mechanism of transmission.

The “best practice” instructions we got with our generic “status report tool” tell us this is one of the problems a written status report is designed to solve—the team member can record the learning, send it to the PM, and then the PM can disseminate it to the team if the ideas are judged worthy of sharing.

Facilitating bidirectional communication for problem resolution
The nimble project manager approaches this situation very differently. The first fundamental difference is that the nimble project manager never wants to control or even filter communication within the team. Back in the days before e-mail, Web sites, and threaded discussion lists, bidirectional team communication was promoted by creating opportunities for both formal and personal sharing (e.g., meetings with food) or by resorting to a more formal method, such as creating a written document that is mailed to the team. Today, technology lets a PM share knowledge and questions in real time, and the entire team can learn from the experiences of a few.

The nimble project manager grasps this technological advantage by understanding each project team and developing processes that work for that team. If that sounds like a lot of work, it really isn’t.

Bidirectional team communications can be supported by:
  • Telephones
  • E-mail
  • A kick-off meeting with the whole team present so everyone can meet
  • A team Web page that gives some personal background on each team member if a face-to-face introduction isn’t possible
  • Topic-specific threaded discussions
  • Weekly staff meetings
  • A gathering site that includes beverages or recreation
  • Permission

If you’re scratching your head wondering what “permission” means, let me elaborate. Most people try to follow the rules and behave in a socially acceptable manner. In a culture that enforces the principle that information needs to go up the food chain before it is disseminated, people tend to share ideas and solutions only among their immediate group.

In this situation, problem solving and team learning become informal and may exist below management radar. The nimble project manager communicates that he or she trusts the team implicitly to find problems, solve them, and then share both these problems and solutions among themselves. The nimble PM knows that the PM role doesn’t include being the keeper of knowledge or the dispenser of wisdom and that the best thing that they can do—90 percent of the time—is to get out of the way of the team and let them tackle the problems and create the solutions that only they can create.

By facilitating good bidirectional team communication, some of the urgency behind collecting task status goes away. After all, if the team can solve most of the problems by working them out themselves, communicating that everything is on track is a fairly easy task.

What’s next?
In part three of this series, we’ll review how to ensure that sponsors and customers are getting the status information that they require.

Editor's Picks