The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget (2nd Edition)

So far this chapter has shown why communications is important in project management and the problems faced in trying to communicate in projects. Now let's look at the answer, a systematic approach to project communications management. This section follows the PMBOK approach to project communications management, which is robust and effective. Communication is a broad and deep subject, and entire industries and entire lives are devoted to nothing but communication. A project manager can always learn more about communication, which is a fascinating, practical and valuable subject, but the purpose of a project manager is to manage a project. Communication skills are a means to that end, not an end in themselves. We have had to limit what could be said in this chapter. We have chosen a limit such that you will have a good toolset and pointers for further research into this subject. Table 10.4 shows the four processes in project communication management and how they are categorized within the process groups.

Communications planning

The aim of communications planning is to ensure that you communicate the right information to the right people at the right time. Without a plan your chances of doing this are slim. Planning includes finding out the following:

• Who wants communication about your project?

• Who needs it?

• In what format?

• What communication channels are available?

• What reports should you submit and when?

• Who is going to do the work of producing the reports and other communication material?

• What are the major communication risks and opportunities?

As well as the formal upwards-reporting channels you should use informal channels to keep people elsewhere in the company informed about progress particularly if it is good. When the time comes to roll out your hard work across the firm, you will be grateful for the extra supporters.

Figure 10.1 shows the inputs, tools and techniques and outputs in project management communications planning. The inputs are self-explanatory and need not be explained further, but one of the tools, communications requirements analysis, merits some discussion, and Table 10.5 is an example of it. See also Figure 10.2 later in this chapter, which lists the processes for information distribution. In planning communications you should understand the information distribution processes available to your project and plan accordingly.

The point of the chart shown in Table 10.5 is to ensure that the project communicates to everyone it needs to, in the right way, at the right time. The completed spreadsheet, or something like it, should be a section of the communication plan. It may be useful according to the needs of the particular project to use separate spreadsheets for each of the three sections that together make up the example in this table. Note that this table, or tables like it, are used both as tools for planning communication and as part of the output of planning. When using this tool, use it both to show what additional communication methods are needed in order to meet needs, and also to prune methods by identifying any that are redundant if the burden on the project team of reporting is becoming too great. Table 10.6 shows an alternative output.

When planning project communications, and also when executing them, all your efforts will be for nothing if you do not plan and act in a credible and trustworthy way. This may require much thought and effort, because of the tension between the need to keep some information confidential and the need to build and maintain trust. But if you understand your obligations and work with your sponsor, there should be no real conflicts here. Trust is very important in communication. The project manager and sponsor, and others involved in project communication, will be able to communicate much better if they are trusted. To be trusted you must seek out information actively, using questions which do not presuppose the answer. When information is made available the project manager must listen, and if it is provided in confidence then either accept it as such or make it clear before it is imparted that you cannot do so. It is easy to agree with all this in principle, but during the hectic lead-up to a project deadline, when communication is most important, it is easy to have a brief conversation without making the effort actually to listen to what is being said and to fail to recognize some of the tensions.

Project managers are the focal point of communications in the project. Good communication leads to efficient working, good morale, and project success. A project whose manager cannot communicate effectively is a high-risk one which again underlines the need for planning communications. Plan your communications with an eye on maintaining your team's morale.

Good communication involves more than speaking and writing: good management requires receiving information at least as much as transmitting. This too should be a planning factor.

Another factor in planning your communications is the complexity of possible communications channels and communications methods. In a small organization of a few people a purely internal project has simple communications, because everyone can know everything without much cost in time and effort being incurred. But in a large project in a large organization there may be far more possible communications channels and methods than are needed, so there is a choice. In mathematical terms this can be an NP-hard problem which in plain language means, roughly, don't bother trying to work out with a formula the optimum way to communicate, just use common sense to make a good guess and which channels to use and don't bog yourself down in trying to use too many. Each channel incurs cost to your project in planning and managing. Your sponsor can provide wisdom and guidance.

Information distribution

You've done the planning, now it's time to distribute the information that you want to communicate, and to get feedback. Figure 10.2 shows the inputs, tools and techniques and outputs of information distribution. Information distribution is the process of executing the communications management plan as the PMBOK definition here makes clear. Distribution is about executing the communication plan, and there is little to say here that has not been covered above in the section on communication planning, except for two things: first, to emphasize again the importance of how you communicate; and secondly, to say something about requested changes as the output of the information distribution process.

How you communicate further words on communication skills

If you or one of your team who needs to communicate as part of their project duties is weak in communication skills, then consider getting some training: it is a valuable skill and there is much good training available. You might also consider buying a cheap video camera and recording yourself communicating, perhaps not in real meetings but on your own, talking to the camera or with a friend in role-playing. Such an activity would have been prohibitively expensive a few years ago, but costs have fallen and for many people seeing themselves on video is an experience that transforms how they communicate.

Outputs information

The main output of the information distribution process is of course the information that you are communicating. This should be straightforward, as what should be communicated will have been worked out in the plan, although sometimes you will have to communicate painful news. The techniques and approach to doing that fall under the heading of communication techniques, but the boxed text says more about it.

(Note for those readers preparing for PMI exams: the information being communicated is not listed as an output of the information distribution process in the PMBOK. The omission is perhaps more understandable when one considers the section on performance reporting, which concerns much of the information that is to be distributed.)

Outputs requested changes

When you start executing the communication plan you will discover changes that need to be made to your communications plan, hence requested changes being the main output of the process in Figure 10.2. There will be two reasons to change the communication plan. First, there will be the changes necessary as a result of your plan not working quite as intended, for example the steering committee does not like some particular format. Then there will be changes where the plan was fine but something else changes, such as one of the organization's standard communication templates, or some stakeholder changes their mind about the frequency or format of how they like to receive communication. And of course when things have been running smoothly for a while people tend to want less communication than when surprises and problems have been arising.

Performance reporting

Figure 10.3 shows the inputs, processes and outputs of the performance reporting process as we have said before, treat the inputs as suggestions and ideas; don't try to find all inputs listed there for every project you run, or you will create a bureaucracy that will kill the project and probably drive you and your team insane. Focus on what matters. Performance is what matters to your stakeholders. You need to consider the following factors in performance reporting:

• What the stakeholder expects to hear about project progress.

• What the stakeholder wants to hear about it.

• What it is reasonable that they should hear, i.e. actual progress as against the schedule and scope.

• What you want them to understand.

• How to deal with the gaps in the above.

Finding out about and then reconciling all of these is a major task. The tools and techniques of performance reporting are there to make this task easier.

As Figure 10.3 says, time and cost reporting are of particular interest to the sponsor and other stakeholders. The usual way for project managers to track progress is through timesheets or an online equivalent. You should get timesheet information from all of your team at least once a week. However, some time reporting systems only record historical hours spent down to the project level rather than the task level. If necessary, therefore, you may wish to create a project-specific version that allows people to record time on individual tasks and also to give revised estimates of time to task completion, although be sensitive to the costs and possible political ramifications of doing this. On small projects, you can gather this information yourself as part of your regular tours of the project team, without having to use another form, but on large projects some degree of automation will be required.

The sponsor, the steering committee, the managers of other projects that are waiting for your resources, the various stakeholders, and of course the users, are all keen to know how things are going. They aren't likely to be interested in the details that occupy most of your time but they will all want to hear when the project is likely to finish and whether everything is under control. Some of these contacts will need to be informed on an as-needed basis, but as a general rule, reporting should follow standard formats. This saves time in producing them and gets the recipients used to the same format every time, which saves them time and enables them to focus on the actual message rather than the format.

The most significant reporting task for a project manager is the weekly or fortnightly report to the sponsor. Figure 10.4 gives an example of such a report in one page. The project status report for the Programme Office, where there is one, is almost as important. The project status report is an essential document, but since it contains summary information of what should already have been generated for internal project use, it should be simple to produce. Many sponsors are content to receive a copy of the weekly programme status report without any additional project progress note. It is good practice to send a weekly note to the sponsor. Sending regular routine notes will make you appear organized, and will mean that, if your project does run into trouble, it will not be the first time that the sponsor has heard about how the project is going. Through being reminded of the project the sponsor will be better placed to act as project ambassador in interactions with other senior staff. Take the opportunity to raise issues and concerns that do not fit into the project status report format and to ask for support in dealing with any organizational, political or resourcing problems that may be emerging.

The design of reports is worth thinking about most carefully. Remember that Gantt charts are good for showing time, PERT charts are good for showing dependencies, and milestone charts are often what senior managers want to see. But if someone senior wants to see dependencies by looking at a Gantt chart, it may be prudent not to argue with them. There are three sources of templates or models: your organization's standard templates, formats or styles preferred by the stakeholder in question, and other templates (such as the ones in this book). Avoid the latter if possible, because it is better to use something that your stakeholder recognizes or something that is a standard in your organization.

Manage stakeholders

Figure 10.5 shows the inputs, tools and techniques and outputs for this process, as per the PMBOK. This diagram is reasonably clear as far as it goes. Another way of looking at the process of managing stakeholders is by keeping stakeholders happy while also keeping the project realistic. There is a tension between these two aims. To keep that tension within manageable bounds, you need to raise issues with stakeholders and either get them to agree a change in scope against their interests, or get the parties to the project (you plus the sponsor plus other affected stakeholders) to agree to extend the scope of the project.

If communication is the most important skill in project management, then stakeholder management is the most important process. Of course you must have a minimum level of competence in actually managing projects, but assuming that, managing stakeholders is the most critical process for success in project management.

There are two parts to getting stakeholder management right. The first is planning, and you will have done this in the communication planning process, described above. The next step is how you engage with stakeholders. This comes down to communication skills, also described above, plus how things work in your organization. Your sponsor will probably be an expert at stakeholder management, but if not, or if they are short of time for you, make a special effort to work with the sponsor to get stakeholder management right.