 |
 |
 |
 |
 |
 |
 |
 |
Informal Communication in Projects
Introduction: setting the scene
Is this situation familiar? You're a project manager in trouble. Specifically, you are in about to walk into a monthly meeting with the steering committee (or project sponsors). The news you have for them is not good. Your project, their project , is going to be delayed because X component (or Y person or Z resource...) is behind schedule by a month. They won't be interested in your reasons, excuses, of course. They're going to get stuck into you - as the project manager you are expected to be omnipresent, omniscient, omni-everything where the project is concerned. You should have anticipated, intercepted and neutralised the problem. Now, instead, you're about to walk into a verbal barrage.
Assuming the delay was unanticipated, there is nothing you could have done to avoid it. However, is there something you could have done to preempt the inquisition you are about to face? Something that would enable the steering committee to see your failure in a more kindly light. Perhaps there is. Perhaps you could have preempted some of the spoken shrapnel you are about to cop by meeting your inquisitors informally, one-on-one to explain the situation.
Here's another, possibly recognizable, scenario. Your project is behind schedule. You have identified the bottleneck - a work package that is the responsibility of Mr. A. On discussing this with him you find that he cannot deliver on schedule unless he gets some help right away. You realize that another team member - call her Ms. B - who is currently waiting for A to finish, can help. However, helping A isn't B's responsibility on the project. Your problem: to get B to cooperate (assume she does not report to you directly).
There are a few ways to deal with the above. The worst option is to go to B's manager and ask him to request B to help. This is likely to make B resentful. A better option would be to make a request directly to B, informally, explaining the situation. Even better: analyse the delayed work package and see if there's something you can take on yourself. Most tasks have some drudge work that nobody likes to do!. Take on the responsibility for these boring bits yourself and ask B to help with the rest.
In this article I discuss how one can promote use of informal channels of communication in project environments. Appropriate use of these may help avert or alleviate difficult situations such as the ones painted above.
Communication: Formal and Informal:
It is a truism (or even a cliche) that good communication between project stakeholders is essential to the success of a project. This is well-recognised by experienced project management practitioners. - for example Max Wideman has termed communication as the lifeblood of a project. It is obvious, for example, that if the steering committee isn't well informed about what is going on they are likely to be unsupportive when problems arise. Thus most project management books and methodologies dwell on the need to develop a communication plan. In essence such a plan details the communication needs, frequency and mode for each group of stakeholders. The plan usually includes only formal communications such as status reports, project meetings, user training, newsletters etc. Informal communications such as conversations, discussions, informal memos etc. are generally not included. Nevertheless, the latter can be very effective in promoting unity of purpose and action within project teams and also improving understanding between project teams and other stakeholders. Unfortunately most books and methodologies don't have much to say about informal communications. This may be because it takes some effort to create an environment in which informal communications are encouraged. In the next section I discuss some tips on promoting their use in project environments.
Most people intuitively understand the distinctions between formal and informal modes of communication. Therefore, rather than boring my readers with matters academic, I've relegated definitions and distinctions to this appendix.
Promoting Informal Communications in Project Teams
So, as I've mentioned earlier, it can be difficult to promote informal communications in project environments. Nonetheless, there are a few things that you, as a project manager, can do to encourage people to communicate informally. Most of these involve setting an example by doing (or not doing) certain things. The best way to encourage particular behaviours is to demonstrate them, consistently, yourself. Here are some that you might consider:
- Manage your project by walking around and talking to people. Nothing is as effective as face-to-face communication. This will help you get to know people personally, and help ease the communication process. The next time you fire up your email client to send an email to a colleague in the same building - Stop. Walk over to his office and have a chat with him instead. Soon you'll find that others reciprocate and start to use informal communications with you.
- Get to know your team members and other stakeholders socially. Organise team get-togethers outside the office so you can meet them socially as a group. This will give you an opportunity to observe social dynamics within the team. Additionally it is worth spending some time one-on-one, in a social setting (perhaps a coffee break or working lunch) with each team member. It is easier to communicate with people you know socially. For instance, one way to avert the first situation described in the introduction - you could have a chat with the steering committee members, individually, prior to the meeting. This would give you an opportunity to tailor your message to suit each individual's temperament. I have generally found it better to deliver such bad news one-on-one, to people I know socially rather than to a group I know only professionally. It is easier to explain the situation and provide reassurance individually. Further people (generally!) handle it more calmly and are more open to explanations.
- Demonstrate a genuine commitment to support the team when things get difficult. Set an example - go out of your way to help a team member who is struggling with a problem. The effort put in will be repaid several times over by the loyalty and respect that such actions will earn. Further, team members will find it easier to discuss problems with you an forthright manner when they know that you are willing to roll up your sleeves and work with them.
- Don't ask the team to do anything you aren't prepared to do yourself. This what I advocate in the second scenario described in the introduction. As another example, when the team works into the night, be sure that you are there with them. Don't forget to have dinner delivered to the office when this happens. This is exactly the kind of expense that your discretionary budget is for. If you don't have one, consider funding the dinner yourself. Such actions will gain you immense goodwill. Group members will find it easier to open up to you and to each other, thereby creating an environment conducive to informal communication
- Never say "No" (even when saying so). Nobody likes to hear a "No". However, it is often necessary to turn down requests or otherwise reply in the negative. When doing so, be sure that you present alternatives. That way the requestor understands that you aren't being obstructive and that you genuinely want to help. Instead of a "No, I can't" try a "That might be difficult, but how about ....instead.". People will find it easier to talk to you when they know you never say "No".
- Start a project forum or blog. This is a nice way to to air project related matters in an informal medium. It also provides a forum for matters that do not directly pertain to the project but are in some way related to or arise from it. For example - an aspect of the project that lends itself to generalisation, suggestions for social activities etc. This provides yet another mode for interaction thereby helping team members get to know each other better.
- Avoid blaming people publicly for problems that are encountered in projects. Look for solutions instead. This will encourage people to be open about their mistakes, without fear of being blamed or scapegoated. Which in turn will nurture an environment of openness and trust - a precondition for creating and opening channels of informal communication.
It must be emphasised that in the context of projects, the two forms of communication complement each other. A project can run on formal communication alone, but it will not run very smoothly because of the lack of a personal touch. Informal communication helps strengthen relationships and is invaluable in resolving crisis situations. The following automotive analogy is rather apt: formal communication keeps the wheels of a project turning while informal communication lubricates the axle.
I'd like to close this section with an important point: informal does not imply incoherent or illogical. Informal communications do not absolve you from the responsibility for clear, logical messages. Be sure that you review all messages before hitting send or verbalising. Basically - review before you transmit ,think before you speak, look before you leap etc. etc. You get the point, I'm sure.
In Closing
Informal channels can be very helpful in improving communications within project teams and also, more generally, between all stakeholders. This, in turn, can have a positive effect on relationships, as they evolve from being purely professional to something more. Despite this, most books and project methodologies have not acknowledged the importance of informal communications. In this article I have discussed some ways in which I have attempted to cultivate and encourage these within my project teams. Implementing thes may make "Communication Nirvana" - a situation in which everyone knows everything they need to know, when they need to know it - just that little bit easier to achieve.
Back to the top