Project Management Articles|
Bridging the divide: cross-disciplinary communication in project environments
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:
Alright, enough said. I've listed a few techniques that can help bridge the communication
gap across the technical / business divide. Obviously, the list isn't comprehensive: any technique that
improves effectiveness of communication across the divide is worth trying. The
Mind Tools site has some nice articles on
improving communication skills. Many of the pieces are relevant to communications across the
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
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:
These are a couple of techniques that have worked well for me. Try them - they are easy enough and
you just might be surprised at the results.
"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.
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