Chapter 10. Communication Triggers and Target Audiences

This chapter covers the following topics:

Understand communication triggers: Triggers include audits, project planning, project changes, risk register updates, milestones, task initiation/completion, gate reviews, incident responses, and business continuity responses.

Understand communication target audiences: Target audiences for communication include the project sponsor, stakeholders, and team members.

Understand communication rationale: Rationale behind project communication.

Communication triggers are project events or conditions that must be reported to the appropriate audience after they occur. During the Planning phase of a project, the project manager creates the project management plan and its subsidiary documents, which include the communication plan. This plan details the communications that must occur during the Executing, Monitoring and Controlling, and Closing phases of the project, and it lists the target audiences for these project communications. The project manager is responsible for knowing when and how involved parties should be kept in the loop.

This chapter discusses common triggers for project communication, as well as the target audiences and rationale for each type of communication.

This chapter covers the following objective for the Project+ exam:

3.3 Explain common communication triggers and determine the target audience and rationale.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 10-1 lists major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 10-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section	Questions Covered in This Section
Audits	1
Project Planning	2
Project Changes	3–4
Risk Register Updates	5
Milestones	6
Task Initiation/Completion	7, 10
Gate Reviews	8
Incident Responses and Business Continuity Responses	9

1. Which communication trigger is the result of verifying compliance with project requirements?

a. gate review

b. project milestone

c. project change

d. project audit

2. Which project entities should have at least read-only access to all documents created during the Planning phase? (More than one answer may be correct.)

a. procurement vendors

b. project team members

c. project sponsor

d. project stakeholders

3.Which of the following changes is likely to alter the project’s schedule if approved?

a. A stakeholder is added.

b. A team member is added.

c. A team member has a higher rate of pay than expected.

d. A stakeholder identifies a new requirement.

4. Which of the following changes is likely to alter the project’s budget if approved?

a. A procurement will cost more to complete.

b. A procurement will take longer to deliver than expected.

c. A new stakeholder is added.

d. The project sponsor is unavailable for a gate review.

5. During project execution, a new project risk is identified. Which project entity should be notified once the risk management plan is updated?

a. project sponsor and project team members

b. project stakeholders and project team members

c. project sponsor and project stakeholders

d. project sponsor, project stakeholders, and project team members

6. Why should project milestones be noted on the project schedule?

a. to ensure that proper communication occurs

b. to ensure that dependent tasks start on time

c. to ensure that time is allocated for the milestone to be completed

d. to ensure that the project is reviewed by the CCB

7. Which communication trigger ensures that a dependent activity starts?

a. gate review

b. task initiation/completion

c. milestone

d. audit

8.During a project, the project managers from the different phases meet with the project sponsor to decide whether the project will proceed. What is this process called?

a. gate review

b. milestone

c. audit

d. change control process

9. Which project event may result in a business continuity response?

a. audit

b. change request

c. incident

d. approved change request

10. A project task cannot be started until its predecessor task finishes. Which type of task relationship is this?

a. start-to-start (SS)

b. start-to-finish (SF)

c. finish-to-finish (FF)

d. finish-to-start (FS)

Foundation Topics

While project communication happens on a daily or hourly (or even minute-by-minute) basis according to the project needs, certain types of project communication are formal and predictable, such as cost reports, status reports, and quality reports. Other types of communication may not be intuitively obvious, but they also need to occur to ensure that no hidden pitfalls derail stakeholder expectations.

As with planning risk responses, project managers must be prepared to communicate ordinary project updates while also knowing how to respond in worst-case scenarios. Communication triggers are events or conditions in the project that require communication with the project team and stakeholders. For the Project+ exam, project managers must understand communication triggers and target audiences, including audits, project planning, project changes, risk register updates, milestones, task initiation/completion, gate reviews, incident responses, and business continuity response.

Audits

Audits are part of the Monitoring and Controlling phase of a project. An audit verifies that project deliverables comply with the guidelines set forth in the project management plan, in order to validate the performance of the project. Audits are usually performed to validate a project’s scope, quality, and regulatory compliance, but they also can verify cost or schedule compliance, identify new risks, or determine whether a risk is about to occur.

Project audits offer two main benefits:

Obtaining tangible data about specific components, to determine how the project is aligning with its objectives

Motivating team members and stakeholders, who see audits as evidence of managerial oversight

Audit results should be analyzed carefully to determine whether the project is performing as expected. If any issues are discovered, they should be documented as part of the audit report. Based on the audit results, the project manager should work with the project team to identify any corrective actions that could improve issues identified by the audit.

When the audit report is completed, the project manager should distribute the results of that audit to the recipients listed in the project’s communication plan. Typically, these reports will be shared with project team members, the project sponsor, and any project stakeholders that request audit results. Communicating the audit results with the project sponsor and stakeholders allows them to analyze the results and provide any applicable feedback. Communicating the audit results with the project team members ensures that they understand any audit findings that may affect their project tasks or schedule. Audits are defined in the subsidiary plans of the project management plan: Quality audits are defined in the quality management plan, cost audits are defined in the cost management plan, and so on.

EXAMPLE: The project management plan for a manufacturing project includes regular audits to ensure that the parts being produced fit within certain design specifications and cost ranges. If the audit shows that none of these values are outside the required standards, the project manager sends a normal audit report. However, the communication plan includes an audit trigger that instructs the project manager to hold a meeting with certain team members if values fall outside the quality or cost specifications, to discuss what adjustments need to be made to the project to address these issues.

Project Planning

The majority of the project planning documentation is created during the Planning phase of a project. Because each of these documents is important to project success, project managers should ensure that all of the documents are stored in a central location and that individuals who need access to them can, at minimum, read the documents.

The project management plan describes how the project will be executed, monitored, and controlled. This document consolidates a number of subsidiary plans and baselines. Each of these documents has a specific purpose, as discussed in Chapter 1, “Project Properties and Phases.” Once each document is created, it is important to ensure that the recommended target audience receives or is granted access to the document (see Table 10-2). However, organizations and their project management office might need to customize the target audience for a document, based on the project and organizational requirements.

Table 10-2 Project Management Plan Components and Target Audiences

Component	Recommended Target Audience
Change management plan	Project sponsor and stakeholders, change control board, any project team members with change process roles
Communication plan	Project sponsor and stakeholders, any project team members with communication roles
Configuration management plan	Project sponsor and stakeholders, project team members
Cost baseline	Project sponsor, any project team members with budgetary roles
Cost management plan	Project sponsor and stakeholders, project team members
Human resource management plan	Project sponsor and stakeholders
Process improvement plan	Project sponsor and stakeholders, project team members
Procurement management plan	Project sponsor and stakeholders, procurement vendors, any project team members with procurement roles
Quality management plan	Project sponsor and stakeholders, any project team members with quality control/assurance roles
Requirements management plan	Project sponsor and stakeholders, project team members
Risk management plan	Project sponsor and stakeholders, project team members
Schedule baseline	Project sponsor and stakeholders, project team members
Schedule management plan	Project sponsor and stakeholders, project team members
Scope baseline	Project sponsor and stakeholders, project team members
Scope management plan	Project sponsor and stakeholders, project team members
Stakeholder management plan	Project sponsor, project team members

Because these documents are subject to change over the entire project life cycle, project managers should establish a version control process and should communicate with the appropriate individuals and groups when changes have been made in the documents.

Project Changes

A change request is a formal proposal to modify any document, deliverable, or baseline. Change requests are entered into the change log, which is a comprehensive list of changes requested during the project. The change log includes the date and time, cost, risk impacts, and other details of the change (see Figure 10-1 for an example). Changes may be requested for a variety of reasons, such as corrective actions, preventive actions, and repairs.

Figure 10-1 Example of a Change Log

Once the change is requested, the change control board (CCB), which usually consists of the project manager and other project team members as stated in the change management plan, meets to review the change request and decide whether to approve or reject the change. The disposition of the change request should be updated in the change log, and all approved change requests should be implemented by the appropriate project team member(s). The project manager, project team members, CCB members, and project sponsor will need to have access to the change log. The change may require updating appropriate project management plan components and project documents. If baseline changes are necessary, these changes should show only the changes from the current time going forward. Depending on which project components are affected, changes will need to be communicated with the appropriate personnel.

The project manager needs to control certain changes, including schedule changes, stakeholder changes, resource changes, and budget changes. No matter which type of change occurs, the project manager is responsible for ensuring that the change is properly documented and communicated to the appropriate project entities.

Schedule Changes

Schedule changes include any change requests that affect the project schedule, such as task delays, inaccurate task estimates, and procurement delays. When a schedule change has been approved, the project schedule baseline will need to be updated and milestones may have to be moved.

EXAMPLE: A project team member determines that several tasks are going to take longer than originally planned. Once the schedule change is approved by the CCB, the schedule baseline will need to be updated to reflect the new task durations for the affected tasks. This change would also affect any dependent tasks.

The project sponsor, project stakeholders, and project team members need to be notified each time schedule changes occur.

Stakeholder Changes

Stakeholder changes that occur in a project are of two different varieties. First, stakeholders, like project team members, may be removed from or added to a project. Second, stakeholders may make change requests that affect project scope, time, cost, quality, or procurements. When a stakeholder change has been approved, the appropriate project documents need to be updated.

EXAMPLE: A project stakeholder has left the company and been replaced by another stakeholder. In this case, the project manager will need to edit the stakeholder register and stakeholder management plan. The project sponsor and project team members will need to be notified about these changes.

EXAMPLE: A stakeholder has contacted the project manager to ask for a new requirement to be added to the project. This change request would need to be analyzed by the CCB. If approved, the change would need to be reflected in the requirements management plan. In addition, depending on the effects of the change, the project manager may need to update the cost baseline and/or schedule baseline. The project sponsor, project stakeholders, and project team members will need to be notified regarding the requested changes, even if they are not approved. This ensures that the requestor understands the change request resolution and the team members know not to implement the change request, even if requested privately at a later date.

EXAMPLE: A project team works from multiple locations, and team members often communicate with each other only via weekly project status video conferences. A project stakeholder requests a feature change in a new application that the team is developing. During the formal change control process, the change is denied. The next week, the stakeholder mentions the requested change during a call with one of the application developers. After the call, the developer decides that including this feature really would not add to the schedule, and she implements the code that would allow it. If the project manager had shared the change log with the entire team, all team members (including the application developers) would know that the change request was denied.

Resource Changes

Resource changes consist of any changes to project resources, such as changes in supplies, procurements, and personnel resources. When a resource change has been approved, the resource calendar, project schedule, schedule baseline, and other documents may need to be updated. If the resource change is related to personnel, the project manager should notify the project team and stakeholders. If the resource change is related to supply or procurement, the project manager only needs to notify the team members who are affected by the resource, and then only if the change affects project tasks.

EXAMPLE: A project team member must take an unexpected leave of absence, and a replacement team member has been allocated to the project. Tasks assigned to the original team member are reassigned to the new team member. If the new team member can complete work at the same speed as the original team member, the only update would be the resource assigned to the task. However, if the new team member completes work at a different speed, the task durations for the tasks assigned to the new team member will have to be adjusted, which also affects any dependent tasks. The project sponsor, project stakeholders, and project team members need to be notified that schedule changes have occurred.

EXAMPLE: A bulldozer has been allocated to complete the grading for a construction project. However, that particular machine is scheduled for repair during the five-day task for which the bulldozer will be needed. The project manager has two options: Delay the task that involves the bulldozer, or rent another bulldozer to prevent schedule delays. A task delay would require adjusting the schedule baseline, updating the team member who is responsible for the bulldozer, and notifying any team members who are responsible for dependent tasks. Renting another bulldozer would require adjusting the cost baseline, updating the project schedule to allocate the new bulldozer to the task, and informing the project sponsor of the budget change.

Budget Changes

Budget changes require decreases or increases in the project budget. A budget change may consist of increased procurement costs, decreased project team costs, increased task durations that affect project cost, decreases in the budget from the project sponsor, and so on. When a budget change has been approved, the cost baseline, project budget, and the cost management plan may need to be updated.

EXAMPLE: A project procurement is encountering higher costs than were originally estimated based on the vendor proposals. Once the CCB approves this budget change, the project manager would need to update the cost baseline, project budget, cost management plan, and procurement management plan.

Budget changes need to be communicated to the project sponsor and to stakeholders that want to be kept informed of the budget status. It is probably not necessary to share budget changes with all project team members, but project team members who have budgetary or procurement roles should be informed.

Risk Register Updates

The risk register includes all the identified positive and negative project risks. Events that may affect the risk register include changing the responsible party, changing a risk’s status, and adding newly discovered risks. When the change has been approved, the risk register should be updated with the new information.

EXAMPLE: The party responsible for a risk is leaving the project. Once the new responsible party is identified, the former responsible person’s name should be removed and the new person added. If a new risk has been discovered, it will need to be thoroughly analyzed and added to the risk register so that a risk response can be planned. The changes to the risk register and the risk response plan would then need to be communicated to the project’s sponsor, team members, and stakeholders.

No matter which type of risk register update occurs, it is the responsibility of the project manager to ensure that the change is properly documented and communicated to the appropriate project entities.

Milestones

As covered in Chapter 4, “Project Schedules,” a milestone is a significant project event indicating that a phase of the project work is complete. Even though milestones do not actually have their own durations, the project’s sponsor, stakeholders, and team members should be notified when milestones are met, missed, or moved so that all parties have a realistic view of the project’s status. For example, if the first 20% of work on a project should bring the project to its first milestone, the project manager must report on that milestone once the schedule shows that 20% of the work is done. Reporting whether the milestone was met (hit on time), exceeded (hit early), or missed (not yet hit) gives valuable insight into how well the project is performing.

Milestones are included at a high level in the project charter and are part of the project schedule. Milestones should be noted on the project schedule so that the project manager will know when to report the achievement (or failure) of a project milestone. If scheduled tasks slip, milestone dates may need to be adjusted.

Task Initiation/Completion

Throughout the project’s life cycle, task relationships control the initiation and completion of tasks as part of the project schedule. When two or more project tasks share a dependency or logical relationship, a predecessor activity comes before any dependent activities, and a successor activity comes after the activity on which it is dependent.

Project task relationships are defined in one of four ways:

Finish-to-start (FS): The predecessor activity must finish for the successor activity to start.

Finish-to-finish (FF): The predecessor activity must finish for the successor activity to finish.

Start-to-start (SS): The predecessor activity must start for the successor activity to start.

Start-to-finish (SF): The predecessor activity must start for the successor activity to finish.

The FS relationship is the most common relationship in most projects.

Because many project tasks may involve different project team members, it is important to ensure that the project team is notified when tasks start and finish. The completion of a task should always be a communication trigger. Notification ensures that team members who are working on dependent successor tasks can start their tasks on time.

It is important to start and finish tasks on the critical path on time, in order to prevent project delays. Monitor those particular tasks closely.

No matter whether tasks are starting or finishing, and whether or not they are on the critical path, the project manager is responsible for ensuring that each task’s initiation and completion are properly documented and communicated to the appropriate project entities.

Gate Reviews

To understand gate reviews, project managers must first understand the phase-gate model, also known as phase-gate process or stage-gate process. Most projects consist of a single pass through all of the project life cycle processes. In a phase-gate project, an initiative or project is divided into stages or phases, separated by gates. Each gate completes that phase of the project life cycle and then undergoes review before the project moves on to the next phase.

EXAMPLE: A large, multi-story construction project uses a phase-gate process to subdivide processes into individual gates to ensure project management success. Each separate facet is its own project that runs through the phases, with gate reviews occurring as each portion is finished. The site preparation is one project gate, the concrete work is another project gate, the steel work is another project gate, and so on. In this manner, the overall project is more manageable, with each project manager being responsible for only his or her individual gate.

In projects with a phase-gate design, individual gates have relationships similar to the task relationships discussed earlier. Gate reviews are completed as detailed on the project schedule to clear the project to continue. At a gate review, the project managers and project sponsor meet to determine whether to continue the project. Gate quality-control checks are also performed at this time. Project sponsors make go/kill decisions based on criteria defined during the Planning phase of each gate.

The project manager is responsible for ensuring that the appropriate entities are aware of the gate review and participate in gate review meetings as necessary. In most projects, gate reviews are the sole responsibility of the project sponsor, with project managers participating to provide project details should questions arise. Once a project gate review is complete, the project manager must ensure that the gate review is documented and communicated with the appropriate project entities, usually the project stakeholders and project managers of the other gates.

Incident Responses and Business Continuity Responses

An incident is an event in a project that could lead to a disruption in the project. If not properly managed, an incident can escalate into an emergency, a crisis, or a disaster. Incident management is the process of limiting how much an event can disrupt a project.

Business continuity is the capability of a project to continue at acceptable levels following a disruptive incident. Most disruptive incidents for a project should be anticipated and documented during risk planning, and all documented risks should have a planned risk response. If an incident occurs, the project manager should first consult the risk management plan to see whether the incident was anticipated. If not, the project manager will need to work quickly with project team members to determine a business continuity response.

EXAMPLE: A power outage occurs at a building site. If this risk was anticipated, the risk planning for the project would have ensured that an alternate power source, such as a generator, would be available. If the risk was not anticipated, the project manager may need to obtain an alternate power source. If no other power source is available, stopping project tasks at the construction site temporarily may be necessary until power can be restored.

Business continuity might require including plans for contacting civil authorities and informing the public. In some cases, the organization might need to notify dependent organizations, such as when a cloud deployment is a victim of an attack. The point is to anticipate such events and have a plan in place in case the event occurs. Nothing is worse than a security incident or some other event that leaves the project team not knowing what to do because nobody made a plan.

EXAMPLE: An application development project relies on a central server to store developed code, and a hard drive on that server crashes. If this risk was anticipated, the risk planning probably would have ensured that some sort of fault tolerance was implemented on the server and that data backups were completed. If the risk was not anticipated, the data on the failed drive must be recovered. Either case will involve some downtime until the data can be restored. During this server downtime, project team members could work on project tasks that do not require that server resource. The project manager will need to communicate schedule changes to the project stakeholders and team. Any data that is lost should be documented, and the documentation should be provided to the team members so that they can look for copies on their local computers. Finally, the project manager will need to communicate with the project stakeholders and team members about which parts of the project were affected by the server crash.

Whether or not business continuity response was part of the risk management plan, the project manager is responsible for ensuring that the project’s sponsor, stakeholders, and team members are notified of the incident, the business continuity response, and the expected downtime. It may be necessary to postpone project tasks until the response is complete and operations return to normal.

Exam Preparation Tasks

As mentioned in the section “How To Use This Book” in the Introduction, you have several choices for exam preparation: the exercises here; Chapter 15, “Final Preparation”; and the Pearson Test Prep practice test software online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 10-3 provides a reference of these key topics and the page number on which each begins.

Table 10-3 Key Topics for Chapter 10

Key Topic Element	Description	Page Number
Section; list; example	How audits trigger project communications	199
Section; Table 10-2	Target audiences for communications about project management plan components	200
Section; Figure 10-1	How project changes trigger project communications	201
Section; example	How schedule changes trigger project communications	203
Section; examples	How stakeholder changes trigger project communications	204
Section; examples	How resource changes trigger project communications	204
Section; example	How budget changes trigger project communications	205
Section; list	How predecessor and successor task relationships trigger project communications	207
Section; example	Overview of the phase-gate model process and gate reviews as project communication triggers	207
Section; examples	Overview of incident responses and business continuity responses as project communication triggers	208

Define Key Terms

Define the following key terms from this chapter and check your answers in the Glossary:

audit

change request

change log

predecessor activity

successor activity

finish-to-start (FS) relationship

finish-to-finish (FF) relationship

start-to-start (SS) relationship

start-to-finish (SF) relationship

phase-gate model

gate review

incident

incident management

business continuity

Review Questions

The answers to these questions appear in Appendix A. For more practice with sample exam questions, use the Pearson Test Prep practice test software online.

1. You have been hired to take over as project manager for a new research project. You need to assess the project to ensure that it is complying with project requirements and quality metrics. What should you do?

a. Place a formal change request.

b. Perform a gate review.

c. Update the risk register.

d. Perform a project audit.

2. Which of the following communication triggers might require communication with a project vendor?

a. audit

b. procurement change request

c. budget change request

d. risk register update

3. For your company’s current project, the project manager discovers that creating the project deliverables is taking significantly longer than estimated. After discussing this issue with the project sponsor, a new team member is hired. Which project communication trigger will most likely occur as a result of these actions?

a. gate review

b. audit

c. stakeholder change

d. budget change

4. Which of the following is an example of a stakeholder change?

a. new project requirement

b. increase in procurement cost

c. gate review

d. milestone completion

5. For a new printing project, the project sponsor requests upgrading to a higher-quality vinyl that is not currently in stock. You submit a change request. Which project entity must approve this change before it is communicated to the project team?

a. project manager

b. project stakeholders

c. project sponsor

d. CCB

6. Which communication trigger occurs when a procurement contract is for a higher dollar amount than estimated?

a. schedule change

b. stakeholder change

c. budget change

d. resource change

7. You are the project manager for a new construction project. During project planning, you learn that a backhoe owned by the project sponsor can be used for the project. However, two days before you need the backhoe, you find out that it is being repaired, and you must rent a backhoe instead. The backhoe rental is approved. Which communication triggers will be affected? (Choose two.)

a. resource changes

b. schedule changes

c. budget changes

d. stakeholder changes

8. Which project entities should most likely receive communications regarding the completion of a task C1 that has a start-to-finish (SF) relationship with task C2?

a. the project team member(s) responsible for task C2

b. the project team member(s) responsible for task C1

c. the project stakeholders

d. the project sponsor

9. Which of the following describes a gate review?

a. a significant event that is part of the project schedule but does not actually have a duration

b. a meeting held to determine whether a project will continue

c. the process of verifying compliance with the project guidelines and validating the performance of the project

d. an event in a project that could lead to a disruption in the project

10. Which communication trigger often results in a business continuity response?

a. milestone

b. audit

c. incident

d. gate review