Managing project teams
24 Communicate and document changes
Despite having a clear and precise idea of what your project will deliver, agreed to by all parties at the beginning of the project, it is inevitable that there will be changes. When this happens, you need to be certain that you take the opportunity to explain the new changes to everyone concerned.
Communicating to stakeholders needs a different set of skills compared with extracting information from them.
D O T - C O M T E L E C O M S ( P A R T 2 )
Liz Kirby’s project to bring intranet sites from four corners of the world into one consolidated system suffered from another problem: the scope was not written down.
‘It was difficult to keep a grasp of the scope, as it kept growing’ she says.
‘If the business were prepared to throw money at a problem, the scope just expanded to include the problem. We had written a terms of reference document and thought there was a common vision, but everyone still had different interpretations of what was supposed to happen.’
This inconsistency in the scope affected the project communications. It was hard to make it clear to the end users what the ‘launch’ of the new intranet site actually meant. The inconsistency also affected the way in which IT and the intranet teams around the world interpreted their parts in the project.
Communications issues came to a head eight months into the project, when Kirby realized that she had to act to ensure everyone had the same message.
She sent out members of her project team to visit regional offices around the world. She went out to Japan and spent a few weeks with the intranet team there to clarify exactly what the project would deliver and what she needed them to do.
As well as validating the project progress, this approach had some other spin-off benefits. ‘With a clear scope, you can trust people to go off and do what needs to be done without having to monitor the detail,’ Kirby says. As her project team was only 15 people, it was essential that she could trust the local teams. ‘It was also easier to resolve conflicts later on as we had built up relationships with the people involved around the world. And as they had not worked on anything like this before, it was a useful learning experience for the team. They can take that with them on to future projects,’ she adds.
‘It was difficult to manage the in-project communications over the two-and
a-half-year project because of the scope changes,’ Kirby says, ‘but harder to manage the messages to people outside the project. If the messages change, you just don’t look credible, and that doesn’t help anyone.’
Communicate and document changes
Communication during any project is important, but when elements of the project are changing on an apparently random but regular basis, it becomes critical to get across the right message in the right way. Goodman and Truss studied two major change initiatives – one at a company undergoing signific
ant restructuring and the other at a company moving offices. Very few man
agers or employees felt that the communication around these projects was adequate. Goodman and Truss present a ‘best approach’ model developed from their academic research as well as the experiences at the two organ
izations they studied.46 This model, the change communication wheel, is shown in Figure 24.1. Although it was designed to help plan communication strategies about change programmes as a whole, i.e. to a very wide audience, it is also relevant to in-project communications and the communications to your project team.
The change communication wheel, adpated from Goodman, J. and Truss, C. (2004). The medium and the message: communication effectively during a major change initiative.
Journal of Change Management, 4:217, No. 28.
Figure 24.1 The change communication wheel
The model illustrates the four elements of communication where a decision is required from the project manager:
• What is the message?
• How will we present it?
Project Management in the Real World
• How will people hear about it?
• What is our strategic approach?
The correct response to each of these questions depends on four external factors:
• Organizational context: your decisions will depend upon the situation within your organization, as what would work in one company may be disastrous in another.
• Purpose of communication: your responses will depend on the stage you are at in the project, as the aim of your communications will differ as the project progresses and the audience reacts to previous messages.
• Change project characteristics: different strategies and decisions are required for different types of project. What would be suitable for the communication of a new bonus scheme would not be relevant for an office closure.
• Employee response: consider how you want employees to respond and also how you will find out how they have actually responded.
This means building a feedback mechanism into your communication strategy.
All these elements must be taken into account when designing your approach to communication and considering how you will get across the message about changes. The response to your communication is especially import
ant when the message is that something within the project has changed, for example part of the scope. If this change has an impact on the work your project team needs to do, then you must be confident that they understand fully the new status quo. Eddie Obeng, in his book Perfect Projects, writes:47
Imagine you say to someone ‘Do you understand?’ – what answer are you almost inevitably bound to get? If they understand, they will reply ‘Yes’. If they don’t understand, but they don’t know that they don’t understand, they will say ‘Yes’. If they don’t understand but are too embarrassed to say so, they will still say ‘Yes’! In some cultures, the only acceptable answer anyway is ‘Yes’
. . . So what question should you ask? One of a select group. Ask instead, ‘What are the implications for you? What are you going to do as a result of what I’ve just said? How will this affect you next?
This approach gives you the confidence that they have understood and taken on board the change. It has the added advantage of offering you the oppor
tunity to correct any misunderstanding at this point and not three weeks later when they deliver something completely different to what you were expecting.
Communicate and document changes
H I N T
When sending emails, use a descriptive subject line, not ‘Janu
ary Project Report’ or ‘Re: Your Question’. Even if the recipient does not have time to open the email and properly digest the contents, they can at least get an impression of the situation from subject lines such as ‘Project Alpha delayed by two weeks’
or ‘Project Beta passed audit’.
There is the additional factor of maintaining credibility when you have changes to scope or other elements within the lifecycle of the project. Trust is an important factor here, and when your project team is split over multiple locations, even within the same building, maintaining a level of trust within the team will allow you to maintain the project’s credibility. It is far easier to write ‘build trust within the team’ than it is to explain how to start doing this, as trust is something that develops over time. Honesty and predictability – doing what you said you would when you said you would and behaving in a way your colleagues would expect – are two factors that will provide a starting point for you to work out what trust means for your team.48
Finally, avoid a one-size-fits-all approach to communicating change. Your project team will need a different level of detail to your sponsor. Equally, those affected by the change will need a different message to the one you give your boss – not different factually, as inconsistent messages will damage your project’s credibility, but presented differently and with a different amount of detail. Make the time to give the detailed version to anyone who asks, but tailor your communication to suit the needs of your audience.
G O L D E N R U L E S
Projects change the status quo, and projects themselves change as they progress. Effective communication is essential at all points through the project lifecycle in order to ensure under
standing and maintain credibility.