CHAPTER 8

Program Management Infrastructure

This chapter starts by describing how a program manager uses procurement in the delivery of program benefits. The chapter examines program infrastructure, including systems and tools needed to manage a program effectively and describes how to build and maintain a program management plan—a key document that ensures program alignment with the organizational strategy and on-time and on-budget benefits delivery. The chapter analyzes tools for program monitoring and periodic evaluation. It also defines risks and examines risk management and escalation mechanisms. The chapter concludes by describing the program change process, quality control process, and program communication. This chapter can be used as a desktop manual, as it includes multiple program management tools and templates.

The chapter includes the following sections:

• Program procurement planning and execution;
• Infrastructure overview;
• System requirements for effective program execution;
• Program management planning;
• Program monitoring and periodic evaluation;
• Program risk management;
• Change control processes;
• Quality control processes; and
• Program communication.

Program Procurement Planning and Execution

One of the many tools a program manager uses to deliver program benefits is the procurement of products and services. Program procurement management addresses the activities necessary to acquire products and services. Program procurement management addresses specific procurement needs that are unique to managing the overall program and the needs of the constituent components. We will use the call center's process improvement program example. During the benefits delivery phase, it was discovered that project two, decrease call response time, required an additional scope. Additional scope includes research around call response time for different call types. It was determined that the research department would perform this task. In this case, the program will procure this research from the research department.

Program procurement includes a few activities that take place during all phases of the program life cycle. Some activities take place on a program level and some on component levels. The procurement process includes:

• Program procurement planning occurs on a program level and takes place during the program definition phase;
• Program procurement administration occurs on the component level with oversight on the program level, and takes place during the program benefits delivery phase; and
• Program procurement closure occurs on the component level with oversight on the program level, and takes place during the program closure phase.

Program Procurement Planning, Administration, and Closure

Program Procurement Planning

Program procurement planning is performed on the program level during the definition phase of the program. A program manager assesses resource requirements for each component and the program as a whole. A program manager assesses commonalities and differences for various procurement activities across the program scope and determines:

• Whether some of the common needs of several individual components could be met with one overall procurement rather than several separate procurement actions;
• The best mix of the types of procurement contracts planned across the program; at the project level, a particular type of contract may be more optimal for that same procurement when viewed at the program level;
• The best program-wide approach to competition; the risks of sole source contracts in one area of the program could be balanced with the different risks associated with full and open competition in other areas of the program; and
• The best program-wide approach to balancing specific external regulatory mandates; for example, rather than setting aside a certain percentage of each contract in the program to meet a small business mandate, it may be more optimal to award one complete contract to achieve the same mandate.¹

At this stage, a program manager may analyze alternatives. After all information is gathered, a program manager drafts a program procurement plan.

Program Procurement

Procurement should be a centralized function within a program, and it should be conducted on a program level. A program manager sets up procurement standards for the components. The standards include proposal evaluation criteria, qualified seller and buyer lists, and purchase agreements. A program manager establishes proposal evaluation criteria that will be used to evaluate proposals and places requests for quotes (RFQ), requests for proposals (RFP), and invitations for bid (IFB).

Program Procurement Administration

Procurement administration starts after contracts are awarded and performed on the component level. Contract administration and closure are conducted on the component level. Components ensure that contract deliverables are produced on time, deadlines are met, and established quality standards are met. Component project managers report status to a program manager.

A program manager maintains oversight of the procurement administration on the program level to ensure that program benefits are realized on time and on budget, and that the quality standards are met across the program.

Program Procurement Closure

Contract closure occurs during the program procurement closure phase and takes place on the component level. After all contract deliverables are produced, component project managers close contracts. At the time of the contract closure, component project managers ensure that all deliverables were produced, that there are no outstanding contract issues, and that all payments were made.

A program manager maintains oversight of the procurement closure on the program level to ensure that program benefits are realized on time and on budget, and that the quality standards are met across the program.

Infrastructure Overview

Program infrastructure provides systems and tools to manage the program effectively. A system allows for managing a program management plan and tracking program progress, assigning resources to tasks and analyzing workloads, and managing a budget. Program tools include a status report, a risk tracking mechanism, and financial tools. A program manager can perform program operational tasks quicker by utilizing systems and tools. Thus, program infrastructure enables a program manager to lead a program, deliver to the strategic objectives, and become a trusted advisor and subject matter expert.

Program infrastructure may vary significantly among organizations, depending on where organizations operate along the program management continuum. Different use of program management in project-oriented and program-oriented organizations determines the need for the program infrastructure. As the program management function is limited in administration-focused and facilitation-focused organizations, the program execution requires a limited program infrastructure. The need for a more complex program infrastructure increases as organizations move to the right along the program management continuum. As the program management function expands in integration-focused and business-focused organizations, program execution requires a more complex program infrastructure.

Program infrastructure has similarities and differences with the project infrastructure. Similar to projects, programs track budget and actuals, resources, changes, status, and risks. Differently from projects, programs require aggregation of components on a program level. Organizations frequently have a project-centric infrastructure. However, a program manager needs to have a program-centric infrastructure to optimize program operational management and allow sufficient time to a lead a program. The absence of a program-centric infrastructure creates an issue in multiple areas, including budget and actuals, variance analysis, resource management, status report production, issue and risk tracking, and escalation. We will examine the effects in each area in the subsequent sections of this chapter.

Program infrastructure supports program execution throughout the entire program life cycle. During the definition phase, utilizing a system and tools, a program manager develops a program management plan, assigns resources, and develops an initial budget. During the benefits delivery phase, utilizing a system, a program manager maintains a program management plan and tracks program progress. In the program management plan, a program manager also monitors resources’ workloads. Using various program tools, a program manager tracks and analyzes program spending, produces status reports, and tracks risks. During the program closeout phase, using program infrastructure, a program manager finalizes the program management plan, off-boards resources, completes the final status report, and closes risks.

System Requirements for Effective Program Execution

System infrastructure is a key element that allows for sustaining the program management discipline. It enables a program manager to lead a program by way of significantly increasing efficiency and ensuring the quality of program execution through automation and consistency around program management plan execution.

Program system support should include an aggregated project plan that allows aggregating project information into a program. It can either be Microsoft Project, spreadsheets, or databases. The system should have the ability to aggregate from multiple projects into program tasks and milestones.²

Aggregation of multiple components into a program includes more than just adding or linking components. It includes managing interdependencies between components, managing program-wide milestones, managing program costs, escalating component risks and managing them on a program level, coordinating and prioritizing resources across components, and tracking program operational management tasks.

Project management software can help plan, organize, and manage resource pools and develop resource estimates. Depending on the sophistication of the software, it can manage estimation and planning, scheduling, cost control and budget management, resource allocation, collaboration software, communication, decision making, quality management, and documentation or administration systems. Today, numerous PC- and browser-based project management software and contract management software solutions exist, and are finding applications in almost every organization.

Project management software typically has the following key features:

• Schedule that includes sequence project activities;
• Activity duration, start and finish dates;
• Activity percent completion;
• Resource assignment to the project activities; and
• Project critical path.³

Using project management software, a project manager can obtain the following information about a program and components:

• Task completion, in percent;
• Remaining time needed to complete tasks, in days;
• Tasks on, ahead, or behind schedule;
• Resource workloads;
• Overutilized and underutilized resources;
• Program and component risks; and
• Task costs.

Project management software almost always includes various reports that allow tracking task execution, resource workloads, and costs, and identifying risks.

Project management software can be desktop- or web-based. Desktop software is a single-user application that runs on the desktop of an individual user. Desktop software only houses the project management plan and does not have the functionality to support status reports and risk tracking. Desktop software also has a limitation around information sharing, as information can only be shared by exchanging a file with other users.

Web-based software is a multiuser application that can be accessed through a web browser. Web-based software houses not only a project management plan, but also a status report, and has a risk tracker. Web-based software removes the information sharing limitation that desktop software has.

There are many project management systems currently available, including commercial and homegrown products. Microsoft Project is one of the most widely used desktop project management systems. Microsoft Project is a project management software program, developed and sold by Microsoft, that is designed to assist a project manager in developing a plan, assigning resources to tasks, tracking progress, managing the budget, and analyzing workloads.⁴

Microsoft Office Project Server is one of the most widely used web-based project management systems. Microsoft Office Project Server is a project management server solution made by Microsoft. It uses Microsoft SharePoint as its foundation, and supports interface from either Microsoft Project as a client application, or by web browser connecting to its Project Web App (PWA) component.⁵

As was mentioned earlier, many organizations have project-centric and not program-centric systems. One of the main limitations that the project-centric system has for program management is an absence of a mechanism to aggregate component tasks and milestones into a program, and to escalate risks from components to a program level.

System requirements to effectively manage a program should include the following functionality:

• Manage links and interdependencies between components;
• Aggregate component management plans to a program management plan;
• Coordinate and prioritize resources across components;
• Manage program costs;
• Consolidate component status reports to a program status report;
• Escalate component risks to a program level;
• Track program operational management tasks; and
• Develop program reports that allow for tracking task execution, resource workloads, costs, and risks.

The industry-leading project management software program and project management server solutions, Microsoft Project and Microsoft Office Project Server, are both project-centric. The majority of the functionality that these software and server solutions have is geared for managing a project and not a program. They do not have the program-specific functionality described above.

In Microsoft Project, a program management plan may be built using one of two approaches:

• Build a megaprogram management plan where components are included as subplans; or
• Build separate plans and link them using the Microsoft Office “link projects” functionality.

The first option can be executed by creating a megaproject in Microsoft Project and adding multiple work streams to it. A megaproject becomes a program and multiple work streams become components.

Microsoft Project allows linking projects to create a master project. To help keep a large project more organized, you can link several project files together to create a master project/subproject arrangement (also known as external dependencies). For example, a construction master project might have subproject files for plumbing, electrical, and carpentry work.⁶ Similar to Microsoft Project, Microsoft Office Project Server allows linking multiple projects into a master project. This is done by creating a master project and linking subprojects to it.

Both approaches, creating one large project with multiple work streams and linking multiple projects into a master project, do not allow the full aggregation necessary for a program management plan. A program manager may encounter multiple issues, including a lack of mechanisms to track cross-functional tasks, managing cross-functional resources, and shifting resources from one component to another.

When linking multiple projects into a master project, information may be duplicated and not aggregated. For example, if you link projects that use the same resources, you will create duplicate resource names, including name, pay rate, and resource calendars, which could be confusing.⁷

System Usage During Program Execution

A system is being used during the entire program life cycle. A system can be Microsoft Project, Microsoft Office Project Server, a spreadsheet, or a database.

Program Definition Phase

During the definition phase, a program manager develops a program management plan. The plan contains tasks and milestones for the components and the program as a whole. This is an initial version of the plan, as a program manager does not have complete information about program components during the program definition phase.

A program manager defines the structure and sets up a program status report that tracks components and program status. Based on the tools available, a status report can be housed on the Microsoft Office Project Server that has a built-in feature for the status report. The status report can be prepared in Microsoft Word or PowerPoint, and shared on a program site or a shared drive (e.g., on the SharePoint site).

A program manager defines and sets up a risk-tracking mechanism. Based on the tools available, risks can be tracked in the Microsoft Office Project Server, in Excel, or on a SharePoint site. Both Microsoft Office Project Server and SharePoint sites have built-in features that allow tracking risks.

A program manager identifies or sets up reports that will be used to analyze milestones and the task schedule, program and completion risks, program budgets, and more. These reports will also be used for updates to the program management governance board and program team.

Program Benefits Delivery Phase

During the benefits delivery phase, a program manager leads program execution, ensuring it is on time and within budget, by executing a program management plan, preparing status reports, monitoring program reports, and tracking risks. A system plays a vital role during this phase, as it houses some or all of the program documents, including a program management plan, program reports, status reports, and risks.

This phase is an iterative phase of the program. During this phase, a program manager updates the program management plan and budget with component information. As the program manager acquires program resources, he or she assigns resources to the tasks. The project creates budgets based on assignment work and resource rates. As resources are assigned to tasks and assignment work is estimated, the program calculates the cost, equal to the work times the rate, which rolls up to the task level and then to any summary tasks, and finally, to the project level. Resource definitions (people, equipment, and materials) can be shared between projects using a shared resource pool. Each resource can have its calendar, which defines what days and shifts a resource is available. Resource rates are used to calculate resource assignment costs, which are rolled up and summarized at the resource level. Each resource can be assigned to multiple tasks in multiple plans and each task can be assigned multiple resources, and the application schedules task work can be based on the resource availability as defined in the resource calendars. All resources can be defined in the label without limit. Therefore, it cannot determine how many finished products can be produced with a given amount of raw materials. This makes Microsoft Project unsuitable for solving problems of available materials’ constrained production. Additional software is necessary to manage a complex facility that produces physical goods.⁸

Program Closure Phase

During the program closure phase, a program manager ensures that the program delivered all benefits and that program work fully transitioned. A system assists with this work, as a program manager uses the program management plan to confirm that all benefits were delivered as planned and a program was transitioned. A program manager marks all tasks and milestones in the program management plan as complete and runs program reports to perform final analysis around program execution on time and on budget. A program manager also produces a final status report and closes all risks.

Program Management Plan

A program management plan is a key program document. The plan is used during the entire program duration; however, it serves different purposes during each phase. A program management plan's main purpose is to ensure program alignment with the organizational strategy. As was mentioned earlier, some organizations do not follow through on the execution of the strategic plan, which then does not fully cascade down to the program level. During the program definition phase, to ensure program alignment with the organizational strategy, a program management plan should use a strategic plan as an input document.

Sometimes, organizations do not establish tracking mechanisms to ensure on-time and on-budget program delivery. During the benefits delivery phase, a program manager should establish mechanisms to ensure the program's timely execution. Mechanisms should include program reports that allow for tracking timely task execution, full resource utilization, and on-budget delivery.

Upon program completion, some organizations do not fully incorporate benefits realized through program execution and do not align the ongoing operations with implemented changes. During the program closure phase, using the program management plan, a program manager ensures a smooth transition of the delivered program benefits to ongoing operations.

A program management plan can be built using one of the two approaches, activity-based and resource-based. A resource-based approach to building a program management plan assigns resources to tasks, estimates hours of work based on task duration, and calculates program costs such as the product of hours multiplied by resource rates. An advantage of this approach is that it allows for building a full set of program tasks and accurately estimates their duration and cost. A disadvantage of this approach is the time required to build a list of tasks and identify and assign resources to them. For example, adding resources to the plan in Microsoft Project may be a time-consuming and laborious task. Another disadvantage of this approach is that, initially, the program management plan may be incomplete, as the full set of the program components may not be known early in the program life cycle.

An activity-based approach to building a program management plan uses tasks, duration, and cost from a similar program or a component. This information can be obtained using programs executed in the past or industry best practices. An advantage of this approach is that it allows obtaining tasks, duration, and cost information early. And, using historical knowledge from other programs or industry best practices, this approach allows creating a more comprehensive program management plan early in the program life cycle when a full set of components of the current program may not be known. A disadvantage of this approach is that it may have discrepancies in the tasks, duration, and cost, as other programs or industry best practices may not be the same as a current program.

Program cost can be calculated using one of the two approaches, resources’ hourly rates that calculate task costs and historical information that is used to estimate task costs. Calculating program costs using the resources approach includes adding resources in the program management plan using the following steps:

• Click the View tab. In the Resource Views group, click Resource Sheet;
• In the Resource Name field, type work, material, or generic resource name;
• If you want to designate resource groups, then in the Group field for the resource name, type the name of the group;
• Specify the resource type:
  • To specify that this resource is a work resource, in the Type field, click Work;
  • To specify that this resource is a material resource, in the Type field, click Material. In the Material Label field, type the label (e.g., yards, tons, or boxes) for the resource;
  • To specify that this resource is a cost resource, in the Type field, click Cost;
• In the Max Units field for the resource, type the number of total units of this resource that is available for this project. The maximum units’ value specifies how much of this resource is available for this project (e.g., part time or multiples). For example, if you have a resource who is available for your project two days a week, you can enter a maximum units’ value of 40%. You can use maximum units to specify multiple availabilities of a resource designation. For example, suppose you have a resource named Engineers, a single resource that represents three individual engineers on your team. You can enter the maximum units for Engineers as 300%. You can schedule all three engineers for full-time work at one time without the Engineers resource being over-allocated. You can enter maximum units as a percentage (e.g., 50%, 100%, 300%), or as a decimal (e.g., 0.5, 1, 3).
• To create a budget resource, select the resource, right-click the resource name, and then click Information. Select the Budget check box.

You can add a work resource and associated information by using the managing application programming interface (MAPI) email address book, from the Active Directory, or from Microsoft Project Server. Click the Resource tab, and in the Insert group, click Add Resources. Click Build Team from Enterprise (Project Professional only), Active Directory, or Address Book.⁹

A program management plan structure should include all parameters necessary to track successful program benefits execution and effectively communicate program status to the program governance board and program team. The program management plan may include the following columns: program time line, task order number, work breakdown structure (WBS), task name, task percent complete, task duration in days, start date, finish date, predecessor activity, resources, actual start date, actual finish date, and Gantt chart.

A time line is a way of displaying a list of events in chronological order, sometimes described as a project artifact. It is typically a graphic design showing a long bar labeled with dates alongside itself and usually events labeled on points where they would have happened.¹⁰ In the program management world, a program time line is a useful tool to get a program-wide view of critical task duration and milestone dates. It is also a communication tool to provide status updates to the program governance board and the program team. To add a task or a milestone to the time line, right click on the task and choose Add to time line in the drop-down box.

A task order number is a number in the leftmost column that lists task numbers in order starting with one. Typically, a program management plan is large and includes hundreds of rows. A task order number helps quickly find a task and is used to list a predecessor activity for the current task.

The work breakdown structure (WBS) column shows a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.¹¹ It is a tree structure, which shows a subdivision of effort required to achieve an objective (e.g., a program, project, and contract).¹²

A task name displays the name of a task. It is a text box that allows typing any text, adjusting fonts, and applying formatting. A task can be an independent task, a summary task, or a subtask. A summary task has subtasks underneath it and shows their combined information. To create a subtask in the Gantt Chart view, select the task you want to turn into a subtask, then click Task > Indent.

The task percent complete column shows partial or full completion of a task in a percent value. Based on task percent complete, Microsoft Project and other systems calculate component and program percent complete to date. It is a very useful measure of the components and the overall program's progress.

The duration column shows the total number of work periods required to complete an activity or work breakdown structure component, expressed in hours, days, or weeks.¹³ Duration is calculated as a sum of the business days between task start and finish dates.

A start date column displays the first day when a task execution is scheduled to start. It serves as a baseline for a comparison with a task actual start date. A task may start on, ahead, or later than a scheduled start date. If a task starts ahead or later than scheduled, it leads to a variance between a start and actual start dates.

A finish date column displays the last day when a task execution is scheduled to complete. It serves as a baseline to compare with an actual finish date. A task may finish on, ahead, or later than a scheduled finish date. If a task finishes ahead or later than a scheduled finish date, it leads to a variance between a finish and actual finish dates.

A predecessor activity column shows an activity that logically comes before a dependent activity on a schedule.¹⁴ Predecessor activity lists a task or tasks that must be completed before the start of a current task. In Microsoft Project, predecessor activities are listed as task order numbers separated by a comma.

A resources column lists program or component resources. Resources are typically people included in your project plan, whether or not they are assigned to tasks.¹⁵ Resources can be broken into three categories, enterprise resources, non-enterprise resources, and generic resources. An enterprise resource is part of the list of resources for the whole organization; therefore, each of these resources can be shared across multiple projects. Typically, the list of enterprise resources is managed by an administrator, and each project manager adds these resources to their projects as needed. A non-enterprise resource, or local resource, is not part of the list of resources for the whole organization. No other project manager can use your non-enterprise resources in their projects. Generic resources are used to specify the staffing requirements for a project, such as carpenters and developers, or a team of resources.¹⁶

An actual start date column displays a date when a task starts. As was described above, a task may start on, ahead of, or later than a scheduled date. A variance that compares actual and scheduled task start dates allows for determining if a task started before or later than scheduled. If a task started ahead of schedule, a program manager needs to decide on the early start of a subsequent task. And if a task started later than scheduled, a program manager needs to prepare a mitigation plan to ensure that a subsequent task will start on schedule.

An actual finish date column displays a date when a task is completed. As was described above, a task may finish on, ahead of, or later than a scheduled date. A variance that compares actual and scheduled task finish dates allows for determining if a task is finished before or later than scheduled. If a task is finished ahead of schedule, a program manager needs to decide on an early start of a subsequent task. And if a task is finished later than scheduled, a program manager needs to prepare a mitigation plan to ensure that a subsequent task will start on schedule.

A Gantt chart is a bar chart of schedule information where activities are listed on the vertical axis, dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed according to start and finish dates.¹⁷ A Gantt chart shows all program and component tasks durations, milestones, and interdependencies.

A program management plan is developed at the component level and is aggregated at the program level. It includes component and subprogram plans as well as program operational management activities. At the component level, a program management plan facilitates management of program scope, costs, schedule, resources, and risks. At the program level, a program management plan facilitates interaction with components to manage changes and mitigate risks and enables component alignment to deliver program benefits.

Each component has an associated component management plan. A component management plan may include a project management plan, a transition plan, an operational plan, a maintenance plan, or another type of plan depending upon the type of work under consideration. The appropriate information from each component plan is integrated into the associated plan for the program. This includes information used by the program to help manage and oversee the overall program.¹⁸

The program management plan is utilized differently in each phase of the program life cycle. A program manager builds the plan during the program definition phase, updates it during the program benefits delivery phase, and closes it during the program closure phase. Using the call center's process improvement program, we will illustrate the program management plan evolution during the program life cycle. All definitions stated above will be graphically illustrated in the program management plan figures presented in the next sections.

Program Definition Phase

During program preparation, a subphase of the program definition phase, a program manager develops a program management plan. Input documents to the plan include a strategic plan, a business case, a program charter, a program business case, a program road map, environmental analysis, and other outputs from the formulation subphase of the program definition phase. The plan may include components’ management plans that are needed to achieve desired organizational benefits. And, as not all components’ information may be known during the program definition phase, the components’ management plans may initially include some, but not all, information.

We will use the call center's process improvement program example. The program includes four components—subprogram one that includes projects one and two, project three, and program operational management. The program is scheduled to start on 3 October 2016 and end on 29 September 2017.

• Subprogram one includes projects one and two. The projects are executed consecutively. Subprogram one is scheduled to start on 3 October 2016 with the start of project one. Subprogram one is scheduled to end on 31 March 2017 with the completion of project two:
  • Project one: Improve call response quality has a duration of three months. It is scheduled to start on 3 October 2016 and end on 30 December 2016. It has multiple resources, project manager one and project team one;
  • Project two: Decrease call response time has a duration of three months. It is scheduled to start on 2 January 2017 and end on 31 March 2017. It has multiple resources, project manager two and project team two.
• Project three: Implement projects one and two has a duration of six months. It is scheduled to start on 3 April 2017 and end on 29 September 2017. It has multiple resources, project manager three, project team three, and call center directors; and
• Program operational management has a duration of twelve months, during an entire program life cycle. It is scheduled to start on 3 October 2016 and end on 29 September 2017. It has one resource, a program manager.

If we use an approach of developing a megaprogram management plan where the subprogram and projects are included as subplans, the initial program management plan will have a structure that is shown in Figure 8-1. The section on top of the program management plan represents a program time line. The plan includes the following columns, descriptions of which were given in the previous section: task order number, WBS, task name, percent complete, duration, start date, finish date, predecessor, and resources.

A task can be scheduled either manually or automatically. Manually scheduled tasks have a user-defined start, finish, and duration values. The project will never change their dates, but may warn you if there are potential issues with the entered values. Automatically scheduled tasks have start, finish, and duration values calculated by Microsoft Project based on dependencies, constraints, calendars, and other factors.¹⁹

The baseline is the approved version of a work product that can be changed using formal change control procedures and is used as the basis for comparison to actual results.²⁰ Baseline plays an important part in measuring program performance. Throughout the program benefits delivery phase, a program manager calculates schedule and cost variances to compare baseline to actual schedule and cost, and determine if the program is on schedule and budget. Various types of program management software allow setting a baseline. In Microsoft Project, to set the baseline, a program manager needs to click Project > Set Baseline > Set Baseline.

The project critical path is the sequence of activities that represents the longest path through a project, which determines the shortest possible duration.²¹ Critical path allows calculating the shortest and absolute required time to execute a project. In Microsoft Project, to calculate a component and a critical program path in the context of all tasks, a program manager needs to click View > More Views > Detail Gantt > Apply. To view only critical tasks, a program manager needs to click View > Gantt Chart > Critical in the filter list, as the filter list by default shows all tasks.

Just like projects, programs have a critical path, which goes through component critical paths. The program critical path allows identifying critical components, the execution of which is essential for program success. If a program is experiencing a delay due to a component's execution actual time being longer than scheduled or a resource constraint, a program manager needs to shift resources from non-critical to critical components.²²

The program critical path can serve as an implementation checklist, as it lists all critical tasks without the completion of which a program cannot be executed. An implementation checklist defines the steps required to implement the end state in this specific environment successfully.²³ The implementation checklist may also be referred to as a program readiness checklist.

The application creates critical path schedule, and critical chain and event chain methodology; third-party add-ons also are available. Schedules can be resource-leveled, and chains are visualized in a Gantt chart. Additionally, Microsoft Project can recognize different classes of users. These different classes of users can have differing access levels to projects, views, and other data. Custom objects, such as calendars, views, tables, filters, and fields are stored in an enterprise global, which is shared by all users.²⁴

The call center program management plan shown in Figure 8-1 is built using a megaprogram management plan approach, wherein the plan components are listed as subprojects in one megaprogram management plan. In Microsoft Project, a program management plan can also be built by creating component management plans in separate Microsoft Project files and linking them to a program management plan.

Once component management plans are built, a program manager needs to store them in the same folder or a shared directory, for example, a SharePoint site. This step is necessary for the Microsoft Project link project plan function to work. A program manager consolidates component management plans into a program management plan using the Microsoft Project link plans function, following these steps:

• Create separate project files for each component, then open or create the project file that you want to be the master project;
• In the master project, click View > Gantt Chart;
• In the Task Name field, click the row below which you want to insert the subproject;
• Click Project > Subproject;
• Click the Project ribbon tab to show the Insert subproject command;
• In the Insert Project box, select the subproject you want to insert;
  • To insert multiple subprojects, hold down Ctrl and click the subprojects in the order that you want to insert them;
  • In most cases, you will want to leave the Link to Project box checked, so that changes in the subproject are reflected in the master project, and vice-versa. But if you just want to copy the subproject into the master project without the files being dynamically linked, uncheck the box; and
• To insert a project in read-only format, click the arrow on the Insert button, and then click Insert Read-Only. Inserting a project read-only creates a link between the two projects, but prevents you from updating the subproject from within the master project. If you update the subproject file directly, however, its changes are reflected in the master project. The Insert Read-Only option is only available when the Link to Project box is checked.²⁵

To illustrate how to build a program plan using the Microsoft Project link plans function, we will use the call center's process improvement program as an example. The program includes three major components, subprogram one that includes projects one and two, project three, and program operational management. We will build individual component management plans for each component and store files in the same directory, folder, or shared drive. We will then create a program plan file. And, using the link plans function, we will link all component management plans into one program plan, as shown in Figure 8-2.

The plan includes the following columns: task order number, indicator, task mode, task name, duration, start date, and finish date. The indicators column shows that the component management plans are linked to the program management plan. The task mode column shows if a task is scheduled manually or automatically.

Manually scheduled tasks have user-defined start, finish, and duration values. Manually scheduled tasks are noted by a green pin sign in the task mode column. Duration of the manually scheduled tasks is set as a text value, for example, today or tomorrow. Manually scheduled tasks are not visualized in a Gantt chart. Automatically scheduled tasks have start, finish, and duration values calculated by Microsoft Project based on dependencies, constraints, calendars, and other factors. Automatically scheduled tasks are noted by a blue bar sign in the task mode column, as shown in Figure 8-2. Duration of the automatically scheduled tasks is set as a number value, for example, 130 days. Automatically scheduled tasks are visualized in a Gantt chart.

Once component management plans are linked to the program management plan, updates to the component management plans are automatically processed in the linked program management plan. To view component management plans, expand each plan by clicking on an arrow at the start of the task name.

Program Benefits Delivery Phase

As was mentioned previously, program planning has a significant element of uncertainty. A full set of program components is not known during the program definition phase, when a program management plan is initially developed. That is why program management plan development is an iterative activity.

During the program benefits delivery phase, a program manager needs to manage program components and, as new information becomes available, replan program components and their integration. If needed, a program manager may change program direction. To accomplish that, the program manager iteratively manages the program components through these three subphases:

• Component planning and authorization;
• Component oversight and integration; and
• Component transition and closure.

Component Planning and Authorization

Component planning is performed throughout the duration of the program benefits delivery phase in response to events that require significant replanning or a new component's initiation request. Component planning includes the activities needed to integrate the component into a program to position each component for successful execution. These activities involve formalizing the scope of the work to be accomplished by each of the components and identifying the deliverables that will satisfy the program's goals and benefits.²⁶

During the component planning and authorization subphase, the following activities may be performed in the program management plan:

• Update the plan with the new tasks in response to the new components’ initiation requests;
• Update existing tasks in response to replanning;
• Integrate components into a program management plan, including identifying, unifying, and coordinating activities within a program management plan as well as making trade-offs among competing objectives and managing interdependencies between knowledge areas; and
• Baseline a program management plan and calculate a critical program path.

To illustrate how the plan is being updated with the new tasks, we will use the call center's process improvement program example. During quarter one, it was identified that project two, decrease call response time, required an additional scope. Additional scope includes research around call response time for different call types. Project two's plan was updated to include a new task for research around call response time for different call types. It was determined that the research department would perform this task. The new task addition will be shown on line 21 in Figure 8-3, presented in the next section.

Component Oversight and Integration

In the context of a program, some components produce benefits immediately, while other components need to be integrated before the associated benefits can be realized. For example, in the call center's process improvement program, subprogram one that includes project one, improve call response quality, and project two, decrease call response time, produces benefits immediately. While project three, implement projects one and two, to realize associated benefits, needs to be integrated and implemented in all call centers.

During the component oversight and integration subphase, the following activities may be performed in the program management plan:

• Update program management plan with actual start and finish dates to track when tasks actually started and finished;
• Compare actual start and finish dates with scheduled start and finish dates to identify tasks that started and finished later than scheduled;
• Track program and component progress by calculating tasks partial and full percent completion;
• Track milestone completion;
• Rebaseline program management plan. Microsoft Project allows setting as many as eleven baselines;
• Calculate program and component critical paths;
• Identify program-wide conflicts and interdependencies using the program management plan and program time line;
• Provide program and component status updates; and
• Monitor benefits delivery progress.

All component information becomes known during the program benefits delivery phase. During the component planning and authorization subphase of the benefits delivery phase, a program management plan is updated with all components’ information. During the component oversight and integration subphase of the benefits delivery phase, a program management plan is used to track tasks’ partial and full percent completion, as shown in Figure 8-3.

During the program benefits delivery phase, component planning and authorization, and component oversight and integration subphases, a program management plan may include the following columns:

• Text column shows components’ task status indicators using smiley face images:
  • Green smiley face depicts that schedule is within 0.5% of the finish date;
  • Blue smiley face depicts that schedule within 1.5% of the finish date;
  • Yellow smiley face depicts that schedule within 2.5% of the finish date; and
  • Red smiley face depicts that schedule within 3.5% of the finish date;
• Actual start date column shows actual start dates for each task;
• Actual finish date column shows actual finish dates for each task; and
• Task number, task name, percent complete, start and finish, predecessor, resources columns, and Gantt chart, were described in the previous section.

During the component oversight and integration subphase, a program manager tracks component tasks’ partial and full completion and utilizes multiple tools within the program management plan:

• Calculate task's partial and full percent complete;
• Track task status depicted by the status indicators, green, blue, yellow, and red smiley faces;
• Calculate variance by comparing actual start date with the scheduled start date and determining if an actual start date is ahead of, on time, or behind a scheduled start date;
• Calculate variance by comparing actual finish date with the scheduled finish date and determining if an actual finish is ahead of, on time, or behind a scheduled finish date;
• Review program time line and identify tasks that are behind schedule; and
• Use reports to track timely benefits delivery, as will be discussed in detail in the next section.

Component Transition and Closure

After program components’ successful delivery of their products, services, or results, they may be closed or transitioned into another organization and then closed. Transition addresses the need for ongoing activities, such as product support, service management, change management, user engagement, or customer support from a program component to an operational support function for the ongoing benefits to be achieved.²⁷ For example, in the call center's process improvement program, after projects one and two are implemented in all call centers, they become a part of their ongoing operations. At that time, the call center's process improvement program and component tasks should be closed.

During the component transition and closure subphase, the following activities may be performed in the program management plan, as shown on Figure 8-4:

• Review all components to verify that the benefits were delivered;
• Transition component activities;
• Mark all program and component tasks as complete in the percent complete column; and
• Create a final program status report using program time line and program reports.

During the program benefits delivery phase, component transition, and closure subphase, a program management plan marks all tasks as 100% complete. A program manager analyzes components’ actual start and finish dates, and compares them with the scheduled start and finish dates to identify tasks that started and finished later than scheduled. A program manager also runs reports to review with the program governance board and receives approval for program closure.

Program Closure Phase

During the program closure phase, a program manager marks all program tasks as 100% complete. A program manager analyzes program actual start and finish dates, compares them with the scheduled start and finish dates to identify tasks that started and finished later than scheduled, and runs a series of program reports. A program management plan, along with other program artifacts, is transitioned to the ongoing operations.

Program Monitoring and Periodic Evaluation

Program monitoring and periodic evaluation ensure successful program execution. It ensures that a program delivers all benefits, and is being executed on time and within budget. Program monitoring and periodic evaluation take place on both the program and component levels.

Program monitoring and periodic evaluation take place during the entire program life cycle with different steps being executed during each phase. During the program definition phase, a program manager plans program monitoring and periodic evaluation of a program and its components. During the program benefits delivery phase, a program manager executes program monitoring and periodic evaluation. The execution occurs on the component level with oversight on the program level. During the program closure phase, a program manager closes program monitoring and periodic evaluation. The closure occurs on the component level with oversight on the program level.

Program Definition Phase

During the program definition phase, a program manager develops a program monitoring plan. The plan defines how the program execution will be monitored and evaluated. Objectives of the program monitoring and evaluation may include ensuring that a program is on track to deliver all benefits, is executed on time and on budget, there is no duplicate work, there are no gaps in work, and resources are used as planned. Program monitoring may utilize various techniques, including phase-gate review, program audit, program deep dive, and a readiness review.

Phase gate is a review at the end of a phase in which a decision is made to continue to the next phase, to continue with modification, or to end a project or a program.²⁸ Phase gate has three main objectives: ensures the quality of program execution, confirms the validity of business rationale behind program execution, and confirms program management plans and resources requests. A program manager authorizes a phase-gate review team, which includes selected members of the program team and a program governance board, develops a phase-gate review template, and determines phase-gate review frequency.

A program audit is a process of inspecting a program, which can be performed internally by a designee within a program, by an audit department, or externally by a government agency. Program audit objectives may include an assurance that a program is being executed as planned, meets program quality standards, attests to the regulatory requirements, and meets industry standards.

A program deep dive includes a detailed program and component review. Program deep dive objectives may include program scope validation, program interdependencies identification, and program risk mitigation planning. A program manager forms the deep-dive team, develops the deep-dive checklist, and determines deep-dive frequency.

A readiness review includes all activities that need to be completed before a program or a component delivers benefits. A program manager appoints a readiness review committee, develops a readiness checklist, and determines readiness review frequency.

Program Benefits Delivery Phase

During the program benefits delivery phase, a program manager executes a program monitoring plan, which utilizes techniques defined in the program monitoring plan, including phase-gate review, program audit, program deep dive, and a readiness review. A program manager executes each technique with the frequency described in the program monitoring plan. An exception to this rule is an external audit, where a government agency determines audit content and frequency. A program manager updates a program sponsor and a program governance board of the results of the program monitoring plan execution.

Program Closure Phase

During the program closure phase, a program manager finishes a program monitoring plan. A final plan states if a program delivered all benefits, was executed on time and on budget, did not have any duplicate work, did not have gaps in work, and used resources as planned. A program manager delivers the final plan to the program sponsor and the program governance board.

Program Risk Management

All programs encounter risks! A program risk is an event or series of events or conditions that, if they occur, may affect the success of the program. Positive risks are often referred to as opportunities and negative risks as threats. These risks arise from the program components and their interactions with each other—from technical complexity, schedule, and cost constraints—and with the broader environment in which the program is managed.

It is essential to define risk profiles of organizations to construct the most suitable approach to managing program risks, adjusting risk sensitivity, and monitoring risk criticality. Risk targets and risk thresholds influence the program management plan.²⁹ A risk profile includes risk categorization into high, medium, and low, which can be done based on assessing the level of impact on a program and a component, and a probability of occurrence.

High, medium, and low risks have a different level of impact on a program and a component:

• High risk can significantly impact a program or a component's cost, schedule, or performance;
• Medium risk can somewhat impact a program or a component's cost, schedule, or performance; and
• Low risk can minimally impact a program or a component's cost, schedule, or performance.

High, medium, and low risks have a different probability of occurrence:

• High risk has 70% or higher probability of occurrence;
• Medium risk has 30%–70% probability of occurrence;
• Low risk has 30% or lower probability of occurrence.

External and internal program factors can cause risks. External factors mostly cause program-level risks. Examples of external factors include political unrest, terrorist attacks, wars, tornadoes, and hurricanes. Internal factors can cause either program or component-level risks. Examples of internal factors that cause program-level risks include lack of system functionality, inefficient program initiation phase structure, and an absence of a program management tool. Examples of internal factors that cause component-level risks include resource constraints, changes to a component's scope, and delays with deliverables completion.

Organizations may have predefined approaches to risk management such as risk categories, the common definition of concepts and terms, risk statement formats, standard templates, roles and responsibilities, and authority levels for decision making. Lessons learned from executing similar programs in the past are also critical assets to be reviewed as a component of establishing an effective risk management plan.³⁰

To have greater influence over the program, you give up direct control over each project task. The program manager is not a firefighter, but instead looks for changes or delays in activities, identifies possible risks, and prepares the team for things that could go wrong.³¹ Risks can be encountered during all phases of the program life cycle. It is important to anticipate risks, as with time, their impact on a program may increase. Thus, it is critical for a successful program execution to identify, track, and mitigate risks.

Program risk monitoring and control is the activity of identifying, analyzing, and planning of new risks; tracking identified risks and those on the watch list; and re-analyzing existing risks. Monitoring reduces the impact of a threat and maximizes the impact of an opportunity by identifying, analyzing, reporting, and managing risks on a continuous basis. Risk monitoring and control is an ongoing activity for the duration of the program.

The program manager identifies risks that can threaten the program's existence and develops a mitigation plan, such as environmental changes or governmental policies and regulations.³²

Program Risk Management

Risk management is at the heart of project management. Any number of risks can befall a project and drive it off course, often through no fault of the project team. From hurricanes and political unrest, to supplier conflicts and labor shortages, internal and external events can have a significant impact on a project's progress and ultimate performance. Such risks are not fully predictable, but with effective risk management practices, potential damage can be mitigated.

Even though risk management practice is vital to successful program execution, in 2015 only 64% of organizations reported the frequent use of risk management practice, down from a high of 71% in 2012. While this number has declined, and is something that PMI will continue to monitor, the study does find that 83% of high performers report frequent use of risk management practices, compared to only 49% of low performers.

A risk management competency helps organizations assess and identify project risks, mitigate threats, and capitalize on opportunities. In fact, organizations that report they always use risk management practices have significantly better project outcomes compared to organizations that do not, as shown in Figure 8-5.³³ Figure 8-5 reports statistics for project management. Data on risk management and program outcomes are not available, so we assume that risk management and program outcomes have a similar correlation as risk management and project outcomes.

Program risk management occurs during all phases of the program life cycle. During the definition phase, a program manager performs program risk management planning. During the benefits delivery phase, a program manager identifies, registers, monitors, and mitigates risks. During the closure phase, a program manager closes all risks.

Program risk management planning identifies how to approach and conduct risk management activities for a program by considering its components. It occurs during the program definition phase. The risk management plan—the output of this activity—defines the approach to be used for managing risks.

Risk identification is an iterative activity that occurs during the benefits delivery phase. As the program progresses, new risks may evolve or become known. The frequency of iteration and involvement of participants may vary, but the format of the risk statements should be consistent. This allows for the comparison of risk events in the program. During risk identification, each program team member forecasts the outcomes of current strategies, plans, and activities, and exercises their best judgment to identify new risks. It is important to include contextual information that narrates how or why the risk may affect the program's success; the identification activity should provide sufficient information to allow the risk to be analyzed and prioritized.³⁴

Risk monitoring involves tracking program-level risks identified in the program risk register and identifying new risks that emerge during the execution of the program, for example, unresolved component-level risks that demand resolution at the program level. Required actions may include determining if new risks have developed, current risks have changed, risks have been triggered, risk responses are in place where necessary and are effective, and program assumptions are still valid.³⁵

There are many tools that allow tracking risks, including applications like Microsoft Office Project Server, SharePoint drive, homegrown software packages, and Excel spreadsheets. Microsoft Office Project Server, SharePoint drive, and similar applications have built-in functionality that allows registering risks and monitoring their resolutions. If applications are not available, a program manager can always build a risk register in Excel.

A risk register, which allows successfully registering, tracking, and mitigating risks, may include the following columns:

• ID column corresponds to risk orderly number.
• Date identified column displays a date when a risk was registered.
• Program or component column states if it is a program or a component risk.
• The title column provides risk name.
• The description column provides risk description.
• Probability column defines the percent probability of risk occurrence, which can be high, medium, or low.
• Impact column defines an impact that a risk will have on a component or a program, which can be high, medium, or low.
• Owner column lists a project manager responsible for risk resolution.
• The status column describes if a risk is open or closed.
• Escalated to a program column states if a risk is escalated to a program level.
• Mitigation strategy column describes a strategy to mitigate a risk.
• Target resolution date column shows a scheduled date to resolve a risk.
• Actual resolution date column shows an actual date a risk was resolved and closed.

We will use the call center's process improvement program example to illustrate issue identification, registering, and mitigation. It was determined that project two, decrease call response time, needs to include an additional scope. The additional scope is a research around call response time for different call types. This is a risk, as it has a negative impact on the project two time line. Subsequently, this risk has a negative impact on the call center's process improvement program execution time line. As this risk impacts program time line, project manager two escalates it to a program level.

A program manager and a project manager identify a mitigation plan that includes executing research around call response time for different call types in parallel with the subsequent tasks. Parallel tracking is possible, as a research department, and not a program team, will execute this task. A risk register for the call center's process improvement program is presented in Figure 8-6.

During the closure phase, a program manager conducts closure activities, including review and closure of all risks. A program manager archives risk documentation for future usage and transitions program benefits to operations.

Escalation Mechanism

As a program manager, I have learned to become more proactive in resolving conflict rather than reacting to the crisis. I think regarding escalation rather than reporting. Reporting only conveys the status of an issue; there's no obligation from the receivers to take action. Escalation gets the leadership team involved in solving the problem. From my experience, escalation can be considered complaining, so in the kick-off meeting for any project, I try to define when issues are escalated and to whom.³⁶

Risks that require escalation include risks that impact more than one component within a program or the program as a whole. Examples of risks that require escalation include resource and inter-group conflicts, incorrect expectations about roles and responsibilities, and risks to key project indicators.

Program governance and escalation procedures should be in place to allow risk assessment for possible impact across the organization. The risk register is used in risk analysis and identification of risks that need to be escalated to senior leadership.

When risks remain unresolved, a program manager ensures that they are escalated progressively higher on the authority scale until a resolution is achieved. Risks are first escalated to a program manager. If a program manager does not have authority to resolve them, a program manager escalates risks to an executive sponsor and a program governance board.

There are several types of escalation to consider:

• Sometimes you need a yes or no answer to a critical question, such as scope expansion, which is beyond program manager authority;
• Conflicts may require mediation from someone at a higher level with a broader view of the project or program;
• An information-only escalation simply keeps management informed of potential issues that may arise and require their attention in the future;³⁷
• Component-level risks that cannot be resolved by the project management team at the component level; and
• Component-level risks that could be managed more effectively at the program level because they affect more than one component or require a higher level of authority to be resolved.³⁸

After determining that a risk should be escalated, a program manager determines the right time and identifies a correct person to escalate it to. Frequent escalation may be perceived by management as either a program manager's lack of competence or a high risk to project success. Rare escalation may result in missing critical issues or time for management to step in and facilitate the needed timely resolution.

A program manager needs to ask these questions to help decide whether it is time to escalate:

• Have you made a sincere attempt to reach an appropriate resolution, but have found that you are at a dead end?
• Is this an issue that your boss would expect you to handle or to escalate?
• Do you have all the appropriate know-how to make the decision, or does another subject matter expert or stakeholder need to be consulted?
• Can you approach these experts or stakeholders directly, or is escalation the only way to obtain their input?
• Have you exhausted all other options and any further delay could have a detrimental effect on the project outcome or deliverables?

Once a program manager has decided to escalate, it is important to do it in a mature and professional way. Here are six tips for effectively escalating problems with your project or on your project team:

• You need to determine the right person to escalate to. The immediate manager may not be the one to escalate to, especially in a matrix organization.
• Escalate to an appropriate level in the hierarchy in which there is someone empowered to make the decision or intervene. Going “too high” may result in your request being sent down to a lower-level employee.
• Provide a concise summary of the problem and also indicate where detailed information can be found. Do not assume that the people you are escalating to have the required background information.
• State explicitly what you need. Don't leave any ambiguity. Make sure you say when you need it and the impact or consequences if the expected action is not taken in time.
• Follow up, even after sending that email and making the telephone call—do not assume that when you escalate, the ball is now in the other person's court.
• Use appropriate, respectful content. Harsh emails and telephone calls complicate more things than they solve.³⁹

It is very important to define and document what risks should be escalated, what is the timing to escalate, and who are the senior executives to escalate to. If a risk escalation process is not defined and documented, it may result in erroneous, missed, or untimely risk escalation. If an organization does not have a risk escalation process, it is critical that a program manager develops one for a program.

Program Change Control Process

All programs encounter changes. Examples of program changes include changes to scope, schedule, budget, documents, and deliverables. Changes to scope include an increase or reduction in the originally defined scope. An increase in scope occurs when a need for additional scope is identified. Similarly, a reduction in scope occurs when it is confirmed that a part of the scope is no longer needed.

Changes to the schedule include changes to task start and finish dates. Changes to task start dates occur when a task can start earlier or later than scheduled. A task starts earlier than scheduled due to an earlier completion of a preceding task or resource availability. A task starts later than scheduled due to a delay in completion of a preceding task or resource unavailability. Similarly, a change to task finish dates occurs when a task can be completed earlier or later than scheduled. A task finishes earlier than scheduled due to fast-tracked work or availability of additional resources. A task finishes later than scheduled due to a delay in completion of work or resource constraints.

Changes to budget occur when a program needs additional funds or has unused funds. A need for additional funds occurs due to an increase in scope, a need to engage additional resources, a delay in schedule, or a shift in work to an earlier date. A program has unused funds due to a reduction in scope, a need to free up resources, an advancement of schedule, or a shift in work to a later date. Changes to documents and deliverables occur due to a change in scope, a need for additional content, and a request for edits.

Changes are caused by both internal and external program factors. Examples of internal factors include resource constraints, budget constraints, and a discovery of additional information that may alter program baseline plans. Examples of external factors include changes in regulatory requirements, changes in industry standards, and an introduction of new products and technology to the market.

We will use the call center's process improvement program to provide an example of change. During the benefits delivery phase, it was discovered that project two, decrease call response time, needs additional research around call response time for different call types. This is an example of an additional component's scope that was not known during the definition phase. It is caused by an internal factor, an identification of a need for additional research. The research department will conduct research. Thus, this change results in an increase to budget to pay for a research department resource.

Critical to project management is the establishment of a baseline from which to effectively execute a program. Any change introduced is normally tightly controlled with a penchant for change avoidance to prevent rework and drive assurance of the scope and time line. Critical to program management, however, is awareness of change occurring in the business environment, which will affect the success of the program. Program managers must be adept at navigating change and understanding the impact of change on the business goals driving a program.⁴⁰

Change control is a process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected.⁴¹ During the definition phase, a program manager locks program scope and baselines the program management plan by locking the originally approved tasks and their start and finish dates. A program manager defines documents and deliverables that will be produced throughout the program life cycle and gets approval for a program budget.

During the program life cycle, there may be changes to the originally approved scope, schedule, budget, documents, and deliverables. These changes require change requests. A change request is a formal proposal to modify any document, deliverable, or a baseline.⁴² To process program change requests, a program manager establishes a program change control process.

Change Control Process

Program change control is a process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected.⁴³ A change control process is utilized during the program life cycle. During the program definition phase, a change control process is developed at the program level. During the benefits delivery phase, it is executed at the component level with oversight on the program level. During the program closure phase, a change control process is closed at the program level.

Definition Phase

To process changes, a program manager establishes a program change control process. The process is established on a program level and executed at the component level with oversight on the program level. The process describes how to initiate, track, approve, implement, and close changes; it defines roles and responsibilities of all persons who participate in the change control process. The process may include the following:

• Define regular and fast-tracked change control processes, including timing of each step;
• Define roles and responsibilities, and establish approval thresholds;
• Develop change request process quality standards;
• Develop change request tracking mechanism and create change request repository tool; and
• Develop a change request form.

Change control process execution starts with the initiation of the change request form. As was defined earlier, a change request form is a document that outlines changes to the original program scope, time line, or funding, providing justification to help determine proper action. A change request is declarative; it states what change should be implemented, but leaves out details on how to implement it. A change request form can be a standardized functionality built into a Microsoft Office Project Server or a program's SharePoint site. It can also be a homegrown document developed within a program or by an organization in Microsoft Word or Excel.

During the definition phase, a program manager develops a change request form. During the entire program life cycle, component project managers and the program manager use the form to request changes. Depending on the nature of a program, organization and industry standards, and regulatory requirements, a change request form may include these fields:

• Change header that includes a program name and a serial number;
• Change title;
• Date a change request was created;
• Name and title of a person who created a change request;
• Change request status, open or closed;
• Detailed description of change;
• Change-supporting documentation, including technical specifications, data analysis, process flows, and more;
• Change impact on schedule and budget, including timing needed and funds required to implement change;
• Change start and implementation dates; and
• Approval status, approved or denied.

Large scope programs may have a change manager. A change manager performs functions related to the change control process, including receiving a change request form, assigning a serial number, storing it on the shared site or drive, conducting an initial review, and taking it to the change control board and steering committee for review and approval. If a program does not have a change manager, likely a program manager performs this function.

After a change request form is created, it is submitted to a program manager or a change manager for processing and an initial review. Once submitted, a change request is assigned a serial number that allows tracking it throughout the change control process as well as to reference it at a later phase of the program or by other programs.

It is important to store and track change requests. If a change request is created in Microsoft Office Project Server or a program SharePoint site, it is tracked there utilizing a built-in tracking mechanism. If a change request is created in Microsoft Word or Excel, the file is stored on a program SharePoint site or a program's shared drive. A change request log, a separate document, serves as a tracking mechanism.

A program manager or change manager conducts an initial review of a change request. The objective for an initial review is to confirm that a requested change meets program objectives, and includes all necessary supporting documentation. The outcome of the review is either a recommendation for a change request to go through a change control process, a request for additional information, or a conclusion that change is not needed for successful program benefits delivery.

After an initial review, a change request is submitted for a formal review and approval. An objective of the change request review is to determine if a change is needed for successful program benefits delivery, it meets regulatory requirements and industry standards, and change cost corresponds to the benefit that will be realized by implementing it. Change request approval is usually set based on approvers’ thresholds. Organizations grant approving power to individuals and committees within defined thresholds. Based on the thresholds that a change request falls into, an individual or a committee approves a change request. For example, a program manager may have the power to approve change requests for under US$10,000. A change request board may have the power to approve change requests within a range of US$11,000 and US$50,000. A change request steering committee may have the power to approve change requests within a range of US$51,000 to US$250,000. Organizational authorities, such as a capital approval committee or a CFO may have the power to approve change requests of over US$251,000.

Based on the organizational guidelines around approving power, a program manager establishes program thresholds and identifies people and committees that can grant approvals for each threshold. A program manager may establish a change control board to review and approve change requests for low and medium costs, and a steering committee to review and approve change requests with high costs. An outcome of the review can be either an approval or a denial of a change request. If a change request is approved, it will be implemented. If a change request is denied, it may be resubmitted with additional information that substantiates the request.

A change control board (CCB) is a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions.⁴⁴ A change control board may include a program manager, program team members, subject matter experts, members of the CFO team, and business owners.

A program steering committee is a committee that plays an important role in directing a program throughout program life cycle execution. It plans various functions, including monitoring program execution and budget spending, conducting phase-gate reviews, reviewing and approving change requests, and ensuring successful delivery of program benefits. A program steering committee may include a program manager, senior program team members, senior-level subject matter experts, CFO, and executive-level business owners.

A program manager establishes duration for each step within a change control process. For example, an initial review by a program manager or a change manager should be completed within two days of the change request submission. Change control board meetings should be regularly scheduled (e.g., biweekly or monthly to ensure timely processing of all change requests). Similarly, steering committee meetings should also be scheduled regularly (e.g., monthly).

A program manager defines regular and fast-tracked change control processes. If a change is not urgent in nature, it is processed through a regular change control process that includes all defined steps. If a change is urgent in nature, it is processed through a fast-tracked change control process that includes only critical steps.

A program manager establishes change control process quality standards that may include defining exceptions to the change control process, developing change request form standards, and determining the timing of change control process steps.

Benefits Delivery Phase

As stated earlier, change control process execution occurs during an entire program life cycle. The change control process starts with preparation, review, and approval of a change request. If approved, a change request is implemented. A component program manager monitors implementation and reports implementation status to a program manager or a change manager. If a change request implementation encounters issues, a component project manager resolves them or escalates them to a program manager where needed.

Once a change request is implemented, a component project manager reviews the outcome to ensure completeness. A component project manager closes a change request and reports closure to a program manager or a change manager.

Closure Phase

Change control process closure takes place at a program level. A program manager or a change manager confirms that all change requests were reviewed, and either approved or denied. A program manager or a change manager confirms that all approved change requests were implemented and confirms that all change requests were properly archived for future use by other programs.

Quality Control Process

Even projects that are delivered within budget and on time are not successful if the quality of the deliverable is poor. Quality management is all about identifying and following quality requirements, auditing the results of quality control measurements, and using quality measurements to control quality, recommending project changes if necessary.

Delivering high-quality benefits warrants on time and on budget benefits delivery and results in high customer satisfaction. In contrast, delivering low-quality benefits may result in missed delivery dates and the cost of rework. Quality is a variable cost for a program; it should be evaluated and incorporated into the business plan.

It is critical for successful benefits delivery to have a program quality management plan. Quality management ensures that a quality plan exists for overall program and project quality. The quality plan will also define program management metrics that will be used in providing early warnings of program failure points.

A quality management plan is used during the entire program life cycle. A program manager develops a plan during the program definition phase. A program manager and component managers execute the plan during the benefits delivery phase. The plan is cascaded down from a program level to the component level. A quality management plan is executed iteratively. A program manager closes a plan during the closure phase.

Quality management plan uses the program management plan, stakeholder register, and risk register as inputs. The program management plan provides the work breakdown structure, cost base, and scope baseline, including start and finish dates. The stakeholder register helps identify stakeholders that have an interest in and impact on quality. The risk register helps identify risks that may have an impact on quality.

The quality management plan includes quality standards, metrics, and measurement tools. Quality standards set up a framework of clear expectations around the quality of benefits that a program will deliver. Quality metrics are measurements that are used to compare benefits quality with the standards. Quality tools are used to measure benefits quality. Tools may include phase-gate reviews, internal and external quality audits, and documents review and approval processes.

Phase-gate reviews ensure benefits quality, as was described earlier. Phase-gate reviews are conducted at the end of each phase by a phase-gate review team that includes selected members of the program team and a governance board. A quality audit is a structured, independent process to determine if benefits meet quality standards, and meet internal and external regulatory requirements. Quality audits may be internal or external.

A department may conduct internal program audits within an organization or a project within a portfolio of which a program is a part. We will use the call center's process improvement program example. The program is a part of the call center's portfolio that has project one, call center's audit. The call center's audit is conducted for multiple purposes, including quality assurance of benefits delivered by the call center's process improvement program.

Government agencies conduct external program audits. External audits are especially important in the industries that have very high-quality standards, as they are directly responsible for human lives, including healthcare, aerospace, and car manufacturing.

Program documents review and approval is an important part of the quality assurance process. All program documents should be reviewed with the team that prepares the document, with the team that will use it in the next phase, and with executives. Review with the executives is a very important step in the quality assurance process, as they have a comprehensive view of the organization. Thus, through their review and approval of the document, the executives can ensure an overall cross-functional alignment. Among the reasons a program fails in quality is because executives do not take the time to review the documents, ensuring overall organizational alignment. An approach of using proxies in obtaining approvals may help with timing but, on the downside, may result in potential quality issues.

If any of the quality tools determine lower than desired benefits quality, it means that additional work is needed. In that case, a component project manager initiates a change request to conduct additional work to meet quality standards.

A program manager should balance quality of delivered benefits and program delivery on time and budget. If achieving quality results requires additional time, a program manager should evaluate various alternatives to ensure quality and secure on-time and on-budget delivery, including:

• Implement short-term solutions first and long-term solutions second;
• Implement manual solutions first and automated solutions second; and
• Conduct additional work needed to ensure benefits quality, then accelerate a subsequent phase by engaging additional resources.

Program Communication

In the context of organizational project and program management, communication is a core competency that, when properly executed, connects every member of a project team to a common set of strategies, goals, and actions. Unless project leads effectively share these components, and they are understood by stakeholders, project outcomes are jeopardized and budgets incur unnecessary risk.

The most crucial success factor in project management is effective communication to all stakeholders—a critical core competency to all organizations. In a complex and competitive business climate, organizations cannot afford to overlook this key element of project success and long-term profitability.

PMI research proves that ineffective communication leads to fewer successful projects; organizations that are minimally effective communicators report significantly fewer projects that meet original goals, come in on time, and complete within budget, as shown in Figure 8-7. ⁴⁵

It is critical for a successful benefits delivery to have a program communication management plan. Communication planning is the activity of determining the information and communication needs of the program stakeholders based on who needs what information, when they need it, how it will be given to them, and by whom.⁴⁶

A communication management plan is used during the entire program life cycle. A program manager develops a plan during the program definition phase. A program manager and component managers execute the plan during the benefits delivery phase and close the plan during the closure phase.

Program communication can be internal and external. Examples of internal communication include communication to a program team, departments within the organization, program governance board, and executives. Examples of external communication include communication to the government agencies, external auditors, competitors, and suppliers.

A communication management plan describes communication protocols for various types of program communication, both internal and external. The plan needs to address stakeholders’ needs and expectations, and to provide key messages in a timely fashion and format designed specifically for the target audience. Communication messages include program and component status updates, risks communication, change requests updates, budget information, external filings with the government, announcements, and press releases.

The program manager is the key communicator for the program. It is beneficial for the program manager to have a defined and documented strategy for the wide spectrum of communication requirements. This communication strategy is used throughout the duration of the program even if it is used as a quick reference to ensure that the appropriate message is delivered to the correct audience. This communication strategy should be updated regularly, as audiences and messages change throughout the course of a program.⁴⁷

To ensure successful communication, a program manager needs to have strong communication skills. A program manager needs to be able to communicate up, down, and across with stakeholders, sponsors, customers, vendors, executives, and other program stakeholders. To communicate effectively, a program manager needs to be able to craft messages that will reach the targeted audience.

---

¹ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

² Blomquist, T., & Müller, R. (2004). Program and portfolio managers: Analysis of roles and responsibilities. Proceedings of the PMI Research Conference (11–14 July), London, England.

³ Microsoft Project. (n. d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Microsoft_Project

⁴ Microsoft Project. (n. d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Microsoft_Project

⁵ Microsoft Project Server. (n. d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Microsoft_Project_Server

⁶ Microsoft Office Support. (n.d.). Retrieved from https://support.office.com/en-us/article/Link-projects-to-create-a-master-project-36bcd34d-db5c-403a-9eca-90e878920f2a?ui=en-US&rs=en-US&ad=US&fromAR=1

⁷ Microsoft Office Support. (n.d.). Retrieved from https://support.office.com/en-us/article/Link-projects-to-create-a-master-project-36bcd34d-db5c-403a-9eca-90e878920f2a?ui=en-US&rs=en-US&ad=US&fromAR=1

⁸ Microsoft Project. (n. d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Microsoft_Project

⁹ Support Microsoft Office. (n.d.). Retrieved from https://support.office.com/en-us/article/Add-resources-to-your-project-1a744960-d960-426a-b687-e42ba3f6c0cb

¹⁰ Timeline. (n.d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Timeline

¹¹ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

¹² Work breakdown structure. (n.d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Work_breakdown_structure

¹³ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

¹⁴ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

¹⁵ Microsoft Office Support. (n.d.). Retrieved from https://support.office.com/en-us/article/Add-resources-to-your-project-1a744960-d960-426a-b687-e42ba3f6c0cb

¹⁶ Microsoft Office Support. (n.d.). Retrieved from https://support.office.com/en-us/article/Add-resources-to-your-project-1a744960-d960-426a-b687-e42ba3f6c0cb

¹⁷ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

¹⁸ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

¹⁹ Microsoft Office Support. (n.d.). Retrieved from https://support.office.com/en-us/article/How-Project-schedules-tasks-Behind-the-scenes-df3431ab-8d8a-4047-afc6-a87b547dbac0

²⁰ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

²¹ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

²² Written in collaboration with Sankaran Ramani, MoP, MSP, P3O, CM, PMP, PgMP, PfMP, Director, GRT Consulting LLP

²³ Gardner, D. G. (2001). Operational readiness—Is your system more “ready” than your environment? Retrieved from https://www.pmi.org/learning/library/operational-readiness-system-ready-environment-7946

²⁴ Microsoft Project. (n. d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Microsoft_Project

²⁵ Microsoft Office Support. (n.d.). Retrieved from https://support.office.com/en-us/article/Link-projects-to-create-a-master-project-36bcd34d-db5c-403a-9eca-90e878920f2a

²⁶ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

²⁷ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

²⁸ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

²⁹ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

³⁰ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

³¹ Merrick, A. (2015). Allied forces. Retrieved from http://www.pmi.org/-/media/pmi/landing-pages/business-analysis-tools-silverpop/pdf/allied-forces-project-management-business-analysis.pdf

³² Merrick, A. (2015). Allied forces. Retrieved from http://www.pmi.org/-/media/pmi/landing-pages/business-analysis-tools-silverpop/pdf/allied-forces-project-management-business-analysis.pdf

³³ PMI. (2015). Pulse of the profession®: Capturing the value of project management. Newtown Square, PA: Author.

³⁴ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

³⁵ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

³⁶ Merrick, A. (2015). Allied forces. Retrieved from http://www.pmi.org/-/media/pmi/landing-pages/business-analysis-tools-silverpop/pdf/allied-forces-project-management-business-analysis.pdf

³⁷ Karekar, H. (2014, April 14). Escalation—Let's do it right! Retrieved from https://www.projectmanagement.com/articles/283756/Escalation-Let-s-Do-it-Right

³⁸ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

³⁹ Karekar, H. (2014, April 14). Escalation—Let's do it right! Retrieved from https://www.projectmanagement.com/articles/283756/Escalation-Let-s-Do-it-Right

⁴⁰ Martinelli, R. J., Waddell, J. M., & Rahschulte, T. J. (2014). Program management for improved business results. (2nd ed.). Hoboken, NJ: John Wiley & Sons, Inc.

⁴¹ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

⁴² PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

⁴³ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

⁴⁴ PMI. (2015). PMI lexicon of project management terms, Version 3.0. Newtown Square, PA: Author.

⁴⁵ PMI. (2013). Pulse of the profession®: In-depth report—The high cost of low performance: The essential role of communication. Newtown Square, PA: Author.

⁴⁶ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.

⁴⁷ PMI. (2013). The standard for program management – Third edition. Newtown Square, PA: Author.