A good project manager must be a good communicator

The project manager will be working with three different stakeholders: the customer, the development team and his managers. Each group requires nearly constant communication. But each group has a diverse set of interests and priorities as well as different levels of technical knowledge.

Surely it is true that all three groups have an interest in meeting all three of the project goals of specification, schedule and budget. But each group would prioritize those three goals somewhat differently.

If the customer is paying for the solution on a Time and Materials basis, cost will be the highest priority. But in my own experience, most of the time, the customer is offered a fixed cost estimate. In those cases, the customer understandably loses much of their interest in managing the cost. Instead they focus on the technical features (which I call the “spec”) and the schedule. The importance of those two things is relatively equivalent to most customers, but of those two things, I believe the schedule is often the higher priority.

First of all, often the customer representative who you are communicating with is another project manager. That person is responsible for the same things that the vendor’s project manager is responsible for: spec, schedule and budget. Therefore the customer’s own project manager is making commitments to his or her own managers and other stakeholders that are based on the commitments that you are making. The most visible of those commitments is the schedule.

That’s because changes to the schedule will cost the customer money. They may have to get their technical staff to plan for some infrastructure changes in order to implement the solution and they have to make the users of the new solution available for training. Often that means changing the hours that those users can support production with the older system. Sometimes it even means completely shutting down production with the older solution. Such things require notification and planning. Delays cause extra expenses.

So while the customer surely wants the solution to work with all of the agreed upon features, it is often the case that the customer will delay the inclusion of some features, particularly if the missing features are not key features for the application, as long as the solution can begin to be used when scheduled.

The second stakeholder is the technical team. Their main concern is most often meeting the technical specification. Their job is primarily to make it work. Moreover, that’s what they enjoy doing. Budget and schedule – while surely important and the programmers understand that – are secondary to them. They may actually try to provide more than the customer needs or even wants as long as the challenge of providing those features is interesting to them. (By the way, this is one of the reasons that it is good for the project manager to have a technical background. It is easier for a technical project manager to recognize when the programmers are adding things into the development that really aren’t needed. Note that not all features that programmers add are obvious to the user.)

The final stakeholder is the project manager’s management. The technical specs are the least important feature to them, though the managers understand the need to meet the specs. Instead their primary interest in that regard is whether or not the customer will accept the solution. Schedule is slightly more important. A delayed schedule means delaying the movement of the members of the technical staff working on this project over to another project.

But their main concern, in my own experience, is nearly always cost. Which makes complete sense, of course. After all, if you are not making money on your projects you can’t stay in business very long.

So the project manager must effectively communicate with all of these stakeholders, each of which are emphasizing different aspects of the project. But the forms of communication are different.

The overriding and most important document is the SRS. It has to be written in a way that it can be understood by the customer as well as the development team. That is a difficult but achievable task.

Customers also want to have periodic status updates. These must be based on input from the development team. On large projects weekly conference calls are the most effective way of doing this. Individual developers can participate, but as long as the project manager is able to understand the status, their participation is not necessary.

On smaller as well as larger projects, I recommend keeping an issues list. Any issues that the customer raises should be included. Issues raised by others, particularly the development staff, don’t necessarily need to be on the list that is shared with the customer. That is not to imply that you should keep secrets from the customer. Instead it means that some things raised by the development staff may be more technical than the customer has any interest in.

This issues list that you review with the customer should have the following characteristics:

1. An issue number. This allows easy reference to each specific issue.
2. A short name for each issue. This is another way to reference each issue, which is another way to make those issues easier to remember. (The customer may remember what “issue number 24” is, but they are more likely to remember a name like “Long search times”.)
3. The date that the issue was added to the list.
4. The person who raised the issue.
5. A longer description of the issue.
6. The person who is assigned to resolve the issue. Often this is the project manager. If the issue reflects a problem with some portion of the code, the issue may be assigned to the programmer who wrote that section of code.
7. A history of what has happened on this issue. This narrative will be added to over time and can become quite long. If attempts are made to resolve the issue which are unsuccessful, that historical information should be tracked as well. It is best that the person assigned to resolve the issue update this section of the issues list. However the project manager can do it as well.
8. The date that the issue was closed (if it is closed). Note that if the customer is involved, then the customer must agree that the issue has been closed. A date in this column means that the issue has been closed and need not be discussed when reviewing issues.

When communicating with the customer, it is important to do so in ways other than strictly through emails and other written mechanisms. Surely email messages have their place, particularly when exchanging electronic documents. But oral communications help immensely when creating a relationship with a customer.

That relationship is very important.

Communicating with the software development team is more a matter of listening than anything else. You should always remember that you are dealing with a group of people who tend to be very introverted. One-on-one communication often works best.

However you do it, you need to sense frustration, conflict but also be able to follow the progress of the project. If the team is going in non-productive directions (generally when they are trying to implement new state-of-the-art techniques that may be more than the customer needs) you need to be able to understand and step in. It is good to have periodic project status and schedule review meetings (generally weekly), but it is also a good idea to meet with at least the key members of the project team informally more often. I generally try to spend at least five minutes with each key team member every day.

The amount of communication that you have to do with your managers depends on the importance of the project, the stage in the project’s development that you are at and, in some cases, the amount of trouble that the project may be in.

Early in most projects, particularly when you are developing the requirements for the project, your managers may not show much interest. They will have an interest in the schedule and cost of the project, but the technical requirements of custom software projects are of much less interest to them. As you begin the implementation of such projects, however, if the project is important the level of interest of your managers will rise significantly over time.

On very important projects, your management is going to want to be included on project status reviews. They will probably wish to participate in the status reviews done with the customer. Certainly you should expect to update them on project status at least once a week.

If everything on the project is going well, the level of interest of your managers in the project will not exceed such weekly meetings. That is, of course, another reason why early in a project the level of interest of your managers will be relatively minor.

But if the project does start to fall behind on schedule or budget (and less importantly on spec) the level of the managers to whom you will have to report will increase. I’ve always considered it to be somewhat ironic that important projects that are in a bit of trouble require more and more reporting which effectively helps to remove the people who can solve the problems from operating in that role.