Communication – clarity vs project-speak

As a project manager I don’t profess to be an expert in all the different aspects of my project or all the skills needed to deliver it. But I do know enough to know when I am being fed a load of rubbish.

Dilbert techno-speak

When I saw this cartoon I had to share it because it really resonated with me. My own BS detector (that’s bullsh!t to you and me – excuse my language) chuckled when I read it. So Rule No.1 in my projects is that all communications outside of the team must be in plain English that anyone could understand. Even within the team you should keep it simple unless it’s tech to tech or SME to SME to discuss or resolve an issue. If there are complex technical or business issues (such as regulations) to be explained, do it in a separate document and refer to it from the general comms. Then those that are interested or need to know can go find it. That way we avoid the scenario in the cartoon.

Most project people realise they can’t get away with nonsense in their reporting or communications, so when project-speak or techo-babble is spouted, it’s usually accurate but meaningless to the audience. But even when you keep the language plain and simple, it may not be the right level for the audience.


That leads to Rule No.2 – always write with your audience in mind. If you are running a business re-organisation project, the messages you need to send to the impacted staff will be very different in focus to those on the steering committee. So you need to put yourself in the shoes or the reader. Ask yourself how would I react to or understand this message if it was me being impacted?


Doing this can take a bit of practice so it’s always good to test the message on a colleague and ask them to read it from the recipients perspective. And that leads nicely into Rule No. 3 – always test your communication on someone else. Get a team member or colleagues to read it and give feedback with an explanation for their views. That last part is important. Don’t take the feedback personally and don’t necessarily accept all of it, especially if you disagree with the rationale or explanation behind the feedback. After all one piece of feedback is just that – one other view. If you disagree with the rationale, seek further feedback to get a broader assessment.


Rule No. 4 for effective communication is make sure you have the right audience. Sending the message to the wrong people is a school-boy error but easily done if you haven’t thought about how the audience could be broken down or segmented. It might be more appropriate to split the message and place a different emphasis on different parts to different groups.


My final rule – Rule No. 5 – is always get feedback after the message has gone out. How was the message received? Was it understood in the way that was intended? Did it prompt further questions?


Following these simple rules can help you communicate the progress and consequences of your project and reduce the amount of unnecessary noise and distractions that you have to deal with.

What are your own experiences of communications howlers? Leave a comment below.

Leave a Reply

Your email address will not be published. Required fields are marked *