CHAPTER 8
Communicating with Project Stakeholders

IF THERE’S ONE ACTIVITY that’s guaranteed to improve your projects, it’s effective communication. In project management, communication isn’t just talking, but anything and everything involved in the transfer of information.

Project communication begins with understanding who needs what information. You’ll need to know who your project stakeholders are and what type of information each of them will need. Business owners and customers are not necessarily going to need the same information as a vendor or a compliance officer, for example. You’ll also need to know when stakeholders will need the information, because late communication can be as bad as no communication at all. And finally, you’ll need to know the form in which the communication will be needed. Will the stakeholders expect a phone call, a report, an e-mail, or a text message? The message itself will often determine the modality.

If you’re a business owner, you’re probably being pulled in several directions at once, and forms and reports can help you streamline your communication efforts, help the recipients anticipate what you’re communicating, and standardize project management communications in your company. If you’re a project manager, standardized communications can organize your messages, create a history of what’s been communicated, and help stakeholders participate in the communication process. But whether you’re a business owner, a project manager, or a project team member, don’t make the mistake of relying on using forms, because a quick chat can often be the best way to move things forward. There has to be a balance between documented, formal communication and ad hoc conversations.

Identifying Project Stakeholders

At the foundation of communication is your audience, and for you as project manager, this means that you’ll need to identify all of the project stakeholders. You’ll need to ascertain the project stakeholders as early as possible in the project so that you don’t overlook anyone who is affected by your project activities and outcomes. When you overlook a stakeholder, it can be offensive to the individual, and there can be repercussions: politics, stopped projects, persistent interruptions, and negative influence on the project by the person. It’s always better to pause and determine who the project stakeholders are than to plunge into project planning too deeply.

A review of the project documents that you’ve created to date can help you identify the project stakeholders:

Project charter. If your project uses a formal project charter, you’ll be able to use it to identify many of the project stakeholders. Recall that a project charter authorizes the project work and the project manager, names the project sponsor, and identifies the key customer contacts.

Contracts. As a small-business owner doing projects for others, you’ll have contracts that identify your customers. Your contract between you and your customer will reveal stakeholders. If you’re utilizing vendors and contractors, you’ll have contracts with these entities, too—and they are stakeholders.

Sales communication. Your salespeople are stakeholders, as they’re often the intermediaries between your company’s project and the clients. They can also help identify who the stakeholders are within the client’s site.

Project documentation. Any e-mails, documented regulations, and communications from initial project meetings can all help reveal stakeholders in the project.

Whereas project documentation can be a good initial source for stakeholder identification, it’s often not enough. You’ll need to talk with the existing stakeholders, which you’ll do as part of requirements gathering anyway, and you should always ask whether there is anyone else you should speak with about the project. Always ask, especially early in the project, who else will be affected by this project. Your project may affect end users, lines of business in the client’s company, regulatory agencies, and even the public at large. If you’ve done similar projects in the past, examine those projects to help identify the current stakeholders in the present project.

As you identify stakeholders, you’ll need to create a stakeholder register to record specific information about who the stakeholders are. A stakeholder register is a document that captures all of the following about your project stakeholders:

Name

Phone number(s)

E-mail address

Classification (What type of stakeholder is this—for example, customer, project team member, or vendor?)

Mailing address

Role in the project

What the stakeholder expects from the project

What the stakeholder will contribute to the project

Types of communication that the stakeholder will need

Notes and comments

In this stakeholder register, you may identify large groups of stakeholders, such as the public at large or the end users of a company, without having to record their phone numbers and addresses. You’ll still want to document these large blocks of stakeholders, as you may need to communicate with these people through newsletters, a project web site, or a spokesperson, depending on what your project scope calls for.

It’s sometimes easy to dismiss stakeholder identification because you can probably readily see who the most important stakeholders in your project are. The problem is that when you breeze through stakeholder identification, people can feel left out of the project and unimportant, and these feelings can turn into resentment. You want to communicate with as many stakeholders as possible to introduce the project, detect possible interruptions and risks, and promote the well-being of the project. It’s also good for long-term relationship building, future sales, and your company’s image.

Throughout your project, there are communication channels; a communication channel is a possible link between at least two stakeholders. The more stakeholders you have, even if you don’t identify them, the more communication channels there are in your project. Basically, the more people affected by your project, the more channels you’ll need to influence. There’s a nifty formula in Figure 8–1 to show my point. The formula N(N − 1)/2, where N represents the number of stakeholders, shows the complexity of project communications.

For example, a tiny project with just 12 stakeholders would use the formula as 12(11)/2 to reveal that there are 66 communication channels. Most projects have many more stakeholders than just 12. Consider a project with 57 stakeholders: 57(56)/2 reveals that there are 1,596 communication channels. Will this formula make you a better project manager? Nope. It simply underscores the necessity to identify stakeholders early in order to prevent communication failures later.

Figure 8–1. Communication Channels. Communication channels are opportunities for stakeholders to communicate and for communication failures.

Each line represents a communication channel

Analyzing Stakeholders

As you identify and document your project stakeholders, you’ll also have a need for stakeholder analysis. Stakeholder analysis is the study of each stakeholder’s influence over the project. It gauges each individual’s attitude toward your project; determines his authority over the project; and prepares a strategy for addressing his optimism, power, threats, and perceived threats regarding the project objectives. You’ll analyze stakeholders so that you can better communicate with them throughout the project.

One of the things that you record in your stakeholder register is the stakeholder’s classification, such as end user, customer, vendor, or project team member. This classification can help you communicate swiftly. If you’re using software, such as a contact management system, as part of your stakeholder register, you can create groups of stakeholders that you can communicate with en masse. While the contact management system is fancy, you can also achieve the same results with a good e-mail program. The point is that you create categories or groups of like stakeholders so that you don’t overlook anyone in your communications. With this approach, you can address individuals, categories or groups, or multiple groups at once.

Within your stakeholder register, you’ll also document, sometimes on the sly so as not to offend anyone, individuals’ specific attitudes toward your project. There are three categories of stakeholders that you’ll want to identify and address in every project:

1. Positive stakeholders. These people are usually the champions of your project. They want the project to move forward, want the project to succeed, and are cheerleading your efforts. Positive stakeholders are often those who are paying for the project, such as the project customer or the business owner, but they can also include the people who will be affected by the outcomes that your project will create. Positive stakeholders are easy to identify, as they’re readily involved with your planning and your project outcomes.

2. Negative stakeholders. These people don’t like your project and don’t want it to happen. Because all projects are really about changing some aspect of the environment, it’s natural for some change-adverse people to be against your project. Negative stakeholders may feel threatened by your project; these people see your project as infringing on their line of business, personal interests, or internal power. There’s often politics in play beyond your project that can make an individual a negative stakeholder.

3. Neutral stakeholders. These stakeholders don’t have a real opinion about the success of your project, but they’re involved, and they may have influence over the project’s success. Examples of neutral stakeholders are regulatory inspectors, vendors and suppliers, and project stakeholders who are apathetic about the change that your project will bring about. A neutral stakeholder can, depending on the circumstances, shift to being positive or negative.

Once you’ve identified and classified the project stakeholders, you can go about creating a stakeholder management strategy. This strategy is a plan for how you’ll manage the communication with the stakeholders and their influence over your project. With positive stakeholders, you’ll want to encourage and maintain their enthusiasm for the project. Positive stakeholders, while well-meaning, can sometimes hamper progress through their demands for meetings, their hovering, and their attempts to micromanage the project work. Negative stakeholders can create threats and perceived threats to the project that you’ll need to identify and manage. Finally, neutral stakeholders need to be communicated with to maintain their lack of negativity concerning the project—or to convert them to positive stakeholders.

Project managers will sometimes describe decision makers as key stakeholders. These are the people in the project who have direct and often immediate sway over the project’s success. Key stakeholders are people like the customer, the business owner, the project manager, and even the project team. In larger projects, there may be key stakeholders who have competing objectives concerning your project, and they’ll try their best to nudge the project toward their goals rather than toward what’s been defined in the project scope. This is politics, and it takes a Machiavellian approach to gently manage and control these energy-draining stakeholders.

One approach to stakeholder management is to create a power-influence grid. A power-influence grid is a type of matrix; it’s not necessarily needed in every project, but it can be helpful when you have many key stakeholders to manage. Figure 8–2 shows a power-influence grid that plots out the stakeholders based on the amount of organizational power that they have and the amount of influence that they have over your project. Here’s a general guide to how you’ll manage the quadrants of the grid:

Low power and low influence. These stakeholders should be monitored, kept informed, and not ignored.

Low power and high influence. These stakeholders should be informed of project decisions and kept informed of the project status, and efforts should be made to keep their influence positive toward positive outcomes.

Figure 8–2. Power-Influence Grid. A power-influence grid helps you create a stakeholder management strategy for your positive and negative stakeholders.

High power and low influence. These stakeholders should be kept abreast of the project’s progress, and you should make certain that their project objectives are met as planned in the project scope.

High power and high influence. These stakeholders need to have their objectives and goals met in the project, as they have the highest external sway over the project success. You’ll want to manage these stakeholders through persistent and accurate communication as your project moves through its life cycle.

While the immediate goal of stakeholder management is to monitor and control the stakeholders’ influence over the project, it’s also to make certain that the objectives and requirements of the project are in sync with what the stakeholders really want and need from the project. When you identify the stakeholders early in the project, you’re more apt to be able to identify those with high influence and high power and capture their requirements for the project, not the requirements of someone who has little authority over the project work.

Establishing a Communications Management Plan

Solidarity is needed when it comes to project communications. All project managers should identify and follow a chain of command among the business owner, any sales representatives, the project manager, and the project team. You don’t want the business owner, for example, promising certain deliverables, only to have a project team member tell the customer that they just aren’t possible. You also don’t need to have the project customer asking project team members for additions in an attempt to bypass billable hours and change control. You need to establish communication rules for all stakeholders.

The communication rules for a project are defined in a standardized communication management plan. This plan defines the project’s communication model; how the stakeholders are to act with one another; the correct process for communicating with customers and the project team; and how stakeholders, especially customer-facing project team members, are allowed to respond during interactions with customers. While your internal stakeholders can be forced to follow a chain of command in the project, customers also need to be educated on the correct project procedures.

An ideal communication management plan is uniform among all projects in your organization. With each project, you’ll update the plan to reflect the needs of the current stakeholders, but you don’t want to recreate the plan and approach over and over. It’s best to create policies for your project team members, project managers, sales representatives, and the business owner. Without defined tactics, communication can break down, causing project stoppage, risks, and conflicts. A good communication management plan defines for your projects:

What information the stakeholders will need and when the information is needed. The scope of the project will often dictate what information stakeholders will need, such as dates, procurement, risks, assignments, and the status of the project. The need for information can follow a schedule of weekly reports, daily assignment meetings, or other project meetings. You might also define conditions in the project that mean that communication is needed, such as late deliverables, cost overruns, and project interruptions.

How the information will be formatted, delivered, and archived. If your organization has forms and templates for things like change requests, risk identification, issues, time management, procurement requests, and other organizational activities, it’s a good idea to identify these forms by name and location. You don’t want your project team to be wasting time looking for a form to report its weekly work. Ideally, you’ll use e-mail-driven forms and templates to streamline communication, create an automated record of submission, and facilitate communication. Of course, not all communication can be driven by forms and templates; you will also need face-to-face meetings, ad hoc meetings, daily phone calls, and the occasional text message.

Who will receive what information. Some of the information you generate during the project may be sensitive to your business, be constrained by government regulations, or have only certain people privy to it. You want to control what information is released to stakeholders so as not to create issues for your project and your organization. What you say and what you don’t say are often equally important.

How issues are managed in the project. Issues are risk events that have come true, problems with the project work, conflicts among stakeholders, and other problems that can derail your project. Your communication management plan should define how issues are documented, how they are escalated to the project manager or business owner, and how they are resolved. It’s a good idea to create an issue log for a project to record the issues, the conditions of the issues, and what the final resolution of the problem was. The issue log, like most documents in a project, will be useful for the organization and planning of future projects.

A glossary of project terms. If your organization uses unique terms, abbreviations, and acronyms, it’s a good idea to list these in a glossary as part of the project communication management plan. A glossary can help ensure that the project team members are aware of the terms, the nomenclature that you’ve assigned to internal processes, and any abbreviations that you use.

The communication management plan for your projects doesn’t have to be a lengthy document. It just clearly defines for the project stakeholders the expectations and boundaries concerning how communication is expected to happen. You need this document, even if it just begins as a simple workflow of communication, to start gaining control over how communication happens. If your projects are frenzied and full of conflicting messages, misinterpretations, and arguments among stakeholders, a communication management plan is a must. You should create a well-defined communication management plan if you want to add more control, deliver projects with more stability, and set expectations.

Communication planning also defines how communication among the members of the project team is expected to happen. Your project team members need to work with one another, be reliant on one another, and be able to communicate quickly and accurately. Face-to-face communication is the best method of communicating, as it includes the nonverbal communication that is lacking in e-mails and phone calls. If the project team is situated in one place, its members can have quick, ad hoc conversations about the project and keep chugging along. In today’s business climate, however, virtual teams are practically the norm. You might have team members from all over the world working on the project deliverables. How will you manage the lack of face-to-face communication?

Virtual teams have unique communication challenges that must be addressed early in the project. Even if you’re working with vendors that aren’t local to the project, you’ll need to address the concept of virtual teams. Here are some common communication concerns for distant workers:

Language barriers

Time zone differences

Clarity in e-mail, chat, and text messages

Holidays that may affect availability

Travel and shipping logistics

General unavailability

Technology issues with videoconferences, Web meetings, and phone meetings

While virtual teams allow you to leverage cost-effective and talented people to improve project costs and outcomes, they definitely have communication drawbacks. You’ll need to discuss these concerns with the local and remote project team members. By establishing expectations for all project team members early in the project, you’ll set rules that everyone, including the business owner and the project manager, must follow throughout the project.

Tracking and Reporting Project Performance

The primary piece of information that stakeholders, and particularly business owners and customers, are going to want to know is how the project is performing. In order to report on the project performance, you’ll need to communicate with, not just to, the project team and vendors. This means that the project team will need to contribute accurate information about its work completion, and any contractors you use will need to provide reports on their work status, delivery, and progress, too.

As the project manager, you’ll need to monitor the project as it moves forward in order to report project performance accurately. The most effective method of monitoring the project performance is to be involved with the project’s day-to-day accomplishments. Visit the job site, talk with your project team members face-to-face, review the project work, and be available to your project team. The project manager’s management style directly affects the depth of performance monitoring and reporting. There’s a myriad of management styles when it comes to monitoring project performance, with pros and cons for each:

Exceptional. With this management approach, the project manager reacts only to complications and superlatives within the project—everything else is basically assumed to be fine. The pro of this management style is that you’re aware of the worst and the best aspects of the project; however, you’re not aware of all the other conditions in the project. This style can also lead to resentment among the members of the project team, as they may see you as a manager who is not interested in their contributions unless they’ve screwed up. This is especially true for project team members who may have many supporting activities in the project, but not key activities. The progress of the project is linked to only the major achievements and major flaws.

Autocratic. This management approach means that the project manager controls and monitors everything and the project team cannot make any decisions or start any activities without the project manager’s approval. This management style can cause the project team to be idle, as the project manager will be inspecting the work and dealing with just one topic at a time, rather than delegating the work and allowing the project to move along. The advantage of this approach is that the project manager knows exactly what’s happening in the project because he is making all the project decisions. The project performance is obvious to the project manager, as he’s in the middle of all project activities.

Laissez-faire. This means that the project manager has a “hands-off” approach to managing the project. She sets the project in motion and then stays out of the way and lets the project team work. If the project team is skilled and experienced in the project work, and if its members know exactly what to do in the project, this can be an effective strategy. The con of this approach is that the project manager puts all the decisions on the project team and forces the team to be self-led. If you’re trying to make your project team more self-led, this is a good approach to use on a low-priority project, but it’s rarely useful on larger, high-profile projects, as the project manager can’t really monitor the project progress without being involved in the project work.

Democratic. With this management approach, the project manager and the project team work together to monitor and control the project work. The project team is somewhat self-led based on its roles and responsibilities in the project, but the project manager has the final approval on who does what in the project. The democratic approach allows for a nonrestrictive communication approach among the members of the project team to keep the project moving forward while keeping the project manager abreast of the project progress.

Most project managers have a predominant management style, although it’s not uncommon for a project manager to switch to a different approach based on the conditions in the project. For example, you may be using the democratic approach to allow the project team to be self-led, but if you determine that the project schedule is slipping, you’ll need to take charge and be more autocratic. Each of these approaches has insights into project performance—but all of them require you, the project manager, to communicate with the project team.

How you manage the project affects how you’ll gather the project performance data. You need a strategy for monitoring and controlling so that you can collect metrics for performance reporting. Regardless of the management approach you utilize, when you’re tracking project performance, you’re interested in five components of the project:

1. Schedule. Is the project work reaching its objectives by the time predicted? The longer a project lasts, the more likely it is that costs will increase, issues will arise, risks will creep in, and more detail will be needed. To track the project schedule, you can use daily or weekly status meetings to review the project activities, completion of project work, issues and risks, and work assignments for the next work period.

2. Costs. How is the project performing on costs relative to the estimated expenses for the project? Costs generally increase as a result of waste, defects, and risks, although you may also experience cost increases resulting from market conditions, fluctuations in the cost of materials, and poor cost estimates. To monitor project costs, you’ll need to compare the estimated cost of each work package in the work breakdown schedule (WBS) against the actual cost of completion of that work package. The aggregation of the project costs will help you forecast the final costs of the project based on current project conditions.

3. Human resources. Are the project team members completing their obligations, following the project rules, and working as they are expected to? In project management, there is an assumption that the members of the project team will act as adults, work together, and complete their assignments as requested. Often there are issues, personal problems, personalities, and overworked project team members that directly affect the progress of the project team. The project manager needs to be involved enough with the team to recognize which project team members are not completing their obligations to the project, determine why, and then act accordingly. Performance monitoring in this area of the project may need to be escalated to the business owner or some manager other than the project manager.

4. Quality. Is the project team creating the project scope with the expected quality so that the customer will accept the project deliverables? Because quality is the fulfillment of the project scope with a focus on customer acceptance, you’ll need your quality control inspections to confirm quality in the project. When there are errors, waste, and poor quality, you’ll need to document the quality variance and prescribe corrective actions. Corrective actions are likely to affect the cost, schedule, and human resources of the project.

5. Risks. What risk events are pending, have happened, or have passed, and what impact do they have on the project’s reaching its objectives? Monitoring and controlling the project risk is an important component of project performance because risks that happen can affect the project costs, schedule, and scope. Negative risks that have not happened can free up funds in the contingency reserve, lift the stakeholders’ spirits, and propel the project work.

These performance metrics, sometimes called key performance indicators, are the most common elements that the project manager, the business owner, and the project customer will be interested in. You’ll need regular processes for collecting and ascertaining this information. Periodic updates aren’t likely to be satisfactory to the key stakeholders—you’ll need regularly scheduled opportunities to collect and assemble data on project performance. Of course, if you’re active in your project, it won’t be too difficult for you to know which areas of your project are performing well and which areas need improvement.

One of the best methods for gathering project performance information is through a project status meeting. This is a simple meeting that all the project team members are required to attend. Before the meeting, the project manager distributes an agenda of what the meeting will cover. The agenda usually calls for a review of each team member’s contributions to the project since the last meeting, the status of project activities, and details on any issues or risks that may affect the project performance. The status meeting also quickly reviews the assignments that the project team is to accomplish before the next status meeting. Finally, the project manager opens the meeting floor for questions; project team input; and queries on risks, issues, or assignments.

The project status meeting should be a regularly scheduled meeting, and it should not drone on forever. I’ve known some project managers who have a status meeting every morning to quickly review the project status, discuss the day’s work, and keep the project team on track. Other project managers only find it necessary to meet once a week. Whatever approach you decide is best for your organization, you should keep to a regular schedule so that the project team members will anticipate the meeting and schedule their time accordingly.

Once you’ve gathered the performance information, you’ll need to present it to your stakeholders in a format that’s comprehensible to them. How project information is distributed is often determined by the culture of your organization, the information that you need to share, the audience for the message, and the priority of the project. You won’t present project performance information to your business owner the same way you would present it to your project customers. Always adapt the medium to the message, not the other way around. In other words, create the most appropriate communication modality for the message and the audience that will receive the message.

Performance reports, sometimes called status reports, detail how the project is currently performing on the key performance indicators. These reports also inform the reader of what’s been accomplished in the project, what’s left to do in the project, and any relevant project news, such as risks and issues resolved. A typical performance report is a one-page document that summarizes the overall performance of the project. If there are variances in your project’s time and costs, you may be required to complete a variance report. Variance reports, also called exceptions reports, explain what the variance is, why the variance has occurred, how the variance will affect the project, and what corrective actions have been taken to combat the variance.

The ongoing collection of variance reports and status reports will create an accurate reflection of your project’s performance. These reports help the project manager and the business owner see the true performance of the project, and this helps them forecast how well the project is likely to continue performing. One philosophy of project performance is to “fail early and often.” This idiom means that if the project is going to fail, it’s best to do it early in the project, learn from the mistakes, then correct the action and move forward. Early failure also gives the project manager and the project team some resolve to get motivated, get organized, and accomplish the project fault free moving forward.

While early troubles are not uncommon in projects, it doesn’t make them less painful. The 15/15 rule addresses early project problems. This rule, shown in Figure 8–3, states that if your project is more than 15 percent off schedule or budget when you’re only 15 percent into the project, you’ll never recoup these losses. This early performance indicator isn’t always accurate, but it usually is a good sign that the project has some rocky times ahead. When your project is succumbing to this rule, it’s recommended that you halt the project, determine what areas of planning are weak, and then make corrective and preventive actions.

Figure 8–3. 15/15 Rule. If a project is over budget and/or off schedule by more than 15 percent by 15 percent of project completion, the project probably will not recoup the cost or the time.

The usual suspects in early project failure are lack of project planning and overly aggressive cost and schedule estimates. Poor planning always reveals harsh reality in project execution. If you’ve made aggressive cost and schedule estimates, your project may be performing well, but not be in sync with the estimates that have been created. The root cause of the poor performance isn’t the actual performance, but the standards that your cost and time estimates have set. There’s a big difference between variances in predicted cost and time and actual cost and time.

Conferring with Stakeholders

Performance reporting communicates to your project stakeholders how well your project is performing. Regardless of the performance, you can expect a reaction from your stakeholders. If the performance is poor, they’ll share their opinion about your project, your project team, and what they expected from you. If your project is humming along, they may share a conflicting opinion, follow up with challenges and queries, and ask for project additions (since the project is going so well).

Managing the project stakeholders is the ongoing influence, and communication with the project stakeholders to keep them interested, motivated, and focused on the project objectives. The project manager and the business owner need to communicate with the project stakeholders about the project objectives and manage their expectations about the project outcomes. This means that you’ll rely on your stakeholder management strategy and communicate with both positive and negative stakeholders throughout the project. How you’ll communicate with each is based on her perceived threats, concerns, and goals for your project. You simply can’t ignore stakeholders if you want to manage them, influence them, and set expectations for project acceptance.

Managing stakeholders requires some finesse and insight into the stakeholders’ interests. If you already have a relationship with a stakeholder, you’ll have a good idea of what motivates and interests him. If you’re working with a new client, you’ll have to win her trust and confidence in your company by your project team delivering on your promises. In project management, nothing creates trust more than keeping your promises. Stakeholders will give you their confidence and trust if they like the way you’ve managed the project for them.

Winning confidence and trust requires more than just completing the project. Certainly a project manager can complete a well-performing project, but be disagreeable, smarmy, and unlikable. It’s both completing a well-performing project and being likable that win trust, build relationships, and help your company grow. One of the fundamental concepts of communication isn’t that communication isn’t just talking; it’s also listening. One of the easiest ways to understand what your stakeholders want and expect from your project is to listen to them.

Listening to your stakeholders, in particular your project customer, is more than just hearing them. It’s understanding what their concerns are, what they expect from your project, and the real message that they’re trying to tell you. The fundamental communication mode, seen in Figure 8–4, describes how communication actually happens:

Your customer is the sender in this example, and he wants to tell you about an idea he has for the project deliverable.

Figure 8–4. Communication Model. Communication follows a logical model of transferring information from one person to another.

Your customer is using an e-mail message to send you an explanation of what he wants in the project. His e-mail software is the encoder for his message.

The e-mail message uses a network between your customer’s computer and your computer. The network is the medium between the sender and the receiver.

Your e-mail software is the decoder of the message so that you can actually receive the message.

You are the receiver of the message as you read and understand the information that your customer has sent to you. If you didn’t understand him, you’d respond with follow-up questions, clarifications, or maybe even a phone call to discuss the objective.

In this example, your e-mail software sends an acknowledgment of the e-mail back to your client so that he knows that you’ve received the message.

This communication model is true in all types of communication: meetings, phone calls, and even text messages. The acknowledgment of the received message is part of active listening. Active listening means that you’re involved in the conversation, offering nonverbal clues to the message, asking for more information, or showing interest in what the speaker is conveying. Acknowledgments, however, mean only that the message has been received, not necessarily that it has been understood or agreed with. You’ve probably had conversations with stakeholders who are shaking their heads in agreement with you, but you know they have no idea of what you’re talking about. Just because someone acknowledges your message doesn’t mean that you should assume that she understands or agrees with your message.

Your approach to stakeholder management will shift based on what’s happening in the project and who the stakeholder is. Early in the project, you may be forging a new relationship with a project customer. By the project’s end, you may have established a tighter working relationship with the customer where your communication style allows for less formality and more direct talk. You can’t go from the project launch to a friendly communication approach without having developed a good relationship, led by example, and built confidence in your customer.