While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that yet.”
Responses surprised me though. Author of Projects with People found problems of being too detailed for the audience or revealing facts too early. Well, what exactly does “too early” mean? When people already chatter on the subject at the water cooler is it too early? When managers finally become aware of chatter is it still too early? Do we have to wait until management is ready to communicate the fact (which is always too late)?
Actually gossips are powerful and spread fast. The only way to cut them is bring official communication on the subject as soon as possible. Hopefully before gossiping is started. Which does mean early. Earlier than you’d think.
Another thing is being too detailed. This can be considered as unnecessary or even clutter. Clutter is an issue raised by Danie Vermeulen. If something doesn’t bring added value it shouldn’t be communicated. If we kept this strict we could never post any technical message on project forum since there always would be someone who isn’t really interested which framework we’re going to use for dependency injection or how we prevent SQL injection and what the heck is the difference between these two. And how do you know what is a clutter for whom anyway.
John Moore looks at the problem from different perspective – over-communication can be bad when it hurts morale. I must say I agree with the argument to some point. Some bad news isn’t necessarily related with people’s work (e.g. ongoing changes in business team on customer side) and can be due to change. Then keeping information for you may be a good idea. However if bad news is going to strike us either way the earlier means the better. One has to judge individually on each case.
Although I don’t see easy way to deal with above issues they remain valid. Actually I can agree it is possible to over-communicate yet there’s no concrete border or clearly definable warning which yells “This email is too much! You’re over-communicating!” at you whenever you’re going to send unnecessary message.
The best summary came from Lech who pointed that risk of over-communicating is lower than risk of under-communicating. I’d even say that much, much lower. How many projects with too extensive communication have you seen? One? Two? Personally I’ve seen none. On the other hand how many projects suffered because of insufficient communication? I’ve seen dozens of them.
On general we still communicate too little. Yes, we can over-communicate from time to time but I accept the risk just for the sake of dealing a bit better with insufficient communication which is a real problem in our projects.
How does it look like in your teams?
Subscribe RSS feed
Follow on Twitter
Subscribe by email
12 comments… add one
I think you can communicate both too early and too much, and a good example is changing requirements.
When the requirements change so often that the team doesn't have the time to digest the first change when the second one hits, is it worth communicating the first one at all? I would suggest waiting until the requirements are a little more stable.
Maybe this also comes down to how the changes are communicated – ie, in a structured way or ad-hoc, but still I believe communicating stuff too early just adds noise and confusion.
Good point Will. Requirements management is an area where communication should be organized in some way or it'll bring a mess to planning.
Any other areas which should be managed more carefully when it comes to communication?
The comment regarding too much or too early is also very valid when talking about communication between a client and a professional services company. (My background) When communication has a contractual/legal impact it should be very precise. It should also only happen if it is factual and confirmed. Communicating "rumours" in a professional services engagement can have an impact on your legal position.
Communication in this environment happens at several levels and I believe these levels have different rules. Communication within the project is different than communicating with suppliers or clients.
Communication with a client is generally a tricky area. While being as transparent as possible is appealing idea for me I don't find it feasible.
I consider communication with customers more a game than a totally honest and open discussion with e.g your spouse. I'd love to be always completely frank with our customers but it's not so rare when it backfires.
Actually I learn it the hard way now, but form me it is still all about people you work with. There are these who you can be honest with and those who will use your every word against you. The whole thing is to learn who is who.
Anyway, I didn't want to go there with this article. That's the story for another post.
Of course it's possible to over-communicate and under-inform at the same time. We live in a world full of communication and we spend a great deal of time filtering it. In projects I think it is very important to put quality over quantity in communication, otherwise team members start to tune each other out. Sending irrelevant information is just as disrespectful as sending none. I work in government and we are masters of quantity over quality. Communication must follow a structure or it quickly becomes counter-productive.
Sandy,
To be honest I'm not convinced that communication must follow a structure or it becomes counterproductive. Actually pretty often I worked in project which had no structure for communication whatsoever and we were able to do it well.
On the other hand as far as you face situation you describe – plenty of quantity and not so much quality some formalism can be warmly welcome.
By the way, it is interesting why I didn't considered low-quality communication as a problem. Is it possible the problem never really struck me so far?
I really like your conclusion: "…risk of over-communicating is lower than risk of under-communicating…"
I was thinking this as I was reading the earlier paragraphs.
I also agree with some of the comments about requirements and communicating with clients.
I think the biggest problem with communication in software project management is not over-communicating, but mis-communicating. It is perfectly okay to communicate as early and as often as possible, but just make sure what you're saying is right.
The Lazy Project Manager says:
Communication Breakdown –
Avoiding having a nervous breakdown and going insane
There is, to my mind, a great book – Alpha Project Managers by Andy Crowe – it talks about ‘what the top 2% know that everyone else does not’ and it certainly identifies communication as a key area that top project managers excel at.
The book, based on a survey of 5,000 project managers, states in its findings:
‘Good communication is comprised of more than how the message is delivered. The information itself, the method used, and the timing with which it is delivered all contributes to effective communication.’
Communication on a project is a two way process. You are communicating out and you are receiving communication back at you and the usual complexities of filters and noise typically confuse the process of giving and receiving clear, accurate and understandable information.
Communication is also sequential, communicated through chains of people, which will add that ‘Chinese whispers’ effect – either intentional or accidental.
Add to that the sheer volume of communication these days, email, phone calls (landline and mobile), written, presented, verbal and so on, then life can be very tough for project managers to learn what they need to learn and to share what they need to share.
I was taught a truth in my early project management days – reporting is not communicating!
The fact that the critical facts and important truths are buried somewhere in a report that the right people may be in possession of does not, in any way, mean that they have received the message.
I have also learnt that to waste time and effort in ‘defensive’ and ‘offensive’ communication, typically email these days, is truly pointless and will distract the project manager from the real issues. I know building an email trail that, to put it bluntly, ‘covers your ass’ is easy to do but far better results can come from directing those same efforts in really effective communication.
Effective communication is about isolating the critical information, utilising the optimum communication method for the person (or people) that you need to communicate with, and delivering that information at the appropriate time. I would also add that to ensure that you receive the right information back to you then you need to educate people on what information you need, how you would like to receive that information and when.
http://www.thelazyprojectmanager.com
Michael,
That was my first thought when I started looking at the subject. It's a common situation when we suck at communicating not telling people enough yet somehow people seem so afraid o over-communication.
Peter,
I think you stressed one key thing – reporting doesn't equal communicating. What more – we rarely report to our project teams so even if it worked well I guess people would still remain under-informed.
i sure would like it if people who decide to post a blog in english had a superior command of the language and its nuances. i thought i would look forward to reading this blog, but i was distracted by the sentence structure, grammar challenges and overall stilted use of colloquial english.
Grace,
English isn’t my native language and I never hid the fact. This unfortunately means mistakes in my writing will happen, although I hope there will be fewer of them over time.
If it’s language (not good enough) and not the content which makes you not following the blog I’m sorry to hear this but that’s also a good news for me. This means the content here is decent which is always nice to hear.