Mastering The Communications Game

Telephone tag is a popular game played at children’s birthday parties. The first child whispers a phrase to the second child, who whispers it to the third, and so on. The last child says the phrase out loud, and more often than not the audience hears some funny, fractured version of the original. A similar game is often played in business in a much different context: IT projects – and the results can be anything but hilarious.

CIOs adept at delivering successful IT projects understand the consequences of the game. They know that during high-profile projects there are no casual communications. Every presentation, status report, e-mail, and voice message generated by the project is analysed, interpreted, and picked over by a variety of stakeholders. Some members of the audience, who have a keen interest in the project, even watch and interpret the body language of the team. Some stakeholders have noble intentions and a genuine need to understand how the project is doing. Other stakeholders may have less noble intentions.

Knowing how messages can be distorted and misinterpreted, the CIO must make sure that the project team understands the need to carefully plan all project communications. Towards that end, the CIO must make certain that the IT project team – and in particular the project manager – has the knowledge and the skills to properly handle project communications.

We recommend, therefore, that CIOs read this article and then pass it on to their project managers. It identifies opportunities and strategies related to managing project communications.

Communications To Stakeholders

The project culture should encourage explicit and formal communications to stakeholders. The time to establish this culture is early in the project. Once the project team adopts a certain approach it is difficult to change. Project messages should include emphatic statements that contain words such as “must” and “will”. These are effective tools that deliver clear messages.

In the project-savvy organization, stakeholders understand the role of the project charter; references to that document get the attention of the audience. The project manager should seize any opportunity to quote the business objectives published in the project charter; these important project references lend weight to any project communication.

A formal approach to communications can be difficult if the project manager has prior peer-to-peer relationships with team members; however the manager must overcome any reluctance in this area. Careful choice of words can help, especially if the team is not used to a formal approach. The manager should make it clear that the formality is part of the project-management discipline and not a personal style or whim. For example, it is better to say “According to our project methodology, we must…”, than to say “I think that we must…”.

One of the most important aspects of communications requiring the manager’s attention is the status report. It must be made clear to all stakeholders early in the project that project status is to be published by the manager, using the tools documented in the project’s communication strategy. Members of the team should not be solicited for ad-hoc status reports; any such request should be directed to the manager. Following this procedure will ensure consistent delivery of status reports, reduce mixed messages, and allow team members to focus on their tasks.

The Power Of Positive Thinking

Every project is challenged by negative thoughts, emotions, and perceptions. The manager must help the team to think positively. A balanced response to project events is required, lest the audience perceive that the manager is viewing project status through rose-coloured glasses. The manager must recognize and respond to issues and problems, but must not miss any opportunity to recognize and respond to things that are done right.

The manager must especially encourage team members to present a positive and united front when meeting with clients and other stake-holders. Messengers of gloom and doom are not welcome on the project journey.

Perhaps it comes down to the question: “Is the glass half full or half empty?” Successful project managers believe that the project glass is half full, and demonstrate that at every opportunity.

Managing Praise

Praise can be an effective motivational tool, but it must be used wisely. Used too liberally, it loses meaning. Used too sparingly, team members may think that their efforts are unnoticed.

The manager must be able to distinguish the exceptional contributions from the ordinary, and deliver praise when it is truly deserved. It is not necessary to wait for major project milestones before giving a pat on the back. There are many other opportunities, such as an excellent presentation to the client, an excellent status meeting that includes detailed and meaningful task status, or the elimination of a defect.

The manager should encourage other stakeholders to manage praise. The project sponsor in particular can be a valuable ally. An awareness of the business objectives allows the sponsor to deliver praise in the context of the team’s contribution to the business.

Take My Project…Please!

Humour is a necessary ingredient in the project mix. Circumstances, context, and audience dictate the appropriate level of humour. When meeting with clients and other external stakeholders, a little modest humour (think Bob Newhart) will send two messages to the external audience: the team has good chemistry, and the team is serious about the project objectives.

The regular status meeting is an excellent team-building opportunity, and when the project team meets internally, the level of humour can be raised a notch. A good laugh helps bond team members, especially when they are working together for the first time. But it’s important not to let things go too far. If the humour starts slipping into silliness, you definitely have to rein things in, especially during status meetings. Good times to inject humour into a status meeting are at the top of the agenda, in between individual status reports, and during wrap-up. The manager must ensure that the team understands the importance of every member’s status report. Overall, the status meeting needs to be a serious forum.

Gallows humour has no place on IT project teams. Wisecracks about such things as the status of the project, the probability of success, and the team’s relationship with the client should be strongly discouraged. Remember that what goes on during internal status meetings often becomes public knowledge.

Touting The Tools

Experienced project managers are aware of industry best practices. They know what tools work and what tools don’t – and they are passionate about the ones that work. Instinctively, they want to tell the team what tools will be used, and explain them in great detail. This is appropriate in that it is important that the team understand the rationale for the use of the tools. But preaching about the virtues of the tools should be avoided, for it can lead to the project manager being viewed as up on his or her high horse, a perception that can be very harmful, especially at the beginning of the project.

A better approach to the tools involves dividing the best practices into two categories: mandatory and discretionary. The manager presents all of the possible tools and discusses the pros and cons of each, using success stories to explain their benefits. If there is resistance, the manager should consider allowing the team to discard one or two of the discretionary tools. The objective is to allow the team to help build the infrastructure of the project, which leads to a sense of ownership. As well, with this approach the team is not likely to feel that it has been bullied.

If the team attempts to reject the mandatory tools then the time will have come to recognize that the manager’s leadership responsibilities are inviolate. The manager will have to take charge and insist on the tools’ use. In other words, sometimes you can’t avoid being a bully!

Position of Strength

The manager must consider that the team has probably had less project-management training than he or she has. Some team members might prefer to work in a less formal environment than the one needed for the project to succeed. Unfortunately, less formality can lead to less accountability. Like the warm air leaking out of every crack and hole in your house on a cold winter’s day, formality and discipline will seek any opportunity to leak out of the project.

Therefore, project managers must be in a position of strength. They must conduct themselves at all times in a manner that communicates the message: “I am in charge.” Fortunately, this approach satisfies the needs of almost all other stakeholders: they want someone else to be on the hook for the project.

The project manager negotiates every day. Typical topics include human resources, technical resources, project scope, and project constraints. The manager must plan each negotiation carefully so that the result does not jeopardize his or her position of strength.

For each negotiation the manager should consider the attributes, needs, and objectives of the parties involved, and the forum for the negotiation. Where a win for the project is certain, a broad forum is appropriate. Where the converse is true; a narrower forum is recommended.

The manager will not win every negotiation. It is important to recognize which negotiations must be won and which can be conceded graciously. The manager must approach each negotiation with two outcomes in mind: the ideal result and the minimum result acceptable to the project.

Negotiations with team members around task assignments are best conducted in private and not during status meetings. Some team members will be reluctant to assume ownership of tasks. The manager may be tempted to use the status meeting as a forum for this type of negotiation. But remember, one way to generate a perception of weakness is to conduct a protracted task assignment dialogue with a reluctant team member in front of other team members.

Managing The Domino Effect

The project manager must manage the domino effect that evolves out of the pressure to deliver the project. Very little can be done about the pressure that flows down from management stakeholders. And the manager cannot be the last one to feel the heat – it must be passed down to the team.

The manager must, however, ensure that the domino effect does not adversely affect peer-to-peer relationships on the team. Too much pressure flowing down to the team can result in strained relationships, especially in the area of task dependencies.

Signs that the domino effect is adversely affecting the project team are comments like “How can I start my task if he doesn’t deliver the spec?” or “They’re going to be upset if we don’t deliver.”

Signs that the effect is under control are comments like “What can I do to help you move that task along?” or “Can we fine tune that dependency?”

The Ghosts of Projects Past

Many IT projects are haunted by the ghosts of past failures. The only way to transform the mistakes of the past into present-day value is to learn from them and therefore avoid their repetition. Constructive input from members of those failed projects should be welcomed. But personal biases and strained relationships coming out of past projects need to be checked at the door and/or repaired.

Criticism of past projects should be discouraged. The focus must be on the current initiative. Current team members who were involved in the past projects may be sensitive. The manager should ensure that their feelings are respected.

The Critical First Month

The CIO should measure the project manager’s ability to manage communications. A good time for this evaluation is one month into the project. Two related measurement criteria are: the quality of the relationship with each stakeholder, and each stakeholder’s level of confidence in the project manager’s ability to deliver the project. Each stakeholder whose support is required to deliver the project should be rated on each of those two criteria. Evaluate the results and respond accordingly.

There is no magic threshold value that can be used to measure the probability of project success; however the results will identify opportunities to improve relationships. They will also indicate whether or not the project communications tag game is being won or lost.

Al Taylor is a veteran project manager and independent I.T. consultant. He can be reached