Refactor Your PMP: Communications Management

As promised… next up we’re talking about Communications Management.

According to PMI, Project Communications Management employs the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. This knowledge area provides the critical links between people and information that are necessary for successful project communications.

There is a neat little book by Andy Crowe called “Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not”. This book surveyed over 5000 project managers to find out what the best project managers are doing differently. One of Andy’s conclusions is that top project managers spend significantly more time communicating than their less successful brethren.

In some cases these top project managers spent up to 90% of their time communicating in one form or another. I have to say, that is certainly consistent with my personal experience. If something is going wrong on one of my projects, it is usually because people are not talking to each other.

But maybe I am taking a naïve view of what it means to communicate on a project? It seems to me that the PMI definition of Communications Management is a little broader than just making sure the team is talking to each other. Communications management deals with documents and plans and stakeholders. Communications management is really about managing the flow of information.

Since it’s common knowledge that Agile teams don’t do documents, I am guessing we have some work ahead of us to reconciling these points of view.

Okay… I was kidding with the Agile documentation comment. That said, there is clearly a difference in how these two project management perspectives treat the issue of documentation, reporting, and even interpersonal communication.

Both PMI and Agile have quite a bit to say about how to manage project communications so let’s get started.

Communications Planning

PMI Definition: Determining the information and communication needs of the projects stakeholders

When Agile teams talk about communications, they are usually talking about communications within the team. Agile puts a great deal of emphasis on the free flow of information between team members, between team members and the product owner, and even between the team and the direct customer. In some ways, the Agile community has really abstracted the entire stakeholder community behind the role of Product Owner.

Communication between team members, and between the team and its customers, is essential but it is not the only component of communication that must be planned. Sometimes there are other stakeholders that we must take into consideration.

At the team level, we usually deal with team member communication through collocation, whiteboards, wikis, and other rich and collaborative workspaces. Agile teams trade a great deal of written documentation for these more osmotic forms of information exchange. On a small team with a single customer, it might be sufficient to suggest that customers get all the information they need from attending planning meetings, daily stand-ups, and iteration reviews.

When there is more than one stakeholder, or possibly a hierarchy of stakeholders , sometimes it is not sufficient to suggest that these stakeholders come down to the team room and check out the team’s progress on the Kanban board. Sometimes we need to do some roll-up reporting across a portfolio of projects or even programs. Sometimes we need to report status at a much higher level of abstraction for a more senior audience.

The key to planning communications on an Agile project is to follow the principle of simplicity. Don’t write documentation for the sake of documentation. Find out what your stakeholders really need and provide it as quickly and as simply as possible. Make use of natural information sources that the team is already producing (task boards, burndown charts, architectural representations) and create documentation that enables your business to make decisions.

Keep things light, go for face to face whenever possible, and when your stakeholders require more; make things as simple, clear, and accurate as possible.

Information Distribution

PMI Definition: Making needed information available to project stakeholders in a timely manner

At the team level, information distribution focuses on those rich channels of communication I mentioned in the last section. Agile teams keep their status up to date using large, visible information radiators that everyone in the team room has access to and can update themselves. These repositories of information are there for the team to know where it is at all times and so they can manage their work. The side effect of these radiators for the Project Manager is that you have instant access to real time information about the health of the project, release, or iteration.

Often, design and architecture will be worked out on whiteboards and then minimally documented on a Wiki or Sharepoint so they can be easily changed as we learn more about the evolving system. Agile teams lean toward lightweight artifacts and central, universally accessible document repositories. Agile teams recognize that the only truly accurate representation of the product is the code itself ; therefore documentation is kept light and at a pretty high level.

Sometimes a customer has a need for more detailed documentation to manage an external dependency or possibly an audit requirement. In these cases, that increased level of documentation is built into the estimate for the feature. Documentation is not free and it will slow down the creation of working software.

The key once again is to figure out what is the minimum amount of documentation needed to satisfy the requirement. Document systems at the highest level of abstraction you can get away with. Make sure you understand the information needs of the external stakeholder, make sure that work is represented in the backlog, and that it is prioritized to meet the needs of the organization.

Use the same collaborative techniques you would use to build features to create the documentation required by the business.

Performance Reporting

PMI Definition: Collecting and distributing performance information. This includes status reporting, progress measurement, and forecasting

Okay… so we’ve already talked about things like burndown charts and Kanban boards. These are tools that a team will use to organically manage their work and make sure they are on track. As an Agile project manager is your responsibility to help the team and encourage that these tools are kept up to date. For the most part, these are the only tools you will need to understand the health of your project, and you largely get them for free.

Performance on Agile projects is pretty simple. You know how big your backlog is and you know how much you are able to complete each iteration. Based on these two variables you are able to predict how many features you will be able to complete before the end of the project, release, or iteration. I personally like to keep a high level project roadmap that helps me understand where the project is expected to be at certain points as it progresses to completion. This is also useful for managing external dependencies.

These simple tools help you understand what progress you are making against expectations and if you’ll need to extend the release, adjust scope, or request additional funding. Since you are an agile team, you’ll more than likely be communicating how early you’ll be, how much more you’ll be able to do, and how much more value you’ve delivered to the organization.

Either way, you have a tremendous amount of information at your disposal to communicate project to the project stakeholders. Think EVM based on delivery of working product.

Manage Stakeholders

PMI Definition: Managing communications to satisfy the requirements and resolve issues with project stakeholders.

Managing stakeholders is really about managing the issues that come up during the life of the project. A significant benefit of Agile is that nothing is hidden. This level of visibility gives the project manager the information they need to resolve problems and remove impediments.

Issues can arise during iteration planning, execution, closedown, or just in the course of day to day work. Just like on any project, these need to get tracked and dealt with as soon as possible. Issues are reviewed during the daily stand-up meetings and retrospectives.

There are always going to be some issues that cannot be dealt with by the team. I typically hold a weekly or bi-weekly meeting with senior stakeholders where they get a distillation of significant impediments and what I need them to do to help me resolve the issue.

It is my opinion that stakeholders need to be managed and issues resolved no matter what your software development methodology.

I think that does it for this installment. That was much longer than I had expected. I figured communications management would be one of the easier topics to discuss. Maybe I just need to go home for the day.

Let see… next up… Quality Management.