Addressing the right audiences at the right time, with the right messages has often been a little more than lip service, so that an activity on a checklist can be ticked off by the Project Manager. All too often Change projects have failed not (just) because of the technical aspects, but because of the people aspects and, as previously mentioned in Requirements gathering, done properly a huge opportunity to make real improvements within the organisation is missed.
For far too long, traditional project communications has been seen as more a question of telling Management what you want them to hear and telling the staff what you THINK they want to hear. However, truly successful projects are notable by the absence of one-directional "reporting" strategies because everyone who needs to be is actively engaged, contributing and accountable and the traditional hierarchy and associated blame culture has been removed and replaced with people who know their role, accept their responsibilities and are motivated to work and to ensure the project succeeds, instead of trying to firewall themselves from blame for its failure.
Effective communication in a project is not a question of just progress reporting (although reporting is important), it is a question of collaboration and co-operation towards a shared vision of success, where people understand their role in the ultimate outcome and work as part of a team to achieve it. In a game of football, is it all the goal-keeper's fault for letting the ball go past him into the net, or do the other 10 players share the responsibility for letting the opposition get into a position to shoot at goal in the first place?
As mentioned in "Effective Communications at the start of a project", it is important to be clear about:
But the key thing here is that if you start building a communications plan AFTER you've already started the project, then it is a bit too late - the communications should have started in earnest before the formal project began.
This approach is important for many of reasons, but especially:
Planning
You will need to take critical personnel away from their desks for periods of time - so you must ensure that appropriate cover is arranged in advance and that key people are not on holiday. Likewise, that you don't completely break critical processes by removing numerous links from the chain simultaneously.
Timing
As with planning, you need to get this right - for instance, month ends are not a good time to engage Sales or Finance because they are trying to get stuff done and closed out. So trying to talk about payroll, when Finance is trying to do the payroll is a bad idea!
Justification
People impacted by Change need to know that their contribution is important and VALUED. If they don't understand why their input is important, or don't want to make the time to actively participate, and their boss doesn't get it either and doesn't reinforce these messages, these staff are worse than useless - and so is their boss!
Engagement
If change is being thrust upon me, I may well resist it (passively or even actively) because that is human nature. However, if I have helped to shape it and have actually helped to create the justification for it, then it is my change - I own a stake in it and it will help me do my job better. Then I will support it and will encourage others to do the same.
It is easy to think of Project Communications as an outbound, broadcast activity from the Project Management Office (PMO) to the "target audiences", instead of a two-way process. However, for a project to succeed during both the delivery phase and after handover (assuming the requirements gathering was done well!), the audience for Change should not simply be "communicated with", as in talked to, they need to FEEL heard and listened to for it to be effective.
Scheduling workshop sessions in the Requirements Gathering phase, including the documentation of Business Processes MUST ensure a balanced mix of people - you need to hear from grass roots staff and Managers and, most importantly, you need to explain the context and benefits of what you're trying to achieve. If they perceive this whole process as an "unwelcome interruption", rather than an opportunity to make things better, then you've explained it wrong and, more importantly, these poor communications will lead to resistance and obstructive behaviours!
In the lead up to a new system, before formal work even starts, people need to be engaged and to FEEL able to speak freely about what currently works well and what doesn't, without fear of being singled out as a trouble-maker, or a problem. So ensuring staff are there without their Managers and that you have staff who represent inter-connected parts of an overall process, who can discuss things openly may be a critical success factor. For instance, one process may work perfectly in isolation, but after the handover it may go wrong, causing errors that you never knew about . . .
How about communication during development, what should you tell them? "We're cutting code and we're on schedule" isn't going to inspire people or make them feel part of it.
OK, so, you're in the middle of building the system and it's half finished and you have the opportunity to show some key system screens to the team that will use it. Good idea or not? Some will argue that showing them the system in a "half-baked" state is a very bad idea.
But how about this - Most people can only visualise something they are already familiar with, so they can't visualise a new system, unless it looks just like the old one. If the team (or a few key people) see the system at this point and can provide input to clarify the stated requirements, to further improve it, then it will probably be a fast fix for the coders to tweak it at this stage. Whereas, do it right at the end will be a major piece of work, if it's even possible!
Yet how often does iterative showcasing happen in software development projects? This level of transparency and openness makes the users feel much more engaged and an important part of the process, which makes them more supportive and better ambassadors for the project with their colleagues. Usually, however, the "techies" don't trust the users and the users think the techies don't "get it" and there is a significant gap between them, which causes resentment and friction and a breakdown in communication.
Communication needs to be about talking openly and exchanging views and building team spirit, with a shared vision of what success feels like, and looks like. A blog that gives status updates is NOT communication!
Now compare this approach, of actively engaging users, with the classic scenario of a newsletter pinned to the staff noticeboard, which nobody ever stops to read because it is positioned in a busy corridor, or a blog that gets updated once a month on progress that is almost meaningless to anyone outside the project team.
Products like Yammer and other Social Media tools are becoming more common in some progressive organisations as a way of creating a dialogue and sharing information, but don't just approach it on a "Build it and they will come" basis - people need to be invited to participate, to subscribe to the blog, to join the Yammer group and given reasons to engage beyond having a "Name the new application" competition.
5 Tips for Effective Communication:
The next article will be on Managing Conflicting Requirements.
For far too long, traditional project communications has been seen as more a question of telling Management what you want them to hear and telling the staff what you THINK they want to hear. However, truly successful projects are notable by the absence of one-directional "reporting" strategies because everyone who needs to be is actively engaged, contributing and accountable and the traditional hierarchy and associated blame culture has been removed and replaced with people who know their role, accept their responsibilities and are motivated to work and to ensure the project succeeds, instead of trying to firewall themselves from blame for its failure.
Effective communication in a project is not a question of just progress reporting (although reporting is important), it is a question of collaboration and co-operation towards a shared vision of success, where people understand their role in the ultimate outcome and work as part of a team to achieve it. In a game of football, is it all the goal-keeper's fault for letting the ball go past him into the net, or do the other 10 players share the responsibility for letting the opposition get into a position to shoot at goal in the first place?
As mentioned in "Effective Communications at the start of a project", it is important to be clear about:
- WHO - is involved and who is impacted?
- WHAT - is happening and what it will mean for me?
- WHEN - is it happening and when will I need to be involved?
- WHY - it is happening and why it "makes sense"?
- HOW - it impacts me and how can I get involved?
But the key thing here is that if you start building a communications plan AFTER you've already started the project, then it is a bit too late - the communications should have started in earnest before the formal project began.
This approach is important for many of reasons, but especially:
Planning
You will need to take critical personnel away from their desks for periods of time - so you must ensure that appropriate cover is arranged in advance and that key people are not on holiday. Likewise, that you don't completely break critical processes by removing numerous links from the chain simultaneously.
Timing
As with planning, you need to get this right - for instance, month ends are not a good time to engage Sales or Finance because they are trying to get stuff done and closed out. So trying to talk about payroll, when Finance is trying to do the payroll is a bad idea!
Justification
People impacted by Change need to know that their contribution is important and VALUED. If they don't understand why their input is important, or don't want to make the time to actively participate, and their boss doesn't get it either and doesn't reinforce these messages, these staff are worse than useless - and so is their boss!
Engagement
If change is being thrust upon me, I may well resist it (passively or even actively) because that is human nature. However, if I have helped to shape it and have actually helped to create the justification for it, then it is my change - I own a stake in it and it will help me do my job better. Then I will support it and will encourage others to do the same.
It is easy to think of Project Communications as an outbound, broadcast activity from the Project Management Office (PMO) to the "target audiences", instead of a two-way process. However, for a project to succeed during both the delivery phase and after handover (assuming the requirements gathering was done well!), the audience for Change should not simply be "communicated with", as in talked to, they need to FEEL heard and listened to for it to be effective.
Scheduling workshop sessions in the Requirements Gathering phase, including the documentation of Business Processes MUST ensure a balanced mix of people - you need to hear from grass roots staff and Managers and, most importantly, you need to explain the context and benefits of what you're trying to achieve. If they perceive this whole process as an "unwelcome interruption", rather than an opportunity to make things better, then you've explained it wrong and, more importantly, these poor communications will lead to resistance and obstructive behaviours!
In the lead up to a new system, before formal work even starts, people need to be engaged and to FEEL able to speak freely about what currently works well and what doesn't, without fear of being singled out as a trouble-maker, or a problem. So ensuring staff are there without their Managers and that you have staff who represent inter-connected parts of an overall process, who can discuss things openly may be a critical success factor. For instance, one process may work perfectly in isolation, but after the handover it may go wrong, causing errors that you never knew about . . .
How about communication during development, what should you tell them? "We're cutting code and we're on schedule" isn't going to inspire people or make them feel part of it.
OK, so, you're in the middle of building the system and it's half finished and you have the opportunity to show some key system screens to the team that will use it. Good idea or not? Some will argue that showing them the system in a "half-baked" state is a very bad idea.
But how about this - Most people can only visualise something they are already familiar with, so they can't visualise a new system, unless it looks just like the old one. If the team (or a few key people) see the system at this point and can provide input to clarify the stated requirements, to further improve it, then it will probably be a fast fix for the coders to tweak it at this stage. Whereas, do it right at the end will be a major piece of work, if it's even possible!
Yet how often does iterative showcasing happen in software development projects? This level of transparency and openness makes the users feel much more engaged and an important part of the process, which makes them more supportive and better ambassadors for the project with their colleagues. Usually, however, the "techies" don't trust the users and the users think the techies don't "get it" and there is a significant gap between them, which causes resentment and friction and a breakdown in communication.
Communication needs to be about talking openly and exchanging views and building team spirit, with a shared vision of what success feels like, and looks like. A blog that gives status updates is NOT communication!
Now compare this approach, of actively engaging users, with the classic scenario of a newsletter pinned to the staff noticeboard, which nobody ever stops to read because it is positioned in a busy corridor, or a blog that gets updated once a month on progress that is almost meaningless to anyone outside the project team.
Products like Yammer and other Social Media tools are becoming more common in some progressive organisations as a way of creating a dialogue and sharing information, but don't just approach it on a "Build it and they will come" basis - people need to be invited to participate, to subscribe to the blog, to join the Yammer group and given reasons to engage beyond having a "Name the new application" competition.
5 Tips for Effective Communication:
- Be open, honest, transparent and authentic in your communications styles
- Accept negative feedback as being equally valuable - it often is!
- Use a multi-channel strategy - newsletters, blog, Social Media, informal face-to-face meetings
- Actively engage your audience and do it regularly - encourage input, ideas and feedback
- Explain clearly what the benefits to the organisation are, as well as the benefits to individuals
The next article will be on Managing Conflicting Requirements.
RSS Feed