So far, the previous articles talk about different techniques for cost calculation, schedule estimation, risk management, as well as other relevant processes for delivering a project consistently within the stakeholders’ expectations.

While many people will say that properly executing a project is the core of the project manager’s responsibilities, I believe that the project team is the main responsible for the practical implementation. The most important part of the manager’s job is to actually ensure a solid communication among all relevant stakeholder groups. The role of communication management goes far beyond simply exchanging information.

The vast majority of the project manager’s schedule is spent communicating with others. The effort doesn’t go to the practical execution; instead, it goes to ensuring that everyone is doing their job according to the project standards and within the time and budget constraints that were established at the beginning of the project.

The bottom line? Every project management tool is a communication tool.

To become more efficient as a project manager, we must pay attention to four main areas related to managing communication in a project:

1. Communicating with the project team
2. Communicating with other stakeholders, such as management and customers
3. Managing change in a project
4. Creating project reports

While we split project communication into four main areas, they are actually part of a single larger context where the project manager is responsible for understanding the client’s needs and properly translating them to the project team. Figure 01 shows how this relationship happens.

The project manager is the main responsible for managing the information flow between the project team and other stakeholders.

Let’s cover each of these topics in more details and see how we can apply certain project management principles to help us identify the best way of dealing with each stakeholder group.

1. Communicating with the project team

Needless to say, your team is essential for delivering a project that meets your customer’s expectations. As you can see in Figure 01, communicating with the team is mostly about translating the client’s needs to a set of well-established responsibilities that are clearly distributed among team members according to their availability and skills.

This involves handling four major needs from each team member:

• Individual responsibility. Each team member needs to know exactly what they need to do in the project. Your team members depend on a clear set of responsibilities for being able to deliver a good work.
• Project coordination. Project coordination is about ensuring that each team member is informed about the progress of the work being done by others and that the whole group works efficiently together.
• Project status. As the project evolves, status meetings become essential for communicating the current progress and identifying opportunities for improvement. Keep in mind that, even though the ground rules are defined in the project proposal, there is always room for improvement in a project execution. Status meetings are important because they provide an opportunity for team members to communicate their perspective on the project execution.
• Project decisions. Your team needs to be informed about all the relevant decisions made by the project client, management, and other stakeholders. This is essential to avoid loss of productivity and to ensure project coordination.

Since these four areas are critical to the success of your team and project, let’s go through several techniques that will help you strengthen team communication and improve its productivity.

1.1 Assign tasks and responsibilities clearly

Before sitting with your team to discuss and delegate tasks, there are several steps you can follow to maximize the chances of choosing the right person for each job. Start by analyzing your Work Breakdown Structure, as this will make clear the skill requirements for each job. This imposes some restrictions on who can perform certain tasks within the project.

Once this first analysis is done, move to the schedule estimation document. Which tasks are the most important ones? Which ones can be delayed without harming the overall progress of the project? Answering these and other questions will add some more constraints to your choice set: the urgent tasks will probably require personnel with more time availability.

Finally, look at your cost estimations. How much does it cost to have person A perform task X? What about person B? When distributing tasks within the team, you are trying to find the right balance between minimizing costs and speeding up processes. In a team that has a standardized salary, cost constraints are less of a concern than in teams with members from multiple departments and with different remuneration structures.

Once you have a general idea of who should do what, it’s time to bring your team on board for a detailed discussion about each one’s responsibilities. Ideally, you will listen to each member’s motivations and use them to refine your decisions even more. This, however, is not always possible, and often you’ll find that the three main constraints discussed above will leave you with a very limited set of choices for each specific task.

Nonetheless, once you make the decision about who is going to do what, it’s time to ensure that each team member receives a task description as clear as possible. You can think of each individual task as a “mini-project” itself: the team member must deliver a certain outcome, within a certain period of time, within a certain budget, meeting certain expectations, and depending on a certain number of parallel or sequential tasks.

In order to help you communicate all that as clear as possible, here are some techniques you can use:

1. Communicate the task deliverables in clear terms and figures. “We expect a successful Facebook marketing campaign” is not enough. What defines “successful” here? Is it the number of clicks? Is it the number of views? Is it the CTR, the conversion rate, and the profits per click? Define numbers and targets that can be easily compared with the real outcome, so your team members know what to expect.
2. Communicate expected deadlines and levels of effort. Use the Gantt chart for that, so each team member has a clear picture of the due dates they need to follow. Keep in mind that different employees will have different perspectives on how much effort is needed to deliver the task within the deadline, so you must carefully balance the two before defining a final date.
3. Give plenty of time for discussions and questions, and make sure that what your team understood is what you wanted to communicate. The more time you invest in your team’s preparation, the better the outcome they will produce.

1.2 Carry individual status meetings

As a project manager, your first assignment related to status meetings is to demystify them. The standard usage of status meetings is for when performance is poor, leading to fear and apprehension in your team members. This shouldn’t be the case, and status meetings should be something that happens to both praise and criticism.

The goal of status meetings is not to control your team; instead, it’s to provide them the necessary attention to ensure they are working on the right direction, and, depending on their performance to give them proper recognition or to call their attention to opportunities for improvement.

One important observation is that you must actively schedule and enforce regular individual status meetings. Your team members will certainly come across many doubts, and if you don’t follow up with them, they might feel unprepared for the job. It’s important to give a certain degree of freedom for decisions, but you must check if they are going in the right direction. Even the smallest decisions, if made repeatedly wrong, may lead to a considerable gap between client expectations and project outputs.

If you believe it’s better to adopt an “open door” policy in which the team members can just come to your office and talk to you, make sure you make yourself available. Share your weekly calendar with everyone so they know when you are busy, and create specific time slots for open door time.

1.3 Carry collective project status meetings

While individual meetings are essential, they are just one type of meeting you want to implement. Group meetings targeted at discussing the project landscape and progress are also necessary, but they are quite tricky (yes, the next section presents several arguments against them, and you should use them carefully).

It turns out that collective meetings are not inefficient by definition: they are inefficient when the person holding the meeting doesn’t know how to properly do it. If you are to conduct meetings with your team members, inform yourself about how to run a successful one.

Collective meetings bring several benefits:

1. They are important for bringing the team together and strengthening cohesion.
2. They help you bridge the communication between external stakeholders and your team members.
3. They are important for answering common doubts and solving shared problems.
4. They are a great way of keeping everyone informed about the general progress of the project.

To maximize the benefits from collective meetings, however, there are a few things you must keep in mind when conducting them. First of all, you need to be prepared with a well-defined agenda. If your meeting has no clear goals, you and your team will very likely diverge towards less relevant and less urgent topics. To avoid that, create a clear agenda that ranks each topic according to its priority. Communicate the agenda in advance, so people can collect information and doubts about the topics you want to discuss.

Secondly, don’t bring everyone into the room. Bring only the people who are involved in the agenda for the meeting and leave the others working, undisturbed, on their tasks. You can provide a quick overview of the entire project, but avoid trying to give enough time for every area: this will lead to long, inefficient meetings. Instead, focus on one or two areas per meeting, bring the team members of those areas, and discuss their issues with more details. A good strategy for choosing which areas to bring together in the collective meeting is the amount and strength of interaction between the different tasks of your project.

Thirdly, meet with your team in the morning. As the day progresses, people tend to increase the focus on their work. Conducting a meeting in the morning ensures that you cause less stressful disruptions to your employees. Never (and I mean, never) schedule a meeting after lunch or at the beginning of the afternoon. There is a biological reason for that: our bodies are wired to feel sleepier twice a day, between 2:00 and 4:00 am, and between 1:00 and 3:00 pm. No sane manager will do a meeting that early in the morning, but many people like to use the second time slot. Absolutely avoid this mistake unless you want to have a bunch of half-awake, incredibly unproductive brains around you.

Fourthly, be efficient and organized yourself. Stick to your agenda and avoid diverging the focus of the meeting. You might discuss one or two extra topics if the team finds it necessary, but don’t ask for information about issues that you didn’t include in your initial agenda.

Last but not least, think about your meeting as two events coming together: the core meeting, where the project issues are discussed, decisions are made, and doubts are answered, and the social meeting, which caters to the integration needs of your team members. Budgeting time for both moments is important when defining how long your meeting must be.

1.4 When it comes to meetings, less is more

We’ve discussed a lot about meetings, but the truth is that you should try to reduce the amount of time you keep your team members inside a room and unable to actively work on the project. HBR’s article, Stop the Meeting Madness, discusses the problems and inefficiencies of running unnecessary meetings. They even provide a cost estimation tool for the total cost of a meeting in a corporation. Here’s what they observed from interviewing 182 senior managers across industries:

65% said meetings keep them from completing their own work. 71% said meetings are unproductive and inefficient. 64% said meetings come at the expense of deep thinking. 62% said meetings miss opportunities to bring the team closer together.

General meetings can become serious time and productivity wasters for many reasons:

• Employees who are on time have to wait for their late colleagues.
• The general meeting covers most areas of the project, and not every team member needs to receive general information about the progress of the whole project.
• The doubts of one area or member might not be shared by anyone else.
• Meetings interrupt the focus of your members, preventing concentration.
• Meetings multiply the time wasted: if you have a meeting with 12 people that lasts 30 minutes, you compromised 6 hours of collective productivity.
• People tend to wander off in meetings, and they are very likely to be unproductive or paying attention to something else during it.

Still on the same topic, David Grady gives a great TED talk about how to prevent bad meetings from happening, and Jason Fried discusses why the office is not the best place for getting work done.

Despite all this frenzy against meetings, I prefer to take a more conservative approach. Your team members are not robots, and they need social interaction with other colleagues. Meetings are a good place for this to happen; as already mentioned, you can even budget (in secret) some “social time” for each meeting and add it to your expected duration of the conference.

2. Communicating with external stakeholders and business executives

We already discussed that communicating with the team is mostly about translating how the external stakeholders’ needs define the project. For that, however, you must keep an open line of communication between you and these very same stakeholders, including your business executives and management.

Remember our earlier discussion about creating a communication plan for your project? Let’s revise a couple of important questions you need to ask yourself when defining a communication strategy:

• Who needs to be informed about the project, and why?
• What type of information do they need? How often will you provide updates? And how detailed do the updates need to be?
• What is the actual goal of each communication effort? What kind of information do you need to include to achieve the goal? What is the best communication channel?

To cover all the different aspects involved in it, we wrote an entire article about how to manage all the stakeholders of a project. In this article, we provide an overview of the main stakeholder groups, how to identify them, how to create a single registry to keep track of related information, as well as several tools to help you define the priority of each group.

Since we don’t want to repeat all the information already presented on the mentioned article, this section will focus on discussing a specific group that was not fully covered in it: the business executives.

2.1 Communicating with business executives

The main interest of the business executives is the profitability of the project. When writing the project proposal, you have defined several estimates for revenues, costs, and, consequently, profits. These estimates, when presented to the business executives, were enough to convince them of the potential of your project and obtain their approval.

The communication throughout the project, therefore, should focus on presenting how well your project is doing in terms of costs and potential revenues. Naturally, there is some room for variation: no estimates are perfect, and your project is likely to have higher costs than the forecasts indicated. The business executives know that, and you shouldn’t try to hide the numbers if they are higher than expected. Instead, provide a detailed explanation of why such an increase was necessary, and your action plan to compensate the increase by also increasing revenue.

Our first advice is for you to be careful when first presenting your project. Honesty and transparency are key here: what could go wrong in the project? What can increase its costs? How are you planning to deal with that? What-if scenario analysis is a great tool that can help you define specific action plans for different scenarios in the project execution.

Our second advice is for you to be proactive. If your business executives reach the point of explicitly asking you for project and profitability reports, they’ve been thinking about them for a long time. Not providing information proactively transmits the implicit message that your project is not doing well. After all, if it was, you’d be showing your results around for everyone to see.

If your project is not doing well, avoid focusing on the problems and focus on the solutions. If your supplier is late or delivered products of inferior quality, it’s not the business executives’ job to solve the issue; as the project manager, this is your responsibility. When writing and delivering your reports, adopt the “we are facing this issue, and here are the possible solutions…” approach instead of simply presenting the problems your team is facing. This will increase trust and reduce the executives’ anxiety and concerns with the project.

3. Managing change in a project

The title of this HBR article says it all: All Management Is Change Management.

From a broad perspective, this is absolutely true: even when following a carefully planned execution plan, each step you and your team take means changing from a previous to a next stage. So why is change management so hard? Why is it that so many managers fail miserably when changing the direction of their projects?

To answer this question, we must understand that there are two types of change: expected and unexpected. Expected changes are those described in your project plan. Every time you take an action that impacts the outcome of your project, you are implementing an expected change. As you can imagine, expected changes are not the problem: you already have them defined, their consequences established, and contingency plans for dealing with them if something goes wrong. If you know that next week you’ll have to migrate your database to another server, you’ll proactively notify the tech team so they are prepared to deal with the most likely issues that can occur.

Unexpected changes, however, are considerably trickier. They show up without notice, and they can cause a lot of anxiety and confusion. An example: new standards or new requirements from a meeting with a client. When receiving the new information, you didn’t have an explicit plan to handle it immediately. Instead, you’ll have to process it and find the best way to integrate the changes to your existing project structure. Still in our database migration example, imagine if, on the very morning of the migration event, your client contacts you informing that they decided to opt for a completely different server architecture. From the IT team perspective, this means that the problems that might now happen are completely different, and your previously prepared team has to face a new, uncertain situation.

Our goal is not to talk about expected changes. We’ve been talking about them since the beginning: planning for them is the very same process of planning a project. Our goal here is to discuss unexpected changes.

3.1 The change management process in a project

It’s not possible to create a single roadmap for handling changes. Every change is unique, so what we do for one might not work for another. The best course of action is to discuss a solid framework that you can implement in any change process and that will give you better tools to think about the practical steps. Figure 02 shows an overview of the information flow you should implement when integrating changes requested by stakeholders.

Project changes can lead to complete chaos if they are not kept organized and tracked properly. This is done through the change log. The goal of this document is not to overload you with work; if that’s the case, either your project is going through a lot of changes (which is a signal that it’s planning process was not well implemented), or your change log is poorly designed. The change log’s goal is to help you track the direction of your project and whether the changes you are implementing are consistent with each other.

To help you with this, we’ve created a simple yet very effective change log that you access through this link. It’s extremely intuitive, and you can make a copy of it to your own Google Drive or download it as a spreadsheet to your computer.

Let’s then move on to discussing in more details each of the steps in Figure 02.

3.1.1 Identify the deliverables that result from the change request

When you receive the information about a change taking place in your project, you must think carefully about all the deliverables that will be affected by it. How will this update change your schedule? What about the costs? And the standards of your project output? If your customer, for example, is opting for a cheaper server, it’s your job to carefully explain whether the potential loss of performance is worth the cost savings.

This information must then be integrated into the already existing project documentation and submitted for approval by the relevant stakeholders.

3.1.2 Continuously create intermediate deliverables

That’s an important one. When going through a change in your project, granularity is important. The reason is straightforward: you probably won’t have a thorough plan similar to your original project proposal or statement of work. Implementing change means walking on uncertain grounds. Since your stakeholders’ expectations are changing, you’ll need to submit your team’s work for revision and approval more often than before.

3.1.3 Submit the deliverables for stakeholder evaluation and approval

Autonomy for decisions is good, but only when you have a clear picture of the project outcome. During change, this picture becomes fuzzy and subject to change, so it’s better to submit your work to stakeholder approval instead of simply deciding by yourself (except if the decision scope is small and doesn’t present sensible risks to the project).

3.1.4 Obtain the formal acceptance of your stakeholders

You might think formal acceptance is unnecessary and only makes the project execution slower. Sometimes that’s true, but for change moments we suggest you take the conservative approach. Clients changing their minds and simply denying any previous given information or agreement are not as rare as you might think.

Formal approval is a way of safeguarding you against future complaints about your decisions and deliverables.

3.1.5 Record the changes in the change log

You can access a template of a complete change log here. Organizing the changes and having an overview of every request in one place is a great way of preventing contradictions. This will also help you bring people up to date with the latest requests and changes to the project.

Ideally, a change log will register the date and the person responsible for the change request, as well as a small description and an ID through which you can reference the change and request more details if needed.

3.1.6 Continuously review requested changes

Notice that, from now on, we enter on the cyclical phase of continuous improvement. That’s when you or a team member will continuously review the requested changes and consider their impact on cost, schedule, and product/service quality. These changes might come either from external stakeholders or from the own project team. This assessment should be carried continuously, and a recommendation about accepting or rejecting the change must be issued by the responsible person.

3.1.7 Stakeholder evaluation of the recommendations

Once the recommended course of action is received, the relevant stakeholder (if the change request was made internally) will either (1) confirm the recommendation, (2) request additional details, or (3) deny the recommendation. The change log should be updated once the decision is made.

3.1.8 Obtain the formal acceptance of your stakeholders

We now return to the final step of the process. Make sure to obtain the formal acceptance from your client or stakeholder to avoid any future conflict of information.

3.2 Who should you include in your decisions?

Project decisions don’t always need to include external stakeholders or business executives. In fact, waiting for their approval for every change you want to implement might lead to unnecessary delays. Instead, it’s the job of the project manager to decide which decisions are going to be escalated to external stakeholders or higher management, and which ones will be made by the project team.

To help you establish the decision scope of your project, here are some common categories that most projects use based on the importance of the decision.

3.2.1 First change threshold: The project team

The project team is the lowest change threshold (the required level of decision making). Project decisions that don’t affect cost, schedule, or product functionality usually fall under the scope of the project team. But don’t get me wrong: these decisions are as essential as those that affect cost or schedule.

A great example is the User Interface of a mobile app or website. While the final client might give some guidelines, fine-tuning the design and creating a truly immersive experience is a job for the project team and the designers of the project. Submitting every little change for external approval takes too long and is too costly.

Since there is a considerable amount of project team decisions, there’s no need to document everything. Focus on documenting the most important decisions, as well as those that have repercussions on other teams.

3.2.2 Second change threshold: The change board

The change board is composed of members from different areas of the project, as well as external stakeholders, such as members from the client company and other functional areas within the project organization.

• Representatives from the project team: These are members that actively work in the project. They have the most expertise in presenting the impacts of the proposed changes in cost, schedule, and functionalities. If the project is not very big, the project manager can fulfill this role. If, however, the project team is large and technically diverse, it’s better to have more than one team representative.
• Representatives from the client organization: When discussing changes in the product, the client must be informed and be able to give their take on the matter. Client representatives are also essential for providing a customer-side perspective on how the changes affect product usability and experience.
• Representatives from related sectors within the project organization: Every change in the project impacts other areas in the project organization. While not every external sector must be represented, it’s a good idea to have a person who can identify how the proposed changes affect other relevant departments.
• Representatives from functional management: These managers are mostly responsible for handling how the project changes will affect external relations between the company and the relevant stakeholders. For example, if changing the product specifications will require using a new vendor, the procurement sector must be aware of the discussion and able to discuss whether the new scenario is within reach.

The change board will normally be enough for most decisions. There can be more than one change board based on the size of your project, and, if necessary, each one can be composed of members with more authority.

Finally, avoid abusing change boards and try to solve as many issues as possible within the first change threshold (your project team). Escalating decisions takes time and resources, sometimes resulting in unwanted project delays. We’ve presented several techniques for collaborative problem solving, so make sure to try to find a solution internally before sending the issue to the change board.

3.2.3 Third change threshold: Executive boards

Even change boards have a limit on the cost and schedule variation they can handle. If the decision affects the very own survival of the project, its market value, or its overall profitability, higher management and the executive board of both the client and project organizations should be consulted.

4. Creating effective project reports

Project reports are the most neglected part of a project communication strategy. They are usually criticized as being unnecessary, too long, or with outdated information. It turns out, however, that project reports are as good as the person who makes them. If the responsible for creating the reports doesn’t put the necessary level of effort, it’s obvious that the reports will be useless.

Contrary to popular management beliefs, project reports are a very effective way of recording and transmitting key information across different organizational levels and stakeholders. Let’s go through a couple of tips to help you write better and more effective project reports.

1. Define the target of the report. Who are you targeting when creating the report? Is it your direct client organization? Your project team? The change board?
2. Define the scope of the report. Don’t include everything in one document. It’s going to become long, tedious, hard to read, and with disconnected sections. Instead, split the information according to topics and create one smaller report for each main area of your project. If I’m interested in reading the current cost scenario when judging a new change request, I can quickly access it by opening the expenses report. If I want to be up to date with the project schedule, I can open the timesheet and check the progress of each area.
3. Create a centralized repository for all the reports. In addition to actively sending the reports to all relevant stakeholders, create a single, centralized online folder for uploading all the reports. This way, whenever someone wants to access them, they don’t need to look through all the emails or files on their personal computers. This also ensures that only one version of the reports is valid: the one uploaded to the official folder on the cloud.
4. Write less. Writing less is harder than writing more, so you’ll have to put some extra effort to write shorter reports. Writing less makes your reports more efficient by avoiding unnecessary information.
5. Use visuals to represent data. There are well-known benefits to using graphs and charts instead of text and tables in reports. Naturally, if your report is targeted at presenting detailed information, you should include the raw numbers used in your calculations. Nonetheless, they can be included in the appendix, and the main section used to present visuals that carry the most important results of your analyses.

The bottom line is simple: deliver an interesting read to an interested stakeholder. Project reports should add value to the project; if they don’t, skip them.

5. Final words

Despite its importance, effective communication is often overlooked. As the project grows, documents start to become messy, information starts to become decentralized, and communication in general becomes more confusing and less effective.

If you are careful to keep your communication strategy organized and scalable, you will notice a much easier project integration and tracking. Effective communication is in everyone’s best interest, and ensuring it will bring considerable cost and schedule benefits for your entire project!