I’ve read articles that estimate that a Project Manager spends 90% of her time communicating – communicating up to her executive, across to her client’s management, laterally to her peers, inwardly to her team, outwardly to external stakeholders (and maybe a little muttering to herself or her shrink).
Communication is the lifeblood of any project. Whether 90% is accurate or not, the point is that a Project Manager is expected to communicate effectively, efficiently, clearly, sufficiently, accurately, promptly, frequently, honestly, confidently, sensitively, passionately, compassionately, persuasively, informatively, motivationally, instructively – and sometimes all in the same meeting.
And you thought becoming a Project Manager meant you had arrived!
Of course, the above description is somewhat tongue-in-cheek, though I have found myself having to exhibit any and all of those communication characteristics at different points in my project delivery career.
Projects have become more complex. End-users have become more involved in their projects. Technology has facilitated remote teamwork and additional communication avenues. Project teams have become more diverse. These factors have combined to make communication the single most important contributing factor to project success (in my opinion) – not only for the Project Manager, but for every member of the team.
Think of the following communication situations that we take into account (or should take into account) daily on our projects. I have witnessed countless communication shortcomings whereby the Project Managers are seemingly unaware that their skills (or lack thereof) are make-or-break factors in project success. And we wonder why our industry has such mediocre project success statistics.
- Stakeholder awareness: Different stakeholders have different levels of influence. Project managers must identify their need to know and right to know varying aspects of project delivery.
For example, on many of my large projects, the major funding agency was not the benefiting agency. A different organization than the benefiting agency represented the end-users and requested input. Advocacy groups demanded a say in the end product. Each of these stakeholders had the right and need to know about the progress of the project, but we tailored the information that was provided to each of them.
- Legal/Regulatory requirements: Depending on the project, there may be legal requirements for periodic status reporting, annual reporting, regulatory compliance, standards compliance, legislative mandates, phase-gate reviews, Independent Validation and Verification reviews, and others.
Over my career, I have dealt with all these types of requirements, and found that as we learned their expectations and their language of compliance, we could anticipate and plan ahead to ensure we met their requirements without much rework. Communication with the regulatory bodies needed to be precise, accurate, concise, and well-documented. As they learned to trust our process and communication, compliance became readily achievable.
- Political Awareness. It seems that nothing is immune from politics. Project Managers must be aware of formal and informal influential (aka, political) relationships governing the affairs of the project. My most predictable political tightrope was to please both the end-user executive (who typically loved us) and the IT executive (who often did not see the need for us). Good project communication was as essential as it was tenuous, because upon project completion we would leave the system in the hands of the internal IT shop under the direction of the end-user executive.
- Project team conduct/behavior: It seems that as IT providers, we were always held to a high standard. Typically, we were better paid than our client counterparts. As travelling contractors, we enjoyed certain perks to ease our life on the road, which was often viewed by our clients as living the “high life.”
As a Project Manager, I would remind my teams that we were to work as diligently or more so than anyone else; we were not to talk about our frequent flyer miles or hotel upgrades; our verbal onsite communication was to be project-oriented.
Other behaviors that we need to be aware of:
- Dress appropriately to the local customs (yes, this is a form of communication) – On one project, our team arrived to our new project office in our typical suits and ties. Locals were unfriendly towards us, and I learned later that they speculated that we were either a team of lawyers or a specialized law enforcement unit in town on an investigation. This in a town where our client’s three primary subject matter experts hung a clip-on tie in their shared office so that if anyone of them were summoned to central office, they could grab the shared tie on their way to the meeting.
- Be careful with what is posted on social media (yes, they are watching us) – I go into every situation with the assumption that whatever I post on social media will be seen by my client team. My personal rule, and one that I impress upon my team, is NEVER to mention our client or the project in any posting. I also request that they not accept “friend requests” from the client staff in order to keep an arms-length relationship while working on the project. This can be difficult, especially given the strong bonds that we form with our client teammates. However, with explanation the client staff understand.
- Keep all informal communication professional – Spelling, grammar, punctuation, and complete sentences are all important, even if answering an invitation to lunch. Email etiquette is especially important in our documentation-intense working environment. Copy only those who must be copied. Double check who is on the “To” and “CC” lines before hitting send. Do not forward an email chain without reviewing it all the way to the end first. (On more than one occasion, I have read to the bottom of an email chain before forwarding only to discover information at the bottom of the chain that I was not meant to see. Imagine the originator’s shock when I pointed this out.)
Especially dangerous is the misuse of Instant Messaging (IM). IM is an incredible tool, but I’ve seen profanity-laced messages by my teammates viewed over the shoulder by client staff. I’ve seen inappropriate messages pop up on a PowerPoint presentation during a client briefing. I’ve seen messages go to unintended team members because the sender didn’t check the “To” list before sending.
- Conduct yourself professionally during meetings – First of all, only those with a need to attend should attend. Too many valuable project hours are consumed by staff in meetings who have no need to be there. In frustration on one project, I listed the attendees at a status meeting, calculated the total opportunity cost of them being there, and presented the dollar amount (high five-figures for a one-hour meeting) to the management in the meeting. They were not pleased with me. But the next meeting had far fewer “hangers-on” in attendance.
Another per peeve of mine is attendees on their laptops during a meeting, attempting to multi-task. I have come to understand that this has become pervasive on projects. I also fell into the trap. Trust me, you cannot pay attention and contribute meaningfully while answering email on your laptop. Or vice versa, you cannot address an email with the careful wordsmithing it may need while listening to the meeting at the same time.
- Cultural Awareness: IT projects are wonderfully diverse by nature. While these experiences enrich us, they are also areas in which we need to be sensitive and understanding. It pays to get to know each team member well to make sure communication is given and received with understanding at all times.
For example, on more than one project, I would watch as a team lead would ask a developer to do something, only to receive a head shake that was interpreted as “no”. I would explain to the lead that in the developer’s culture (Indian by nationality and ethnicity), that particular form of head shake meant “yes.”
On one project, I asked one of my staff to test a module that dealt with policy for unmarried, pregnant females. He told me that it was an impossible test, as unmarried females would not be pregnant. I learned that in his culture and nation of birth, such a concept was unheard of.
On another project, I had to separate two team members – not because of cultural differences, which clearly there were – but because of their fierce rivalry over their countries-of-birth football teams (soccer in the U.S.).
On my first major assignment as a Project Manager, I was placed in a cultural situation that valued “saving face”. What a learning experience that was, as I had to learn to curb my assertive management style while still pushing hard to meet deadlines.
Each of these examples (and countless others) shows that opportunities for enhancing our communication styles can come from anywhere, and must be addressed with respect and sensitivity.
- Non-verbal communications: Stereotypically, IT professionals are unaware of how they come across, especially non-verbally. I say stereotypically, though I have found this to be true in my many years on project sites.
On one very large project for which I provided oversight services, a senior member of the IT provider’s project management team interrupted a meeting (unannounced) of client staff, who were deeply concerned about the quality of code that they were testing during User Acceptance Test (UAT). As she walked into the room, the client’s UAT lead and deputy both turned their chairs putting their backs to her. She asked several questions, to which she received curt replies from the UAT leads, who faced away from her the entire time. As she left the meeting, I walked out with her to chide her on her ill-advised behavior in interrupting the meeting. She looked at me and said, “But I thought that went very well, don’t you?” Lest you think this was an extreme case of not being able to read non-verbals, I assure you, in my experience, it was not.
On another project, my instincts told me that we were not going to meet our System Integration Test (SIT) deadlines. I asked my SIT lead to conduct quick stand-up meetings with her team every morning to determine where they needed help. Instead she put a short questionnaire on each tester’s desk and then read their responses in her office. Nothing improved, and at my insistence, she changed her approach to the daily stand-up. Amazingly, as she looked each tester in the eye and asked questions based on their verbal and non-verbal responses, she quickly unearthed several issues which we were able to address.
- Public speaking. In my mind, and based on personal experience as a Project Manager, one of the most useful skills to show one’s professionalism, confidence, and credibility is the ability to stand at the front of a room to give a well-crafted, smoothly transitioned, informative, and persuasive presentation tailored to his or her audience.
On nearly every project I served, I would watch in discomfort as the Project Manager struggled in his or her ability to present in public. Not in facilitating a status meeting (though this was often a struggle as well), but in presenting to an audience. Often PowerPoint was their puppeteer; they were the marionette. And what was more disturbing, they did not understand how poorly they came across, nor did their senior management encourage them improve this skill.
This is a learned skill, best taught by someone who has been in the project delivery trenches and has honed his or her craft as a credible presenter.
So much of project life revolves around communication, both verbal and non-verbal. I’ve seen poor communication on behalf of the Project Manager and his team escalate to project failure. I’ve seen good communication get in front of potential issues and ensure that projects progress successfully.
Communication truly is the lifeblood of every IT project.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.