Project Communications
The ability to communicate clearly, directly, effectively and have it easily understood is one of the top skills of a good development manager. Clear communication, which usually comes in the form of clearly written emails, is a sign of clear thinking. Jumbled and half-ass written emails that are dashed off and leave readers confused and asking for clarification, come from people who are lazy, unempathetic to the reader, and who don't fully understand what they are talking about.
​
When I was a young officer in the US Army deployed to Iraq, I was on brigade staff. My main job was to write orders, for complex operations, which verbally came from my brigade commander, telling his subordinate units what to do. My brigade commander would drill into our heads, "You have to write so clearly, it is impossible to be misunderstood."
​
In Iraq, clearly written orders were critical because massive efforts and lives were at risk. Not as much is at steak with managing a development project, but crystal clear writing sure does save a lot of time, confusion and frustration. And on the contrary, when someone sends out an email, an RFI, or an RFI answer that is not clearly written, it wastes valuable time and cause confusion and frustration. If someone has to ask you for clarification on something you wrote, that means you didn't write it clearly enough, or didn't put yourself in the position of the reader when you were writing it. Don't use acronyms, don't use jargon, don't assume the reader knows what's going on inside your pretty little head, write in simple enough terms that a sixth grader could understand what you are saying.
​
The best book I've read on writing clearly and effectively is On Writing Well. I used to think I was a clear writer before reading this book, but after reading it, I discovered a lot of my writing shortcomings and became a much better communicator. This book is a must read.
​
​
Put It In Writing
Some people prefer verbal over written communication, but if a conversation is important to the project, send a follow up email after the verbal conversation documenting what everyone talked about, what decisions were made, the next steps, and who is responsible for what. When you just verbally talk about something, it drops off people's radar and they forget what everyone said. If you have an email about a discussion, people remember it better and can go back and reference that email.
​
​
Call People Out by Name in Your Emails
One of my pet peeves is when someone sends out an email, asking for some type or action or next step to take place, but they don't identify the specific people by name who should perform that action or next step. When you send out an email and address it to "Hey Team," and ask for something, usually no one will respond. Because they are waiting for someone else to respond, or because they don't know they are the individual that should respond, or because they are lazy. If you need something from someone, call them out by name and tell them explicitly what you need.
​
I take it a step further and highlight in yellow the name of the person I am targeting. For example: "Bob, when can we expect to receive the plan revisions after our last programming session with the tenant?" It is crystal clear in this example that I am talking to Bob, and that Bob needs to take action. It may seam elementary that you should address an email to an individual by name, but I get dozens of project emails every month addressed to no one in particular. Typically after no one responds to that email, the sender sometimes follows up, and sometimes provides a little more clarity. As the development manager, it is usually my job to intervein and call people out by name to ask them to respond to the original sender.
​
​
Follow up is Half the Battle
It would be great if team members and others associated with the project all responded timely to questions they are asked and performed the actions they are asked to perform. But a lot of the times they don't. They have their own agendas and priorities, and what is important to you or the project might not be as important to them. To make sure that they actually do the task that they are supposed to do, you as the development manager have to follow up with them. If a ball gets dropped because a team member does not perform a task on time, it is not only that team member's fault, but it is also the development manager's fault for not following up with that team member to ensure he did the task.
​
Since most project communication is largely done over email, and specifically Microsoft Outlook, it is easy to flag an email for follow up. Simply open the email you sent to someone asking them to do something (or the email they sent you saying they would do something) then click on the "Messages" tab at the top, then "Tags," then "Follow up," and click on the day you want to follow up with the person to see if they accomplished the task. This flagged email will now show up on your Outlook Tasks list for the day you flagged for follow up.
​
If you don't use Outlook Tasks to manage your daily task list, you should. Click here to learn how to use Outlook Tasks to manage your project, work, and life tasks.
Next Page: OAC Meetings