 |
 |
 |
 |
 |
 |
 |
 |
Bridging the divide: cross-disciplinary communication in project environments
Introduction:
Here's a social gendanken experiment: List the number of times you communicate with people on any given day. Include every verbal transaction whether it be checking out at the supermarket, setting up a bank account, answering the phone, communicating with colleagues at work etc. Next, imagine yourself transplanted to a foreign country, where you have only a rudimentary grasp of the local language. Now, think about how you might deal with each of the situations you have listed, assuming that the person at the other end of the transaction knows only the local language. Done? OK, you now have an appreciation of how many business people feel when dealing with techies. Before I'm accused of bias, I agree the converse also applies; some business people are indeed terrible communicators. In general, though, your average business person is far more articulate than your average techie.
What does this have to do with project management? Well, lots really. Projects are generally multi-disciplinary efforts that involve people from diverse professional backgrounds. Communication breakdowns in a project can arise at any human interface, but they are particularly common when the two parties are on different sides of the technical / business divide. Bridging the divide is what the present article is about. I'd like to offer a few suggestions on how the gap can be reduced; on how communication between geeks and suits (to use stereotypes) can be improved. The suggestions are mainly directed to the former, as they most often make up much of a project team. As such they are responsible for a) understanding what business users need and b) making themselves understood when conveying information to business users. Remember, the onus for communication is always on the seller of the service; the project team in this case. Customers are always right - yes, even if they have trouble articulating what they need.
Closing the gap:
So how does one get better at communicating with people on the other side of the divide. Well, there is no magic or wizardry involved, nor does it require Churchillian eloquence. What follows are some simple suggestions which, if followed, can vastly improve communications between project teams and other stakeholders. Here goes:
-
Learn the language (and use it!). When in a foreign country, the best way to make yourself understood
is to speak the local language. You don't have to be an expert, even a few phrases will take you a
long way. The locals will be better disposed towards you because at least you've made the effort. The
same applies to colleagues and stakeholders on the other side of the divide. Learn the concepts
and associated jargon of their profession. It will help you:
- Understand what they are talking about (in requirements interviews, for example)
- Frame your questions using terms that they are familiar with.
- Explain the implications of technical matters using examples that they can relate to.
-
Avoid geekspeak or techtalk. It is all too easy to lapse into techspeak when explaining technical
matters to non-technical people. Explanations need to be tailored to audiences. When communicating with
non-technical audiences remember to:
- Avoid technical jargon. Before jumping into complex technical explanations, check if they are really required. Remember your end users don't care if you are using .NET or Java, but they'll scream blue murder if it takes more than a second for a screen refresh. If you absolutely must use technical terms, be sure to explain them (in non-technical language!) before doing so. Instead of going on about this, I'll point you to a nice article on Jargon Busting.
- Use analogies when explaining technical matters. Similarities, or analogies, between non-technical and non-technical things can often be used to illustrate technical matters. For example, one might use aspects of the postal system to explain how computer networks function.
- Listen, really listen. I've been guilty of sitting through meetings and then coming out not really remembering much about what transpired. Obviously, I sat through the proceedings, may be even heard all that was said, but I certainly wasn't listening (A quick clarification directed to any of my present or ex colleagues who might be reading this: All these meetings have occurred at the other places I've worked at). Active listening is the ideal goal - one needs to listen with the intent to understand the meaning rather than the words.
- Be (and look) interested. There's no bigger turn off for speakers than to see their audience yawning, looking bored (or at their watches!), or in any way disinterested. It takes time and effort to build credibility across the divide. You don't want to mess it up by looking disinterested in what the other party has to say.
-
Seek opportunities to reduce the communication gap. There are several ways one might reduce
the communication gap. Informal communication is one
that works well for me (so much so that I wrote an article
on it). Some other possibilities include:
- "Quick wins" to gain credibility. Sometimes business users may come to you with minor requests that can be fulfilled with only a small effort on your part. Next time, do the work right away instead of delaying or providing reasons why you can't. The goodwill gained by this action could repay itself many times over if you ever work with them on a project. Furthermore, they'll spread the word around that you're a "can do" kind of person.
- Learn the art of small talk. Most people are uncomfortable with long silences, particularly with people they have just met. It is generally easy to get people talking about themselves, and its a great ice-breaker too. Here's another link to an article that lists common conversational mistakes and how to avoid them. Once you know people socially it becomes easier to communicate with them (and vice-versa). Even if your communication isn't clear, at least it makes it easier for them to ask you for clarifications as they won't be too worried about causing offence.
In Closing:
Project stakeholders are generally a diverse lot, coming from a variety of professional backgrounds. In particular, it is almost always true that projects involve both business and technology specialists. In such multidisciplinary project environments, clear communication, which is always tricky, becomes even more fraught with difficulty. This article has discussed some simple communication strategies that I have found helpful in bridging the communication gap across the divide. I hope you find some of these useful in your project environment.
Back to the top