What makes a project and a project manager successful? Most PMs would probably answer “delivering the project on time and on budget.” Accepting this assertion, how do you accomplish this goal? When I started managing projects 20 years ago, the answer was by stepping lightly through the minefield of problems and being flexible enough to handle anything “Murphy” threw at you, regardless of whether or not you had a clue about what you were doing. Today, things have theoretically improved to the point where we have best practices, such as the industry quality-standard CMM (Capability Maturity Model), and a professional organization that will certify that we have learned the “one true way” to manage a project.

The move toward quantification and documentation was laudable when it began. In the past, PMs succeeded or failed based on nothing more than innate talent. With the availability of training and methods, it became possible to expand the population of available PMs from those who were born with the talent to those who could learn the process. Unfortunately, from my perspective, we’ve gone from chaos to moribund control systems, in the virtual blink of an eye.

The secret weapon
In order to gently nudge the pendulum back toward the center, I’d like to offer, as a counterweight, the model of the nimble project manager and his or her well-stocked toolkit. In many ways, nimble project managers look just like any other PM. The primary difference is in their worldview. Nimble project managers know that every project is unique in some fashion, and that success is predicated on finding that uniqueness and working with it rather than against it. Nimble project managers also know that no plan survives engagement with reality and that, ultimately, it isn’t how well they stick to their plan, but how well they navigate through a changed terrain that determines their ability to deliver their project.

Ultimately, nimble project managers are like master craftsmen, who can look at a situation and know what “tool” to take out of their toolkit to accomplish the task at hand. They might have started out with only the tools best practices told them they could have, but over the years they’ve added a few and thrown out some others based on experience and expertise.

In this series of articles, I’d like to explore a tool or technique that conventional wisdom has begun touting as a one-size-fits-all approach and offer, as a counterpoint, the wider toolkit available to the nimble project manager.

Obtaining task level status
Opening our best practices toolkit, the first document we see is the obligatory status report. We’ve always been told that everyone should faithfully fill out the form so that we can sit in our offices, read the report and consolidate it to send on to our sponsors and stakeholders. In theory, at least, this process will result in the world’s being a better place and the project coming in on time.

Our nimble project manager knows differently. A conventional status report is a hierarchical tool designed to automate the communication process. Our nimble project manager knows that communication (to team members, sponsors, and stakeholders) is one of the single most important activities on the project and, as such, should be given a significant amount of mind share. The nimble PM understands intuitively that what we need is not only a way to collect and disseminate status, but also a broader understanding of what we need to communicate, when, and with whom.

So if we’re eliminating the straw man of a one-size-fits-all status report as a tool in the nimble project manager’s toolkit, what are we to replace it with? Since the nimble PM always looks for unique factors in every project, the answer is, of course, that it depends on the situation. With tongue firmly in cheek, I would like to contend that the first tool nimble PMs need is the uniqueness detector. This virtual tool will serve to remind us that when we approach our communication plan that we need to know where people are geographically, what their working styles are, and what their communication preferences are before we leap to an answer.

The first unique factor we’ll look at is the size of our team. One of the best ways to collect status is by walking around. With a team of less than 10 colocated staff (all reporting to the PM), this is a good place to start. The nimble PM begins by determining how the team feels about meetings and how they want to flag when they’re in the “zone” and shouldn’t be interrupted when he or she chooses to do their “MBWA” (otherwise known as “management by walking around”). The nimble PM also gives the less verbally inclined team members the alternative of giving status in e-mails. The basic rule of thumb is to get the team together at the beginning of the project and see how they want to handle things, with the caveat that small projects work best with a great deal of personal involvement from the PM.

Returning to our uniqueness detector, a nimble PM will always look for the opportunities particular to their current project. A case in point would be a project I managed early in my career, where we lost the mainframe for two hours every Wednesday between 11:00 and 1:00. The team decided that we’d do a weekly lunch in lieu of staff meetings. Also, since we were a small team and I spent so much time with everyone, we had absolutely no need for written status reports between ourselves.

On larger projects, the project manager, by definition, becomes less focused on the day-to-day product development activities and becomes more focused on the art of juggling balls (managing multiple teams, keeping the sponsor happy, keeping track of the cost of the project, politically defending your piece of the pie, etc.). If you’re thinking this is the situation that status reports were invented for, as an offline tool to keep you informed when you don’t have time to go see for yourself, then you’ve answered your own question—in a project, the PM never goes offline.

The value of conscious communication
So, the first thing nimble PMs will do to manage a larger project is to increase the amount of time they plan to spend in conscious communication with their team. In order to have the time to do this they’ll have to make sure that they’ve organized the team in such a manner that they personally haven’t become a choke point in their own process. Also since larger teams are most often geographically dispersed, nimble PMs will shift their MBWA to management by phoning around.

So what do nimble PMs get out of a verbal status report that they wouldn’t have gotten out of a written one? The simple answer is, lots. In my own experience, I’ve always scheduled at least an hour for these status calls. I want the time to chat—to listen for issues of stress or hidden worries that aren’t problems now but may be later. I can’t think of a time where these longer conversations didn’t cause me to make some changes either to the schedule or to the composition of the teams out in the field. I also learned from these conversations how to interpret the answers I was getting—that doom and gloom from one PM was no cause for concern and that good news and no problems from another was cause to send in the cavalry. I also learned that if I wanted the truth from a certain PM the only way I would get it was to call his number-two person and get her to give me the lowdown.

So, if phone calls work (with the occasional e-mail) instead of written status reports for your direct reports on larger teams, does that fulfill the communication requirements? After all, we now have task status and a reasonable update on risks and issues and, with very little trouble, we can write it up, pass it along and count ourselves finished, right? Unfortunately, as with most things on a project, task status is only the tip of the iceberg where communication is concerned.

Coming up
In part 2 of this article, we’ll discuss the relationship of the project manager and the extended team and review the type of communication that might be required there. We’ll also review the team’s bidirectional communication needs. In part 3, we’ll conclude by reviewing how to ensure that our sponsors and customers are getting the status information from us that they require.