Project communication

All the world's a stage and each project manager plays many parts. But in order to play your
part, you need to make sure you know your audience. You might not think of your project as
having an audience, but it does. They're probably not laughing, cheering, and clapping, but your
audience is listening and they're interested. The way you communicate should depend on your
audience. If you think about it, that's true for most of your communication. You might share with
a good friend that you really like wool sweaters, but you probably wouldn't tell your
supervisor. You might tell your doctor about the pain in your neck, but you wouldn't usually tell
a person on the train. It's the same with your projects. Once you understand your project's
audience, you can start categorizing who gets what information. In general, there are three
different groups of people that you'll want to consider for your audience. They're the
stakeholders, supporters, and spectators. The first group are the stakeholders. These are the
people who have a stake in your project. These could include project managers, upper
management, team members, vendors, and customers. These people have something riding on
the project. They could even be your competitors. The next group are your supporters. These are
the people who will help you finish your project. They help you with your work without actually
working on the project. These could include finance, IT support, facilities, lawyers, and quality
assurance. They're the background chorus for your project. They can help you succeed, but they
won't be held to blame if the project fails. The final group is the spectators. These are the people
who aren't stakeholders or supporters. They may be interested in your work, but the project
doesn't directly impact them. This may include project managers from other departments. The
spectators won't be interested in your day-to-day operations. You won't want to email the finance
department every time your meeting has a room change. Instead, you'll just want a simple way to
update them on your project's status. So your plan needs to address each group and their
needs, then show how to communicate to these groups and what information to share. So to do
this, you'll want to create an audience list. This list should have three groups, stakeholders,
supporters, and spectators. Then you should add roles to each group. Be sure to add roles and not
actual people. A lot of times, people will be promoted or moved to different roles so it's better to
understand the communication based on the role and not the individual. The audience list should
be very specific on how to communicate with each group. You should specify one-to-one or
group meetings, email lists, and reports. Don't just say something generic like email, phone, or
meeting. It should also show each group's communication needs, how much information does
each group need to know? Project communication can get complex quickly so when you create
your list, keep it clear and simple. You don't want to spend your time trying to communicate the
wrong information to the wrong people.

Plan the communication

A typical project starts out with a flurry of communication. The project manager talks with the
directors. The stakeholders talk with project managers, and then they talk with the teams. After
this flurry, the work begins. So you can think of your communication almost like a
submarine. Most of the communication happens within the team and away from your
stakeholders. Then, your project comes up to communicate and everyone gets updated. Then, it
re-submerges. A few weeks later, the project will surface and everyone gets an update. And then,
the team will re-submerge. Your stakeholders will tell you how many times they want an
update. Some stakeholders don't want to hear from you until the work is finished. Other
stakeholders like to be pinged every day. It's very important to know your stakeholder's
expectations before you submerge to focus on your work. That's why you'll want a project
communication plan. How much does your stakeholder need to know about your project? Who is
the audience, and what do they need to know, and why? If your stakeholder requires a lot of
communication, then be sure to spend some time creating a very detailed communication
plan. There are two different styles of project communication plans. There's the stakeholder
communication plan, and the event communication plan. The stakeholder communication plan
focuses on the who. It will be your audience list, and then a plan for how to communicate. The
event communication plan focuses mostly on the how. It will be a list of meetings, reports, and
email blasts. Then, it describes how each of them help you communicate. Sometimes your
organize will prefer one plan over the other. How you design your plan will depend on your
stakeholders. If you can choose either, then you'll want to create a stakeholder communication
plan. These plans are easier to organize and are clear to follow. Event communication plans are
focused on meetings, reports, and activities, so they can be difficult to spell out ahead of
time. Try to imagine planning your key communication meetings, reports, and presentations
before the project starts. The stakeholder communication plan is less likely to change. You'll
likely have the same audience list throughout your entire project. To start your stakeholder
plan, first find out if you already have a stakeholder register. The stakeholder register is a list of
everyone who has a stake in the project, so that you can get yourself a head start. If you don't
have a stakeholder register, than just to try to create a list of stakeholders. The stakeholder
communication plan should address four items. These are which stakeholder is going to receive
the communication? How are they going to receive it? What is the communication going to
say? And, when are they going to get it? I once worked with a school superintendent who only
wanted to receive updates through text messages. She would never read email and all phone calls
went straight to voicemail. The which stakeholder was the school superintendent. The how was
the text message. The what was short project updates. And the when was Friday after 4:00
p.m. You should use this feedback to add to your stakeholder communication plan. Also, be sure
to keep it updated throughout your project.

Encoding and decoding messages

There's an old joke that goes like this, a man named Oscar was driving down a country
road. When he went around the corner, he saw a man driving towards him in a red
convertible. The man was talking on the phone and zigzagging in and out of his lane. He turned
the corner and swerved into his lane. As he passed Oscar, the man yelled, pig. Oscar turned
around and yelled, learn to drive. But when he turned around, Oscar ran straight into the pig. At a
very basic level, communication is the process of encoding meaning into messages, and
decoding messages back into meaning. You can use spoken words, writing, pictures, and
gestures. But there's a lot of opportunity for meaning to get lost along the way. So let's go back to
our pig. When the man rounded the corner, he yelled out, pig. We can assume his meaning
was, there's a pig in the road, watch out. But he didn't have much time, so pig is how it came
out. But the word pig in English-speaking countries can have a lot of different meanings. It could
mean the animal, but it's also an insult. Think about how Oscar decoded the message, what
meaning did he take from pig? Why was he yelling? What was he doing? Does the word have
more than one meaning? As a project manager, all of the messages you send and receive have a
least some noise. You just need to make sure that the messages aren't drowned out by the
noise. When the noise is louder than the message, then you're in real danger of
miscommunicating. You could tell if there's a lot of risk for noise by looking at the message
content, circumstances, and context. Sometimes the content will have a lot of noise. The content
are usually the words. It can also be commonly used gestures, like thumbs up or thumbs
down. Sometimes the content already has noise built-in. Here the word pig has more than one
meaning. Also the circumstances will add noise to the message. The circumstances are what
you're doing when you receive the message. Let's say at the end of a two hour meeting, someone
says, well, that was a great use of our time. The circumstances suggest that this is sarcasm. If
someone said the same thing at the end of a 30 minute seminar, you might except the message as
genuine. Finally, the context will add a lot of noise. The context is where you are when you
receive the message. Say you're in a business meeting and a stranger in a suit says, you did a
great job. You'd probably react differently than if a stranger says it at a grocery store. The
context will give you a lot of background information about what the other person is trying to
communicate. The same message in a different context will mean different things. Our pig could
have survived if the content, circumstances, or context had had a little bit less noise. Maybe if the
content was, watch out for the pig. Or if the person drove a tractor instead of a red
convertible, then you'd have a different context. Watch for these when you try to determine how
much noise you're getting with your messages. Always assume that the communication has a
little noise, then you'll have a better chance of understanding the meaning.

One-way communication

A few years ago, pirates captured an Italian cargo ship, called the Montecristo. The crew was
shuffled to the bottom of the ship. When the pirates weren't looking, they wrote the ship's
location in a bottle and tossed it overboard. The NATO ships retrieved the bottle, they read the
note, and knew that the crew was safe. The pirates gave up, and no one was hurt. One-way
communication saved the day. Your project won't have pirates, but you'll certainly run into one-
way communication. In fact, almost all of your communication will be one-way. One-way
communication is a type of asynchronous communication. You're sending a message to
someone, but they won't read and respond instantly. It's often push or pull from someone else. A
good example of one-way communication is email. It's a message that's pushed from someone
into your inbox. It's often used as an announcement. Project managers are working in the golden
age of one-way communication. Think of all the email, reports, and memos you receive every
day. It might seem like you spend all of your time reading one-way communication. But many
project managers forget the disadvantages to one-way communication. You should think of
email as not that much different from throwing a bottle into the sea. This type of communication
lacks facial expressions and the speakers tone of voice. There's no real-time interaction. That
makes one-way communication pretty limited. So be sure to think of one-way communication as
notice, your notifying people that something happened. Email's perfect for a notification
like, functional review board meeting canceled. It would be risky to write an email with the
subject, your job performance. The difference is the content of the message. The first message is
straightforward, true notification, it's unlikely to be misinterpreted. The other is about a topic that
could be sensitive and will likely need some clarification. You should only use one-way
communication for low emotion messages. Think about the last time you read an email, and it
seemed sad or angry, then you later talked to the person and they said they were just
fine. Behavior scientists tell us that we think we understand emotions in text, but in reality most
of us depend on tone and facial expressions to help us interpret meaning. More often, we're
adding emotion to other people's messages without even realizing it. We're also not very good at
writing emotion. Most of the emotion we want to communicate is lost in email, reports, and
memos. If you sense that there's some emotional noise, it's often misunderstood. As a project
manager you should always follow up any questions from a one-way message with a two-way
conversation. If there's a question it usually means that your message wasn't really a
notification and is likely to be misunderstood. If you want to send a one-way message, be sure to
understand what works best. If your message is sensitive, then you use two-way
communication. For a simple notice, then just use an email message or report.

Two-way communication

At the end of the 19th century, the telephone was invented and it changed the world. Previously,
you had to transmit beeps that would be converted into written letters. The new telephone was a
marvel of two-way communication. Two-way communication is one of the most powerful
tools you have as a project manager. You could think of it as two-way, real-time
communication, like a face-to-face chat, a phone call, or even through instant messaging. As
you're sending a message, the other person is receiving it in real time. You need to nurture two-
way communication. It should be your go-to method for all important communication. If you
understand the power of two-way communication, you'll start to depend on it in your
projects. It's about having a conversation. An important part of two-way communication is this
back-and-forth between sender and receiver. There should be a rhythm. A message goes out and
the person has an opportunity to respond. The best form of two-way communication is a face-to-
face conversation. With a face-to-face conversation, you can take advantage of visual
cues, gestures, and body language. I once worked for an organization that discouraged two-way
communication. Coworkers were spread throughout the building. Very few of the cubicles had
names on them. The meeting rooms were booked months in advance. So, this organization had
trouble completing their projects. The projects were swamped with email messages and
replies. Everyone spent a lot of time trying to find answers to basic questions. One-way
communication takes a lot less effort in a lot less time. So, it's much more widely used, but one-
way communication should be limited to notifications for explaining, answering questions. And
for high-emotion messages, you'll want to use two-way communication, so you should think of
two-way communication as an investment in your project. You'll spend more time
communicating and less time clearing up miscommunications. You'll get the most value from
two-way communication if you follow some simple practices. You should focus on listening and
making sure that you don't multitask while chatting. You can enhance your two-way
communication by being aware of physical obstacles. If you have an office, don't keep a chair on
the other side of your desk. Instead, place two chairs on the opposite corner of your office. You
might not realize that your desk is a communication barrier between you and your audience. A
physical barrier can quickly become an emotional barrier. Instead, just get up from your desk and
sit right down next to the person. Also, be sure to make the distinction between what you want to
hear, and what you're actually hearing. Everyone's tendency is to accept good news and be more
skeptical of bad news. So, follow up with questions if you get good news. If you use two-way
communication, and you use it well, you'll find that it solves many of your communication
challenges. If you take the time, you'll gain a newfound respect for this oldest form of
communication.

Active listening

Think about the last time you heard a sales announcement in a store. After about five minutes the
words blend together. If you're listening for an hour, then it starts to sound like background
noise. There's some danger that this can also happen with your project. The more messages you
send, the more it starts to sound like background noise. As project managers, there's a lot of
ways to deliver your message, but delivery is only half of communication. To communicate
you'll also need to actively listen. Active listening has a few components, rinsing, remixing, and
rewording. Rinsing the message means deciding which parts are relevant and which are
irrelevant. It's tricky to rinse your messages of extra content. It means that you'll have to
remove everything that's irrelevant. It also means removing items that are technical and can hide
the real problem. This extra content might be funny or interesting, but it's usually irrelevant. The
second part of the process is remixing and rewording. That's when you're synthesizing what the
person said and paraphrasing back to them what you heard. I once worked on a data migration
project. One of the engineers pulled me aside and said that he was the only person who knows
the structure of the old database. Then he pointed out that the new engineers didn't understand
the old system. Finally he said that he couldn't help with the migration over the
weekend, because he was coaching his son's baseball team. As a project manager you have to
rinse away all the outside information and focus on the reason the person's talking. With the
engineer it's basically a rescheduling request. This takes a lot of discipline. People will bring up
items that are annoying, like, what do you mean the engineers I hired are inexperienced. Don't
get pulled into different topics when you're listening. Stay focused on the reason the other
person's talking. After you rinse the information you should remix it so it makes sense to both
you and the listener. You might have noticed that the engineer didn't actually ask to reschedule
the test migration, he just presented you with a problem. He said he couldn't do the test
migration because he's coaching. So don't just assume he wants to wait. Figure out directly what
he wants. So now you should remix what the engineer is saying. So you could reply, "Are you
asking me to postpone the test migration to another weekend?" Then wait for his response. The
remix part of active listening is where you clear up and add information to what the other person
is saying. After each remix you're clearing up assumptions and clarifying the question. The final
part of active listening is to repeat the rinsed and remixed information. So you might want to say
something like, "Are you asking me to postpone the test migration to later that weekend?" If the
person adds more information, then make sure you still rinse it away and remix it and
repeat. With active listening at least you'll have an accurate understanding, then you'll be in a
better position to respond.

Formal communication
In your career, you'll see that if you're wearing a suit and tie, people are more likely to listen to
you. Consultants know this, project managers know this, and politicians know this. Formality
matters. It's the same way with how we communicate. When we communicate, we can do it
either formally or informally. A formal message should communicate professionalism. It's
communication dressed up in a suit and tie. So a formal message might be a standard office
memo. It also might be a slide presentation. Some message channels are more formal than
others. Formal communication comes with its own set of assumptions. When someone reads an
office memo, or sits in a presentation, they'll have a different set of assumptions. These
assumptions show the listener how to respond. If an executive receives an office memo that the
project's over budget, it will have a different effect than if they say it when you bump into them
in the elevator. Formal communication is appropriate depending on the intended receiver and the
content of the message. So you should really think about formal communication in two
parts. There's a people part and a message part. If you're deciding whether to use formal
communication, you should think about both of these parts. You'll want to use formal
communication if your supervisor asks for an update. But you might just choose to send off an
email with the same message if it's someone outside of your organization. So you would change
the medium to be formal based on the person who requested the message. In general, messages
that are consequential should always be sent using formal communication. Formal
communication can be delivered in two ways. There's formal written communication and formal
verbal communication. Some communications should always be delivered using formal written
communication. If you're negotiating a contract, you'd usually use formal written
communication. But check with your manager for the company's standards. Formal verbal
communication is usually a presentation or demonstration. This helps show that you care about
what you're communicating and that it's important to the organization. Say you wanted to give a
status update on a project. If you give an update to the project stakeholders, you'd certainly want
to use formal verbal communication. So in this case, you'd probably want to do a slide
presentation and answer follow up questions. You'd also want to dress formally to communicate
professionalism. If the audience were different, you might want to change the way you
communicate. Let's say that you hired a new developer. In that case, you'd be fine with informal
communication. You just take them out to lunch, and update them on the project's status. So even
though the message was the same, you'd change the delivery based on the person. If the project
went over budget, you'd likely want to use formal written communication. Just remember that
formal communication signals a higher level of professionalism and seriousness that you'd need
for certain messages.

Informal communication

Most of the energy and project communication is about formal communication. You can find
plenty of courses on improving your business writing or presentation skills. But the majority of
your communication will be informal. Informal communication is delivered in two ways. There
is informal written communication and informal verbal communication. A good way to think
about informal communication is all of your communication that's not prepared. In today's
projects, you'll mostly receive informal messages as email. It's informal but it kind of arrives in a
non-standard format and it's casually written. A classic informal message is notice, something
like, there's cake in the kitchen, or the 10 a.m. meeting is canceled. A project manager will often
receive dozens or hundreds of these messages each day. It's almost as if someone is tapping you
on your shoulder. This short, informal, written communication is how you'll usually interact with
your team. But you'll also have a lot of informal verbal communication. Although it's not as
popular as email, these chats will still take up a good chunk of your day. They're usually cubical
discussions or feedback after formal meetings. Like formal communication, these informal chats
come with several assumptions. The fact that it's informal usually means that it's easier to ask
questions. You're not as worried about interrupting. This is the real strength of informal
communication. It's usually much easier to get the unfiltered information that you
need. Sometimes, the presenter will say something that's incorrect at a formal presentation. But it
can be rude to correct the presenter during a formal presentation. So most of that will be
clarified with a small chat after the formal event. When I was a project manager, the program
manager would have a slide presentation each month on how each project fit into the larger
portfolio. The meeting was a formal, verbal presentation. The program manager would prepare
remarks and then deliver them to the group. Because it was a large audience, you could never ask
any questions. Instead, each project manager would add several small, informal chats, to clarify
parts of the presentation. Some project managers do this by standing close to their team. Then
they can easily see when someone's available for a quick chat. Other project managers will do
something called MBWA. That's an acronym for management by walking around. These project
managers walk around and encourage team members to have spontaneous chats. Project
managers know that having a lot of these chats will fill in some of the gaps from informal reports
and presentations. Another thing project managers can do is make sure that you're accessible for
chats with your stakeholders. They'll usually tell you more informally than they would share in a
formal report. Finally, make sure that you're seen as friendly and interested in solving
problems. This is a common theme throughout all communication challenges. If your team, your
stakeholders see you as unfriendly, then they'll be less likely to have these quick chats. You
won't be able to get by with just formal communication. If you skip these chats and depend only
on formal reports, then you'll always be partly in the dark.

Categorize the stakeholders

When you're a project manager, you'll have a lot of people who are interested in your
work. People will be interested in how the project affects them, they'll also be interested in some
of the decisions you make. Some of these people will be your stakeholders. A stakeholder is
someone who believes that the project has an affect on them. This belief could be real or
imagined. Your communication plan will have a list of stakeholders in a stakeholder register. It's
simply a list of everyone who has a stake in your project. For larger projects, you'll have a
stakeholder management plan. This is a detailed look at how to work with the stakeholders in
your project. It builds on your stakeholder register. The first step in your stakeholder
management plan is to categorize your stakeholders. When you categorize your
stakeholders, you don't categorize them as individuals, instead you'll need to categorize them as
roles. I once worked on a large healthcare project. There were doctors, insurance
companies, patients, and administrators. To categorize them, I needed to identify their roles. So I
didn't put names like Dr. Johnson in my stakeholder register, or list out a company like ABC
Insurance. Instead, I just created roles like lead doctor and insurance partner. These roles
simplify the stakeholder register. All doctors and insurance companies should have similar
communication needs. Remember that with your communication plan, you're trying to streamline
your communication. So if you've put in individual names in your register, then you'll need to
know the person to understand their needs. You'll want to lump together as much
communication as you can into one group. That way, you won't send a lot of updates to people
with different criteria. So once you have your roles in your register, you should categorize
them based on their communication needs. For that, you should use the P3I technique. You want
to list out their power, impact, interest, and influence. Power is pretty much what it sounds
like. It's the ability that this role has in the organization to influence others and decisions. So you
might see that executive management roles usually have a lot of power. Impact is different from
power. In many projects, you won't have access to executive management. Instead, you'll be
working with someone who updates the executives, like an executive assistant. This person
might not have that much power, but they'll provide the resources for the people that
do. Stakeholders will also have different levels of interest in your project, so you want to
categorize your stakeholders by their interest level. A stakeholder might have power but very
little interest. The head of human resources might be very powerful, but they probably won't be
thinking much about your project. Finally, there are your stakeholders who have influence on
your project. These are the stakeholders that you'll work most closely with. Each of your
stakeholders should be categorized using this P3I technique. It will make your register much
more useful and is a key part of your stakeholder management plan.

Prioritize the stakeholders

As a project manager, you'll never hear anyone say, take your time. Instead, you'll probably get a
lot of, as soon as possible, or ASAPs. So how do you communicate with everyone ASAP all the
time? The short answer is, you don't. Instead, you'll need to prioritize your communication with a
Power and Interest grid, this grid is for you, and not for your stakeholders, so don't share it. It
shows who gets the highest priority when communicating. The Power and Interest grid has four
quadrants. Starting at the top left-hand and moving clockwise, there are the high-power, low-
interest stakeholders and high-power and high-interest stakeholders. These are the top
stakeholders you'll need to prioritize. The bottom right quadrant has the high-interest, low-power
stakeholders, these are usually stakeholders outside of your project. They might be bloggers or
people in the media. They're powerful in other areas, but not a high priority for your project. The
bottom left quadrant has low-power, low-interest stakeholders, these are the stakeholders that are
barely connected to the project. They should have the lowest priority in your communication
plan. Low-power, low-interest stakeholders are usually barely connected to your project. They
might be the end users that are only interested in your project if the website is down. So take the
time to decide, which stakeholders go into which quadrant. Now that you have your
stakeholders in your Power and Interest grid, you can use it to build out your Stakeholder
Register. The Stakeholder Register is a ranked list of all of your stakeholders. There should be a
column in your register called Priority. This is where you'll create your communication priority
label. So take each quadrant in your Power and Interest grid and write your communication
goal for each of these four quadrants. This goal becomes our label. The top left quadrant has
your high-power, low-interest stakeholders, you'll want to keep these stakeholders satisfied, so
this usually means that you want to send them just enough communication to keep them in the
loop. So in your Stakeholder Register plan, you'll label them Keep Satisfied. In the top right
quadrant, you'll have your high-power and high-interest stakeholders. You'll want to manage
their communication closely. This is usually quite a bit more than just keeping them in the
loop. You'll want to make sure that they have copies of all your reports and access to all the
project information. I might use Manage Closely for my label. The bottom right quadrant is the
low-power, high-interest stakeholders. The stakeholders should be just informed about your
project, this usually involves a lot of one-way communication. Inform is a good label for these
stakeholders. Finally, you'll have the bottom left quadrant. These are the low-power, low-interest
stakeholders. They'll be the lowest priority stakeholders. You'll need to monitor them to make
sure they don't become higher priority stakeholders. So we could label them Monitor. So now
that you have your four labels to prioritize your stakeholders, you can then update the register
with these labels. I've done it with the most commonly used labels, but you can use whatever you
want. Just make sure that the label is meaningful. These labels should be laid out in your
communication management plan. This will then become part of your larger project management
plan.

Manage executive stakeholders

I once worked on a project where the executive sponsor would come down and talk with
everyone on the team. When she asked how things were going, the developers would respond
with a long list of challenges. Then, the executive asked, why the developers seemed so bogged
down? There was a language mismatch between the executive and the developers. The
developers focused on overcoming challenges. The executive wasn't used to hearing these
everyday challenges, so to them, it seemed like they were bogged down. Executive stakeholders
are part of the group that you need to manage closely. They'll use their own executive
language that doesn't have the same terms as project management. So communicating with your
executives is a dual challenge. You need to make sure that you're monitoring their
communications, but you'll also need to make sure that you're using executive-friendly
language. When you speak to executives, try to keep three things in mind. First, understand the
executive's key motivators. Second, be concise. Third, try to understand the big picture. Let's
start with the first, understanding the executive's key motivators. The executive for your
project could have a whole portfolio of other projects, so they'll mostly be interested in a
successful project delivery. That makes their motivators slightly different from that of the project
manager. The project manager is primarily focused with delivering the project on time and on
budget. So when you talk to your executives, use the language of quality and delivery. If they ask
about the project, try to list out the recent accomplishments. Then, let the executive know that
you're on schedule. If you're behind schedule, be sure to use formal written communication. The
second thing is be concise. In project management, you'll often hear the term elevator pitch. This
is a 30 second summary of your project's status. It might be the same type of update that you'd
give to a friend or family member. Executives are not used to hearing challenges unless there's a
recommended fix, so be concise. Never give your executive a list of unsolved challenges. It will
just seem like you're not handling the project. The final thing to keep in mind is try to have a big
picture of where your project fits into the executive's overall portfolio. Your executive sponsor
will have challenges beyond just your project. They'll appreciate when you consider how your
project fits into the overall organization. When you start your project, it's easy to become
focused on what you'll need to accomplish. You don't often get a chance to step back and think
about how the project got started. You'll just need a simple statement that shows that you see
beyond the walls of your project. This shows that you can see the forest and not just your
tree. Executives often appreciate that greater depth of communication.

Answer tough questions

As a project manager, it's inevitable. At some point, a stakeholder is going to ask you a tough
question. Your instincts might be to sugar-coat the answer. You might even try to ignore the
question. You should fight these instincts. I once worked on a project for a group of schools. The
project was behind schedule and one of the stakeholders sat me down and asked, "Why do you
think we should fund this project "if the software isn't working?" If this happens to you, try to
remember the acronym NIECE. N, never get upset. I, illustrate their question with examples. E,
empathize with the stakeholder. C, clarify the question. And E, explain your answer. I'd been
working on this project for over a year, so it was difficult to not get defensive. But I didn't get
upset. Instead, I asked him to illustrate with some examples. He said he had given a
demonstration to a group of customers and the software didn't create student accounts. Using
active listening, I tried to get him to clarify the question. So which part of the software wasn't
working? Was it just the create student accounts? Try to get very specific illustrations. You'll
want to focus on the question and not on the stakeholder. You'd never want to ask something
like, "Why do you think the software's not working?" That type of question might make the
stakeholder defensive. You just want to make sure that you understand the question. All of your
listening should have empathy. Admit to wrongdoing or mistakes. Understand the stakeholder's
point of view. Then you'll want to clarify the original question. Are you asking me if we should
cancel the project? When you clarify the question, you have a much better sense of what the
stakeholder's actually thinking. Remember, his question actually has a positive tilt to it. He's
asking why he shouldn't cancel the project. Compare that to, please shut down the project. That
type of clarification probably means that your project's already canceled. The final, and perhaps
most important part of the NIECE acronym is to explain your answer. When the stakeholder's
asking you a question, it's usually because they're going to use your answer with somebody
else. So a lot of times when the stakeholder asks you a question, what they're really asking is,
give me an answer I can use. So be sure to give them your full thought process. Something like, I
don't think we should cancel this project because we decided to develop a software very
quickly. We did this because we knew that the customer would make a lot of changes. The
downside to delivering it quickly is that we'll spend more time debugging. So after you explain
your answer, you might want to make some suggestions on how to improve the process. The
stakeholder for the schools decided not to cancel the project. He even used my illustrations to
explain to the other schools the issue at the next demonstration. Focusing on the question really
improved our communication.

Cross-functional communication

If you work for a large organization, then you might run into the challenge of communicating in
a cross-functional team. A cross-functional team is a group of employees from different
functional areas working together to deliver a common product. Most organizations are still
divided up into different functional areas. Some common functional areas are sales,
finance, marketing, human resources, and technology. That means that you might have someone
from sales, finance, and software development all working together on the same team. For more
on how cross-functional teams work, check out Working on a Cross-Functional Team in our
library. The big challenge with cross-functional teams is that people underestimate the shared
language and concepts that are part of each functional area. So, it's probably second nature for
salespeople to talk about quarterly sales goals and conversion rates, but this might not be familiar
to software developers. The key way to overcome this challenge is to make sure that you're doing
a lot of cross-training between the team members in different functional areas. A software
developer might not be interested in understanding conversion rates, but in a cross-functional
team, they have to learn all these different terms. That's because this shared language is a core
part of what makes these teams effective. It might seem tedious for software developers to learn
about sales and for salespeople to learn about software, but that's the price you'll pay for this
efficient level of shared communication. I once worked for an organization that had a cross-
functional team that was working on a common finance product. The finance people explained to
the developers the differences between cash flow, assets, and liabilities. Then the software
developers communicated the differences between JavaScript, mobile apps, and test-driven
development. The team was able to make decisions much more quickly once they had this shared
language. It leveled the playing field. It made everybody feel like they could contribute to group
discussions. They weren't spending time clarifying jargon and could quickly reach
consensus. When you're working on a cross-functional team, you want to make sure that you're
comfortable both teaching and learning. You'll need to make sure that you're not afraid to ask
questions. Let your team members know when you don't understand a term or concept. It's
equally important that you're patient when communicating with other team members. You may
have been working for decades in the same functional area, so it may have been some time since
you've had to explain key concepts that are commonly used in your functional area. It takes
patience to explain this to someone who might be entirely unfamiliar with the concept. You
might learn something yourself when trying to explain a concept simply. If your functional area
has a lot of different language and concepts, then you might want to create a shared jargon
board. This is just a whiteboard in your teamspace that lists out some of the shared language that
your team needs for better communication. This could be acronyms that you use in your
functional area or even industry-specific terms. Some teams may find that they even need small
training sessions where one team member communicates some key concepts to the rest of the
team. These meanings can go a long way toward creating a shared language for easier
communication.

Why we meet

Many meetings are no longer called meetings. They're called briefings, innovation circles, or
executive overviews. But most of these are just a standard conference meeting. And a standard
conference meeting is just one of three types of meetings, the conference meeting, work group
meetings, and brainstorming meetings. The conference meetings are typical office meetings. It's
usually one person presenting slides on a single topic. This meeting will have five or more
people with one presenter. Conference meetings are the default in most organizations. If you're in
a meeting with more than five people, then chances are you're in a conference meeting. They're
designed to get everyone on the same page or to let everyone know what's going on. Most
conference meetings are an efficiency drain on organizations. Studies find that these
meetings don't do a good job of communicating, but even as efficiency experts squeeze more and
more out of organizations, the conference meeting lives on. It hasn't changed much in
decades. Most businesses have conference meetings because they're tribal. They're a good
opportunity to interact with coworkers. These meetings are a good way to build your
networks, so a supervisor will point out an employee's hard work, and that's an important
business practice. Conference meetings also cement your place in the organization. They'll give
you a sense of where you fit in with everyone else. Finally, conference meetings are often the
only way to meet people you wouldn't otherwise meet. Think about some of the people in your
organization that you only see in meetings. You'll have to work at it if you want a meeting that's
not a conference meeting. If you don't have a set agenda, then your meeting will always
default to a conference meeting. If you want to have a more efficient meeting, then you should
have a work group meeting. A work group meeting should have a maximum of five people. This
seems to be the magic number to collaborate. The work group meeting is designed to solve a
specific problem. A typical work group meeting has three to five people. The agenda might be
something like, figuring out why the server keeps crashing. It also might be a discussion about
why an employee is underperforming. The final type of meeting is the brainstorming meeting. A
brainstorming meeting is the most difficult to organize of all these three types. This is a meeting
with a maximum of seven people. That's enough to get a diversity of viewpoints but not so much
that the meeting splits into separate groups. In a brainstorming meeting, everyone tries to come
up with new ideas. Keep in mind that these are very difficult meetings to run. They usually do
best with one facilitator who presents questions, and everyone tries to come up with creative
answers. People should play off of each other's ideas. It's almost like meeting jazz. That's why
true brainstorming meetings are very rare. If you're a meeting organizer, be sure to understand
the differences between these meetings and which one you'd like to schedule. Also, be sure to
name your meeting in a way that best communicates your agenda.

Meeting management

It might sound strange, but it's true that, many times, people are in meetings and they don't know
why they're there. Your job as a meeting organizer is to create a clear purpose for your
meeting. Everyone should know why they're there. You should organize your meetings with a
sleek efficiency using the SHARKS approach. The SHARKS approach is S, state the
agenda before you start your meeting; H, hijackers will be at your meeting so watch out; A,
adding relevant information is the key to a good meeting; R, repeat the agenda at the end of the
meeting; K, keep the meeting small and short; S, scheduling should be outside of the meeting. So
let's start with S, state the agenda at the beginning of the meeting. The agenda should be very
clear, something like this is an hour-long meeting to discuss the challenges with installing the
database server. Don't assume that everyone at the meeting will know why they're there. In fact,
it's safer to assume that most people at the meeting don't know why they're there. If someone
asks a question that's outside of the agenda, just tell them that you'd be happy to answer their
question offline. That's where you're in danger of being hijacked. The H in our SHARKS
approach is that hijackers will be at your meeting. Some people can't help themselves. They'll
want to ask questions that are not part of the agenda. If they hear questions about buying
servers, they'll chime in and say, you know, we should really streamline our equipment
purchasing, then they'll start a new meeting within your meeting. The only way to keep your
meeting from being hijacked is to say that their ideas are outside of the agenda. If you let your
meeting get hijacked, then you'll have a reputation as someone who doesn't have productive
meetings. The A in the SHARKS approach is for adding relevant information. No one should
talk at a meeting unless they're adding information. This is particularly challenging for project
managers. There's something deep in project managers that forces us to communicate
agreement. A project manager will interrupt and say, yeah, I agree with that. This can be a
distraction that doesn't add information. The R in the SHARKS approach is to repeat the agenda
at the end of the meeting, then compare the agenda to what actually happened. The K in
SHARKS is to keep your meeting small and short. Sometimes people go to meetings to find out
about the agenda. After they arrive, they realize that there's no reason to be there so they open up
their computer and answer email. You should always be going through the process of invitation
grooming. Make sure that only the people that need to be there are there. The last S in the
SHARKS approach is scheduling. Scheduling should take place outside of the meeting. There's
no reason to keep people at the meeting just to schedule the next meeting. Email is a much better
tool for scheduling. Listening to everyone else's schedule is not a good way to communicate that
you value their time. If you use the SHARKS approach, you'll get a solid reputation as someone
who knows how to run productive meetings. People will show up ready to communicate and
you'll get a lot more accomplished.

Decide what to include

The Romans saw purple as a sign of wealth. So the poet Horace criticized long-winded
writers by saying their snazzy wording was like purple patches sewed into their clothing. That's
why this extra language is called purple prose. It sounds fancy but it's really just a patchwork of
bad ideas. 2,000 years later, you'll still see a lot of purple prose. Many reports use these purple
patches to hide bad ideas. Some project managers believe that if an idea is wordy, it might seem
more thoughtful and acceptable to stakeholders. But most reports shouldn't hide bad
ideas. Instead, you should try to focus on brevity and clarity. A good report communicates just
what the reader needs to know. Here's an actual paragraph from a report that I received on a
project. Because of missed opportunities to properly utilize the business-requirements-
documents that business-analyst team recommends a partial-scale-back of the development team
so the-timeline-is-flattened into the next quarter for budgeting and possible-schedule-
realignment. Now imagine if this was reworded more concisely. To cut cost, we recommend that
the team extends software development into the next quarter. This report is saying that the
developers should slow down so they can save more money, which for a project manager, is a
bad idea. Projects that take longer almost always go over budget. So here's some ways that you
can keep your reports free of purple prose. First, always make sure that you're using the
minimum language you'll need to communicate. Watch out for those ize words. We wish to
utilize, we want to make sure that we prioritize, or this is how we finalize. When you add the
ize, it makes the sentence more complicated. Compare this. If we prioritize this, it would lead to
a better outcome, as opposed to this, this is a high priority. The ize-words only make the sentence
more confusing. Also try to avoid the passive voice in your reports. The passive voice makes the
object of the sentence the subject of the sentence. So here's a passive voice. The report was
created by the project manager. Here's an active voice. The project manager created the
report. The passive voice sounds like the idea doesn't have ownership. It's used in reports to
hedge an idea. Finally, don't be afraid to use bullet points. Remember, your report should have
the minimum amount of language you'll need to communicate. Bullet points are great for just
that purpose. You'll find the busiest stakeholders depend on bullet points. Many projects are
funded not by the report's language but by its shorter bullet points.

Clear language

Some people effortlessly put words on a page. They'll sit in front of a computer and write out
clear sentences. But these people are rare. They should be celebrated and not copied. Many of us
either write badly or spend a lot of time rewriting. Overly complex writing doesn't make your
ideas sound more impressive. In fact, making complex ideas seem simple is much more
difficult. If you can do that in your reports, then you'll have a much easier time communicating
ideas. Each time you sit down, you can spit, polish, and shine your way to clear writing. First,
spit out everything you can think of. Just start writing everything that comes to mind into an
open document. Don't worry about grammar or even punctuation, just get it all out. This will
give you some place to start. Then walk away from your document, just leave it alone. Either do
something else or start another report. Wait as long as it takes to forget about what you
wrote. Then later, go back and polish your writing. Read your document from beginning to
end. Move paragraphs so that there's a clear flow. The polish part is pretty difficult. Unless
you're very talented, the report you spat out will look like a cluttered mess. You'll probably
spend a lot of time overexplaining the least interesting ideas in your report. Try to carefully think
about your audience. Who's your reader? What will they know? Why is the reader interested in
your document? The polish part of your writing should be the part that takes the longest, so take
the time to look objectively at what you wrote. At this point, you should walk again from your
report. You should take the biggest break to clear up your head. You'll need a fresh perspective
for your final edit. In this last stage you'll shine up what you wrote. Do a final review to tighten
up your writing. Many writers use too much text, so look for sentences that are
restatements. You might see some of these in the words themselves. Look for phrases like "in
other words" or "in summary." these will often be unnecessary restatements. It's fine to use
restatements while talking, but when you're writing, you can go back and change what you're
saying so there's no reason for restatements. You don't want to say that your first sentence was
unclear, so here's another one. The final pass to shine things up should remove all of that extra
material. If you spit, polish, and shine, you'll have a much better chance of writing clearly
without spending too much time staring at an open document. Remember that the first step to
being a clear writer is to get those first words on the page.

Simple charts

Simple sketches are a powerful tool for complex ideas. You'll want your reports to
communicate well to everyone. Some of your stakeholders will be visual thinkers, so they'll have
a much easier time reading your report if you include some simple sketches. A sketch can be a
chart, graph, or even a small figure. A smiley face is a good way to show a happy outcome. A
bar chart shows comparisons. A light bulb is an easy way to show an idea. These are all simple
sketches that communicate ideas quickly and effectively. A sketch can take advantage of the
context. The reader can intuitively see how each idea fits into your report, even with something
simple like a smiley face over a dollar bill. So your sketch doesn't need extra information. You
don't have to write out "increase profits" or "How happy are you with your stay?" This keeps
your reports brief. In this report, the smiley face communicates a happy outcome, the dollar bill
communicates profits. This small sketch takes advantage of your readers' understanding that
increased profits leads to a positive outcome. Anyone who's used instant messaging knows how
much you can communicate with a little emoji, even though what you're saying has a different
context. A sketch is also the best way to show relative differences. It's much easier to see how
concepts relate to each other. A pie chart shows the parts of a whole. A bar chart can show
relative sizing. These sketches are usually easier to understand than percentages and ratios. A
sketch can also be the best way to show complex relationships. Imagine you're creating a report
for a database migration. Here you can show just an image of the data server with five arrows
pointing to new servers. A clear sketch will also invite discussion. If you're a project
manager, you already probably realize the power of whiteboards. A few simple sketches on the
whiteboard are a quick way to start a discussion. You can take this same concept and apply it to
all of your reports. People will often ask to explain a confusing sketch over confusing text. If
someone reads confusing text, they'll assume they misread it, but if someone sees a confusing
diagram, they're more likely to ask for an explanation. Finally, an interesting sketch can
hold your readers' attention. A few well placed sketches will give your readers something
interesting to think about. You can test this yourself by including some colorful charts in your
report, then hand a copy to your team member and you'll notice that they'll flip through all the
pages of text and stop for a second when they see the diagram. Those few extra seconds are
giving you just a little bit more of their attention.