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.

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.

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

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.

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 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.

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.

Any other areas which should be managed more carefully when it comes to communication?

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.