Every job posting in the world has “good communicator” as a requirement, and we all think we meet that requirement. We all think we’re great communicators. We cross our Ts, dot our Is, and use proper punctuation. It isn’t that easy though, is it? Being good at communication, especially when it comes to complex projects, is like playing the bass: relatively easy to pick up, and really difficult to master.
The starting point in getting better at project communication is evaluating the effectiveness of your communication efforts. The simplest way I encourage our team at Paper Leaf to do that is to have them ask themselves, Did whomever I was communicating with have follow-up questions or clarifications? If they did, there’s room for improvement. And trust me: every one of us has room for improvement. Except for me because I’m super prefect.
The other side of getting better at communicating is being respectful of people’s time. When we communicate ineffectively, a 2-email chain turns into a 10-email chain plus a phone call – or worse, something gets missed or done incorrectly, and then we’re in rework land. I mean, we’re all busy and that kinda thing drives us nuts, right? When we communicate effectively, we’re more efficient and respectful of people’s time, and our competency shines through.
So let’s talk about how to do that.
The 5 Project Communication Rules
There’s a basic framework I follow when communicating within project teams. The crux of it is ensuring each of the five questions below are answered in any/all pieces of communication:
- Who is responsible?
- When is it required or expected?
- How/Where should it be delivered or executed on?
- Why do you need it?
- What happens next?
Here’s an example of poor communication that I’m sure we’ve all been subject to (or, have subjected someone else to):
“We need the copywriting soon.”
Nope. Not allowed. In fact, if you send me an email like that, I might come kick you in the shins or perhaps take your mother to a nice steak dinner and then never call her again. The problem with the above vague ask is that there is way too much room for misaligned expectations: who is “we”? What format should it come in? When is “soon” to you, and when is “soon” to the recipient? Why is this even important?
Imagine you were the recipient. You would have a whole ton of follow-up questions for clarification if you received an email like this, because expectations are not clear – which is the first indication that the communication is poor. And if those follow-up questions are not asked, and you just forged ahead? You’d be making a pile of assumptions, and that’s a quick route to rework, inefficiency, and frustration – aka the places projects go to die.
So, instead, here’s a better version of the same ask that uses the 5 rules outlined above:
“Our designers need all site copy from [copywriter name] by Thursday, June 2 to keep the project on schedule.
Please use the attached template, fill it out, and send it back to us via email by that date. It doesn’t need to be perfect – draft one is fine – as you’ll be able to edit the content on the live site whenever you want, thanks to the CMS.”
This version leaves few, if any, unanswered questions. It’s clear who is responsible (the copywriter), when the deliverable is expected by (Thursday, June 2), how to deliver it (using the attached template via email), why it’s important (to keep the project on schedule), and whathappens next (editing the content via the CMS). It’s the difference between receiving an organized Google Doc written by a copywriter delivered on Thursday, keeping the project on schedule, and receiving a hot mess of a spreadsheet with content written by an accountant delivered in two months, resulting in huge project delays.
The same rules / method can reasonably be applied to anything, not just dealing with clients or third parties within projects. Do you need your spouse to take some recyclables to the bottle depot? Do you need your designer to complete some wireframes? Do you need your landscaper to fix the paving stones? Check your language against those 5 rules. And if you’re on the receiving end of an ask: make sure you understand the answers to those 5 questions, or else you might be delivering something totally different from what was expected. That’s a surprise – and surprises are best avoided (unless they’re fun, like someone bringing you a cupcake, which is entirely acceptable at all times).
Be Reasonable, Pick the Right Medium, and Check Tone
I don’t have a comments section because internet comments are the wackness/a dumpster fire, but let me pre-empt what would be in there. Yes, this 982-word blog post does not cover every situation ever for all of eternity – the above rules are a general best practice, to be evaluated with reason on a situational basis. Further, comprehensive communication is not good if it’s delivered via the wrong medium for the situation (e.g. email when a phone call is better), and if tone and context are not considered (aka don’t be a presumptive asshole). Finally, there’s an important distinction to be made in situations where you shouldn’t be directive (“do it this way”) and instead should work with others collaboratively to figure out the best solution, or give autonomy to someone better suited to make a decision.
So, giant caveats and general internet outrage preventiveness aside – before you hit send on that next Slack message or email, check your project communication against the 5 rules. Have you covered:
- Who is responsible?
- When is it required or expected?
- How/Where should it be delivered or executed on?
- Why do you need it?
- What happens next?
If you have, before long you’ll find a few things coming your way: fewer mistakes, more efficient communication, and trust / respect. Not a bad outcome from 5 simple rules, right?
Photo Credit: Andre Slob, Flickr (É) – cc license