This chapter is from the book
This chapter is from the book
This chapter is from the book
Control Project Communication
All team members and stakeholders should have access to the communication plan and use it to guide formal and informal communication. However, communication issues are inevitable in any project. Poor communication can lead to differences in expectations, decreased productivity, or scope creep. If unchecked, communication issues can escalate into outright conflict. Common sources of conflict and conflict resolution techniques are covered in detail in Chapter 11, “Executing Phase Activities.”
Escalating Communication Issues
An escalation plan for project communication is much like an IT help desk escalation plan: its goal is to direct issues that threaten a milestone or impede project work to the appropriate tier in the hierarchy for resolution. While an issue log or risk log attempts to solve a problem directly, escalation redirects an issue into another channel for resolution. The escalation plan can be maintained as a section of the communication plan, or it can be kept as a separate document, but both should be accessible to the team. If a category of issue can be escalated multiple times, the plan includes the escalation path.
An escalation plan should include categories of potential issue scenarios, a role or person who owns the response, a decision trigger to show when to escalate, and severity levels. Some escalation can be lateral (from one team member to another with specific skills). Also, different scenarios may need different sensitivity levels. For example, the project manager might want the team to know how to escalate a problem with the development environment, but not how to escalate vendor issues. However, team members should know the appropriate way to escalate a problem with a coworker rather than deal with it directly. Table 7-3 shows an example of a partial escalation matrix.
Table 7-3 Example of an Escalation Matrix
Scenario |
Trigger |
Level 1 |
Contact |
Level 2 |
Contact |
Notes |
|---|---|---|---|---|---|---|
Development environment |
Team cannot open authoring tool.Team cannot get into ticketing system. |
15–30 minutes downtime |
Yusef Parker, operations team lead |
More than 30 minutes or more than three incidents per week |
Tanesha Lee, operations manager |
Notify PM before escalating to Ms. Lee |
Accounts receivable |
License payments not sent on time; seats expiring. |
One late payment per month over three months |
Account manager (cc: Sam Williams after third contact) |
Two or more late payments per month, warning email from vendor |
Pat Cornick, VP of operations |
|
An escalation plan reduces friction, redundancies, and delay by ensuring only the relevant people are contacted with issues. One frequent scenario is when team members field questions from stakeholders. In most cases, stakeholder communication should be funneled through the project manager, scrum master, or other team leader instead. A good project manager or scrum master will shield team members from overly frequent inquiries from customers or stakeholders that interrupt team progress.
Project managers should understand when to let a situation try to resolve itself versus escalating the issue (and bringing conflict) before it damages the project. The first step should be to try to resolve the issue locally. If a sincere effort doesn’t work, document the impact to the project and verify the correct authority with your manager. In the preceding example, your project is affected because your accounting department is not renewing your software licenses on time. It would be inappropriate and counterproductive to escalate immediately to the vice president. However, if multiple payments are missed and your first attempts to correct the issue with the accountant do not work, then you should loop in your manager, Sam Williams, each time you contact the accountant. If the issue continues, it should be escalated to the person with the authority to fix the accounts receivable process, because overseeing the payments is taking your time away from project work.
Revising the Communication Plan
Like all project management documents, the communication plan is a living document that will change during execution. It is commonly revised when the project adds or loses a stakeholder or ends a phase. The project manager may adjust the meeting cadence in response to stakeholder feedback or update a stakeholder’s preferred communication method. After verifying that the communication goals will remain the same after the change is implemented, you should revise both the communication plan and the project schedule to reflect any schedule changes. If stakeholder communication data (such as email address) changes, it should be updated in the stakeholder register as well. The stakeholder register and the communication plan are both detailed in Chapter 10.