Many project management professionals have a natural flair for communicating. They’re good about sharing meaningful information with stakeholders and they don’t have any trouble interacting with others on the team. Unfortunately, even strong communicators sometimes stumble now and then. This becomes particularly problematic when schedules are tight, when resources are lean, and when there are a lot of people doing the talking.
Maintaining open lines of communication with stakeholder groups is often a difficult task. These are the people who most want to know what’s happening with their project but are also less engaged on a daily basis than those working inside the Project Team. Below are a handful of mistakes that even experienced project professionals sometimes make when it comes to communicating with stakeholders.
Too much jargon. Using common project management acronyms or other industry jargon is a given when conversing with fellow Project Team team members, but it can be a source of real confusion for stakeholders. They likely don’t focus on project management methodologies in the normal course of their jobs, so be mindful about how much trade-related jargon you use. Either take the time to explain what terms such as “controls” mean or what a Gantt chart is, or make a concerted effort to rely on phrases that are in more common use. If it makes sense to use an acronym during a presentation or in a status update e-mail, spell it out the first time it appears in each communication. When it’s possible to avoid acronyms, consider doing that. And remember that an acronym in the project management sphere may exist—but mean something else entirely—in a different discipline.
Too much data. It may be easy for your team to quickly review and analyze large datasets—particularly if you’ve already been staring at the information for weeks—but others outside the Project Team probably need more time to digest and understand what they’re seeing. Rather than overwhelming stakeholders with mounds of data, try pulling out meaningful milestones or important numbers to better clarify the situation. Explain where the information came from and what it means. If a figure from last year is available for comparison, include it. Your team runs many risks in offering too much data or too few supporting details, not the least of which is a stakeholder’s instinct to simply put a halt to any progress until they better understand what you’re trying to tell them.
Too many conclusions. It’s crucial that Project Teams provide recommendations along with many of the datasets they present. However, project teams should be careful they aren’t offering up so many conclusions that stakeholders either feel they’re no longer involved in the decision-making process or they begin to doubt your team’s transparency. Where conclusions are offered, include the supporting data and also consider explaining why other potential conclusions aren’t considered viable.
Too much on technology. In today’s information-heavy environment, technology is generally a good thing. Project teams, however, need to realize that stakeholders are people, and sometimes people require more than technology provides. The solutions to this problem are simple. Include a phone number in your communications so someone with questions (or who doesn’t want to type a detailed e-mail on their smartphone) can give you a call. Another example of overusing technology is when a Project Team opts for computer-generated imagery rather than actual photographs. Pictures often resonate with people far better than graphic do, so select a good photo at least some of the time. You can add arrows or text to highlight certain features without losing that great connection with your audience.
