Defining the Program Strategy

The program strategy describes how the program team will achieve the strategic business goals desired from the outcome of the program. It is established by defining the program objectives and the capability output (product, service, infrastructure, or change transition), that once achieved, becomes the end state for program success.

As discussed in Chapter 3, the program objectives establish alignment of a program to the business strategies of an organization, and provide the guiding principles that help the program manager and other key decision makers understand the scope of the program, make key trade-off decisions, and determine resource requirements. To be effective, objectives should be specific, measurable, realistic, and time related.²

Defining the New Capability Concept

To achieve the program objectives, the program output should result in a new capability that becomes the means for achieving the desired outcomes. Capabilities normally come in the form of a new product or service to be offered to a firm's customers, a new internal capability that will positively affect a firm's effectiveness and efficiency, or a new change initiative that will create positive transformation either internally or externally to the organization.

Deriving a capability concept, or set of concepts, is an iterative process that involves the integration and synthesis of the ideas from the subject matter experts on the program definition team. When leading the ideation process, the program manager should focus the output toward the program objectives identified. This involves the following: facilitating the cross-discipline collaboration, setting periodic concept reviews in front of primary program stakeholders to create tension in the system and expedite the concept definition, continually collecting and communicating any changes to the initial program objectives, and testing the concept feasibility from a business perspective.

Developing the Preliminary Business Case

A fully complete business case is not always necessary for the first cycle of work on a program, and in fact may be wasted effort if the program objectives are not agreed upon by influential stakeholders. We recommend a separate business decision fully dedicated to the approval of the program business case following approval of the program strategy. That being said, a preliminary business case is needed to support the program strategy decision. Critical elements include information on the potential benefits, business success factors, costs, and potential risks associated with the program being proposed.

Benefits Identification. Early benefits identification is an iterative learning process and may consume a disproportionate amount of the program definition team's time and effort. It begins with understanding the strategic business goals driving the need for the program, and then dissecting the goals with the input from the program stakeholders, customers and end users, strategic suppliers, and others. The result of this effort is what PMI refers to as the Benefits Realization Plan.³

Business Success Factors. In Chapter 2 we described how we delineate business benefits into business value and business results. Establishing the right measures for delivery of the business results is a key activity of program definition. We firmly believe in the old adage that says, “What gets measured, gets done.”

The business success factors transform the business results derived from strategic goals into a specific statement of success that guides the execution engine of the organization as to how to plan and execute their work. We define business success factors as the set of quantifiable measures that describe the successful achievement of a program's business results. It is the business success factors that bind the activities of strategy setting to those of strategy execution.

In Chapter 3, we discussed the translation from strategic goals to program objectives that needs to occur in order to effectively align a program to the business strategy. Business benefit identification is at the heart of that translation effort. The translation goes as follows: Strategic business goals to business results and from business results to program objectives. Table 6.1 provides an example of this translation process.

Once a translation of goals to benefits to objectives is complete, the program definition team should validate the findings by working backward to ensure that the program objectives will indeed result in the desired business results; then, that the set of business results identified will achieve the strategic goal. When the team is satisfied with the quality of the translation, they can then move to the next strategic goal and translation process.

Cost Evaluation. With the initial benefits of the program established, the preliminary business case should also estimate the cost to execute the program. Program costs represent the investment that the organization must make in the program.

At this stage, a high-level estimate of program funding, capital expenditures, and resources required should be completed. Additionally, if third party organizations are involved—such as strategic partners—an estimate of their investment cost also needs to be provided.

With both the initial benefits and costs identified, the preliminary business case can contain a high-level estimate of program cost versus benefits.

Risk Identification. To promote a risk-based decision, the preliminary business case should include an analysis of the significant risk events that may negatively impact the achievement of the business results. The objective of this exercise is to identify as many unknown events that may occur, and to assess them from the standpoint of impact to the stated business success factors.

A full risk management plan is not necessary at this early juncture of a program. Rather, the intent here is to proactively identify the critical risks that the definition team feels will likely have a negative impact on the program strategy, and to bring this knowledge into the program strategy decision.

Aligning Stakeholders

Program definition provides the first opportunity to identify the various stakeholders of the program, evaluate who is critical to the success of the program, and analyze their needs. A stakeholder is defined as anyone who has a vested interest in a program.⁴ More importantly for the program manager, a critical stakeholder is anyone who can influence, either positively or negatively, the outcome of the program.

Stakeholders play a key role in the program definition process by helping to identify the business benefits expected, providing direction on the capability concepts, and defining the program objectives. The value of early stakeholder identification normally becomes apparent to the program manager. Not only does one get a sense of stakeholder expectation for the program, but also of the opinions, perceptions, and personal agendas that may affect the outcome of program definition and possibly the outcome of the program as a whole.

Proficient program managers never leave the definition of program success up for debate until the end of the program. Instead he or she moves the debate on what constitutes success to the first decision point of the program. It is rare that early consensus is reached among the influential stakeholders on how to measure program success—in fact, consensus may never be reached. The program manager is charged with brokering the negotiation among influential stakeholders on how to define program success through the business success factors.

Some advocate the use of workshops to engage all influential stakeholders in a single session to establish the business success factors. In practice, this becomes difficult for a couple of reasons. First, executives are busy, and trying to align schedules for a two- to four-hour workshop can be an impossible task. Second, not all program managers possess the high level of credibility and skills needed to lead an executive-level negotiation workshop. Rather, we have found it most effective for a program manager to work with the stakeholders individually and to leverage the influential program champions in establishing the business success factors prior to the program strategy decision.

Defining the Final Capability Concept

As in the program definition cycle, the program manager is critical in facilitating the work of a cross-discipline team charged with coming to closure on a final capability concept. Even if a single concept was established prior to the program strategy decision, additional work will likely be required to validate the assumptions surrounding the proposed capability.

The process to accomplish this is best described as an iterative learning process where one seeks to understand how well a capability might satisfy customer, user, or organizational needs, how well it supports the program objectives and provides the means to achieve the business benefits, and how difficult it will be to create and implement.

The challenge for the program manager is to lead the team to convergence of the capability concept as rapidly as possible, know when to prevent additional learning cycles from occurring, and document the remaining assumptions for the next major cycle of work. Periodic reviews with the program sponsor and key stakeholders can be helpful in overcoming this challenge and maintaining a sense of urgency. Additionally, ongoing involvement and input from customers and users of the new capability is necessary.

Documenting the High-Level Requirements

As part of the final concept definition process the high-level requirements for the capability are identified and documented. The importance of diligently defining requirements cannot be overstated, as requirements are the basis for program planning and capability development activities. Poor requirements will result in poor planning. In turn, poor planning will result in poor execution and rework, which may result in failure to realize the business benefits of the program.⁵

The program manager is responsible for collecting and documenting the high-level requirements during this phase of the program, and should work with the content experts who represent the various disciplines on the program definition team to collect the requirements. To support the program investment decision, at a minimum, the high-level requirements must be documented in sufficient detail to describe the capability concept, key features and functions, end user and customer needs, and cost and financial targets as applicable.

Additionally, the high-level business requirements—the business success factors—that were first identified in the previous cycle of work should be further refined and included in the program business case.

Developing the Detailed Business Case

As the business manager on a program, the program manager leads the development and documentation of the detailed program business case. He or she must ensure that the business case contains the appropriate level of detail to support a funding decision, and that it is presented in the language of executives—the language of business.

The purpose of the detailed program business case is to demonstrate that a program and its capability will support the strategic goals and anticipated business results for the enterprise.

It is a guiding document used by a firm's program sponsor and other senior managers to assess the feasibility of a program and to repeatedly assess the program's path to success. For the program team, the business case is its primary chartering document that defines a successful end state.

As the advocate for the firm's business needs on a program, the program manager should lead the effort to develop and defend the detailed program business case. At a minimum, a high-quality program business case should include the elements shown in Table 6.2.

On many programs, the program business case is developed at a time when more is unknown about the program than is known and has been validated. For this reason, the program business case should be treated as a living document that is periodically reviewed, tested, and updated throughout the life of a program.

Stakeholder Engagement

Since multiple stakeholders will likely have a voice in whether or not a program is funded, stakeholder management is a critical role for the program manager to fulfill. The existence of differing needs, desires, and competing agendas between key stakeholders may never be as high on a program as when the major investment decision is approaching. A program manager should expect to spend significant time engaging with his or her stakeholders.

Stakeholder engagement will involve gaining agreement on the program value proposition, gaining commitment of resources to execute the program, and addressing the concerns of the stakeholders as best possible. Program champions can provide a wealth of support in executing your stakeholder strategy at this point in the program—experienced program managers never forget to engage them.

Establishing Program Governance

Most companies systematically monitor the achievement of their investment in programs and other work efforts in order to increase the probability of successfully achieving the expected returns (or value) from these investments through the use of their internal systems, policies, and guidelines that govern these activities. Some companies formalize these procedures into comprehensive governance policies and benefits management systems to provide the structure needed to properly oversee these activities. In some corporations, this may be managed through a governance board or steering committee. Other companies may assign this responsibility to one or more of their executives.

Well designed and implemented governance procedures demonstrate to executives and program stakeholders that their investment in the program will have appropriate oversight and control. A robust program governance system has three primary functions:

1. Establishing and maintaining the program strategy based upon the strategic business goals.
2. Ensuring the right structures are in place to achieve the program strategy.
3. Monitoring and directing the program to make sure the stated program objectives and business benefits are realized.

There is a distinct difference between program and project governance processes due to the nature of programs. Governance of programs needs to focus on both strategic as well as operational progress and results, while project governance primarily focuses on control to ensure execution of scope, time, and budget constraints.⁶

Program governance must also oversee the management authorization and support for dynamic change and impact to strategic business and operational objectives of the program as a result of shifts in the market and business strategy.

Structuring the Program

The program planning process begins with establishing structure and organization. First, the program architecture consisting of the projects and support functions for the program has to be defined. Next, the IPT core team has to be established and staffed with the appropriate team members as described in Chapter 5. Finally, the program scope, which defines the deliverables and outcomes for each of the projects and support functions, has to be developed.

Before these activities begin, however, the program manager should ensure that all the information about the program that was created from the earlier work cycles is carried forward and shared with the program planning team. A clear understanding of the strategic business goals, business benefits desired, program objectives, and business success factors is critical information needed by the team to ensure that the integrated program plan will be in alignment with company strategy.

Also carried forward from the earlier work cycles are the high-level requirements and a depiction of the whole solution. The high-level requirements are the foundation for the detailed requirements, and the whole solution becomes the basis for developing the program architecture.

Defining the Program Architecture

As detailed in Chapter 4, the program architecture begins with first visualizing the primary components that comprise the whole solution—the projects that directly contribute to the capability being created and delivered. The second piece of the program architecture consists of the support functions that enable the projects. PMI refers to these as “elements of related work outside of the scope of the discrete projects in the program” in its definition of a program.⁷

The program architecture shows which of the core components and enabling components of a program need to be implemented as projects, and which can be implemented as individual work efforts.

With the program architecture defined, the integrated program core team and extended team can be fully formed. It should be noted that selective membership of the IPT core team has already occurred to accomplish the work outcomes of the two previous program cycles.

Establishing the IPT Core Team

In order to create a comprehensive program plan, the program manager must first form an integrated core team. As described in Chapter 5, program team structure is a case of form following function. In other words, the makeup of the IPT core team membership is driven by the functions and disciplines that need to be involved in the program to provide the whole solution, as defined by the program architecture.

However, bringing a group of people together and assembling them as a team does not make them think and behave as a team. Members of a program team must view their work in terms of we instead of me. Meaning we must work together toward a common purpose that is defined by a set of common and agreed upon business goals. The program manager's job is to establish the common purpose and to inspire the team to work collaboratively to achieve the goals. It is the ability of the program manager to create a common vision and the team's willingness to adopt that vision that defines a group of people as a team.

A clearly defined common purpose is instrumental in removing ambiguity surrounding a program, and should answer four key questions: 1) what is the purpose of this team—the mission; 2) what does the end-state look like—the program strategy; 3) what do we need to accomplish to get to the end state—the program objectives; and 4) how will our success be measured—the business success factors. The job of the program manager is to create answers to these four foundational questions with input from the team members and stakeholders.

Defining the Program Scope

Program scope is determined by three key elements of program management: the program architecture, the program-level work breakdown structure (PWBS), and the benefits map. As stated earlier, the program architecture identifies the constituent projects of a program and the necessary functional enablers. The PWBS is a hierarchical decomposition of the deliverables and outcomes needed to realize the program objectives (Chapter 9).⁸ If a project or functional support outcome is not included in the PWBS, it is not needed to achieve the business results desired and therefore should not be delivered as part of the program outcomes.

A common error that occurs when developing a PWBS is mixing both deliverables and tasks. A PWBS should only include deliverables or work outcomes, not tasks.

The PWBS does not eliminate the need for a detailed work breakdown structure for each of the constituent projects on a program. In practice both are required. The project managers use the PWBS as a guide for the scope of work for their respective project, and further break down each deliverable into the tasks and activities necessary to create it.

Projects within a program exist to help ensure a program is successfully executed, and as such, the final activity in defining program scope involves ensuring the project deliverables align to and support the program objectives. As part of the previous program definition cycle of work, program objectives were mapped to expected business results. During the program planning process, this activity continues by mapping project deliverables to the program objectives. The resulting benefits map establishes alignment of project deliverables, to program objectives, to expected business results (Chapter 9).

Creating the Integrated Program Plan

Creation of an integrated program plan requires a high degree of collaboration between the members of the IPT core team. Gone is the time when program leadership is authority-driven with work being performed through a series of directives. Today's era of program team leadership is a more diffused, collective team-based leadership, where directives and decisions are participatory, collective, and democratic. Success of the program manager is dependent upon how well he or she facilitates the alignment of interests, motivation, work activities, and collective outcome of the organizational parts.

With a good understanding of who is involved on a program and what will be delivered as established during the program structuring process, the program team is positioned to create the integrated program plan. Four primary steps are involved in the development of an integrated program plan:

1. Documenting the detailed requirements
2. Developing project plans
3. Mapping cross-project interdependencies
4. Creating the integrated plan

Documenting Detailed Requirements: Creation of a good program plan is contingent upon how well the detailed requirements are defined and documented. If gaps exist in the detailed requirements, gaps will exist in the program plan. These gaps will get addressed, but normally later in the program in the form of scope changes. Likewise, low quality or nonspecific requirements will have to be redefined when someone tries to interpret them and perform real work against them. The later the reconciliation occurs, the more expensive it becomes.

The detailed requirements begin with the high-level business, technical, and customer requirements delivered at the end of program definition. Each member of the integrated core team is responsible for ensuring the requirements needed to perform their specialized functional work are included and adequately stated in the detailed requirements documentation. The detailed requirements must be clear, concise, and thorough, as they are the basis on which the project teams will create their work breakdown structures and project plans.

Once completed, the detailed requirements constitute the program scope and should be managed as living documentation. It is recommended that the program manager initiate a comprehensive stakeholder and peer review of the requirements to check that they are complete with respect to the information known about the program at the given time and that the quality level is in alignment with the quality goals and expectations set forth within the firm.

It needs to be understood that more will be learned about the program as time progresses, and that changes to the requirements may be needed during later stages of a program.

Initial Project Planning: Program managers serve in the capacity of project sponsor for each of the constituent projects on a program. As such, they will initiate the project charters and oversee the project planning process.

For the project managers, one of the realities of program management is that planning a project that is part of a program is strikingly different than planning an independent project. The work of the project manager working within a program construct is complicated by the fact that the project is a component of a larger effort that has many interdependencies. Because a project has to be planned within this larger context, multiple planning iterations may be required.

The first iteration is similar in fashion to planning that occurs on an independent project and begins with understanding the scope of the project. Once the detailed requirements are gathered and analyzed, each project team creates a project-specific work breakdown structure (WBS).

With their project WBS complete, each project team can begin developing their respective initial project plan. We use the term initial project plan intentionally, as a final project plan cannot be developed until all the cross-project interdependencies are identified and comprehended at the program level. Initial project planning ends with an understanding of the deliverables required for each project, the tasks and activities necessary to create each deliverable, and an estimate of time and resources to complete each deliverable. With this information at hand, the project manager is ready to participate in the next step—comprehending the cross-project interdependencies.

Mapping Cross-Project Interdependencies: At the project level, the project teams are concerned with development of their respective deliverables. At the program level, the IPT core team is concerned with the interfaces between the deliverables—which deliverables are needed by whom and when. The creation of the program map is the activity that defines the critical cross-project interdependencies (see Chapter 9 for details on developing a program map).

Each deliverable identified in the program work breakdown structure discussed earlier is displayed on the program map in the correct sequence and point in time. The use of arrows between deliverables depicts the interdependencies between project teams and their respective deliverables. This mapping of deliverables from one project to another helps the program team determine and fully understand the dependencies that exist on a program.

Besides the tangible benefit of understanding the cross-project interdependencies, the program mapping process has the intangible benefit of forging a change in mindset and frame of reference on the part of the project managers and functional specialists on the program. The change of reference involves moving from a project or function-perspective, to a program perspective. Instead of narrowly thinking of success in terms of delivering project outcomes, a broader view of program success in terms of collective success emerges.

Final Project Planning: The program mapping process provides each project manager with critical information that he or she needs to complete their final project plan. Most notably, an understanding of all the deliverables on the program, knowledge about who is dependent upon their team's deliverables and conversely who they are dependent upon, an understanding of the sequencing of deliverables over time, information about any program level constraints such as time, budget, or resources, and any program-level risks that may impact the work and outcomes of their project.

With this program-level information at hand, each project manager can again take a traditional approach to completing their detailed project plan. The program manager should set and communicate a common format and content expectation for each of the project plans. Primary elements that should be included in the project plans include the following:

• Project description
• Project objectives and success criteria
• Project deliverables
• Project schedule
• Project budget
• Team structure and resource profile
• Project risk analysis
• Tracking and reporting methods
• Change management methods
• Team communication strategy
• Project termination plan

To keep the work of the various project teams synchronized, the program manager should set clear milestone dates for project plan completion, and set up periodic reviews to ensure planning work is progressing, and to assist them in eradicating any barriers to successful completion. As changes to the program-level requirements and scope occur, the program manager should quickly communicate the changes to the entire IPT core team, so the changes can be incorporated in the project plans.

Integrating the Project Plans: Once the project plans are completed, the program manager can lead the program team through the creation of an integrated program plan. The program plan incorporates the work of all project teams and all other functional or discipline specific representatives that are part of the program team.

The program plan will vary by program type and situation but should include the following details:

Program Timeline. Using the output of the program mapping process as a starting point, the program team will determine the timeline of the program in the form of the master schedule. For most programs, it does not make sense to create a detailed activity-based schedule based upon the project schedules. The result is usually unmanageable or inefficient to manage. Rather, the program-level schedule should consist of an aggregation of the project and functional-specific deliverables in the form of milestones. The program manager can refer to the more detailed individual project schedules and plans as the need arises.

The use of timeline contingency is highly recommended. Inclusion of timeline contingency is a best practice that increases the probability of program success from a timing perspective. Contingency is a planned amount of time that is added to the estimated schedule to proactively account for errors, misjudgments, and unknown events (risks) that will occur. Contingency is derived from the risk management process and is based upon the various risk responses chosen (Chapter 7).

Resource Plan. Once the initial program timeline is developed, the project managers and the program manager can identify the resources needed to complete each task. The program resource plan is an aggregation of the project resource plans.

It is important to remember that resource estimates include both human resources and nonhuman resources. Nonhuman resources include supplies, materials, and capital equipment that people require to complete their work.

Detailed Program Budget. The program budget represents the organization's financial investment in the program. Much like the development of the program timeline, each project team is responsible for the development of their respective project budgets. The program manager works to aggregate the project budgets into an overall program budget.

The inclusion of budget contingency based upon the program risk assessment is a best practice that increases the probability of program success from a monetary or investment perspective.

The Program Strike Zone. The critical business success factors that were established in the definition cycle of the program can now be completed based upon the program planning work. Additionally, the key performance indicators for the program are established during the program planning cycle. A tool called the Program Strike Zone (Chapter 9) is effective for documenting both the business and performance success criteria against which the program will be measured.

Risk Assessment. A great deal is left unknown at the time a program plan is established. A thorough assessment of the potential problems that may be encountered that could impact the realization of the program objectives should be conducted and incorporated into the integrated program plan.

Each project manager should come into the program planning process with a set of project-specific risks that his or her team identified and assessed. The program manager is then responsible for collecting all risks and leading the integrated core team through an exercise to determine which of the risks are program-level risks and which are project-only risks (Chapter 7). The program risks are then categorized and prioritized by potential impact to the program.

As covered earlier, the risk response information should be utilized to estimate schedule and budget contingencies that are needed to protect the program success criteria in the event any of the risks come to fruition.

Validating the Program Business Case

As the business manager on a program, the program manager needs to ensure that the planning activities remain grounded in achieving the business benefits driving the program. The program business case is the program manager's guiding tool for ensuring that business alignment remains intact. Once the integrated program plan is completed, the program manager and team members need to validate that the program business case is still viable. This seems like an obvious step, but in practice it is a step that is often overlooked. It is crucial that the business case is periodically reevaluated to keep the program feasible from a business perspective. This is especially true at major decision checkpoints.

Staffing the Extended Program Team

Upon approval of the integrated program plan, one of the first activities to take place during program execution is the selection and assignment of all human and nonhuman resources to the program. The program manager is responsible for ensuring that the IPT core team is fully staffed, while the project managers are responsible for staffing their project teams.

The program manager is not responsible for selecting the resources for the entire program. Rather, he or she ensures each project manager has the ability to staff their project team with the number of resources required, as well as fulfill critical skill requirements. If gaps exist in these areas, the program manager should work with functional managers, executive managers, and human resources to fill resource gaps. If critical gaps cannot be filled, changes to the integrated program plan may be required. During the early part of program execution, the program manager should ask for project team staffing reports on a weekly basis to gain visibility into how well the resource ramp is progressing. Once the teams are staffed to the level detailed in the program plan, the program manager should periodically review staffing levels, particularly if there is a change in personnel or a change in requirements and scope.

Facilitating Cross-Project Collaboration

At the program level, program managers not only have to manage cross-functional collaboration, but also the cross-project and cross-discipline collaboration needed to create the whole solution.

Cross-project collaboration during program execution first involves facilitating the highly complex network of project interdependencies in the form of deliverables. The program manager is responsible for ensuring these cross-project interdependencies remain synchronized and coordinated. The program map, which was created and matured during program planning, is one of the most helpful tools for managing the implementation of the deliverables (Chapter 9). The program manager can use the program map as a rolling wave execution tool, focusing the program team on cross-project deliverables due within a four week rolling window, for example. This practice will facilitate the cross-project discussions on status, risks, and issues that need to take place between the project teams.

Managing Program-Level Risk

Team-based risk management is a powerful cross-project collaboration practice. Through team-based risk management, the program team has a greater knowledge of the risks to the program, which helps them think of risk in a broader perspective—in terms of the impact of risk outside of their specialty domain and how cross-project risks must be managed collaboratively.

The program manager is the risk management advocate on the program and is responsible for evaluating, managing, and communicating the overall risk of the program. The IPT core team is responsible for identifying and tracking the key program-level risks across the elements of the program, while the project managers are responsible for identification, assessment, and management of all program and project risk events specific to their discipline. The project managers are also responsible for bringing new risk events identified within their project to the program level for cross-project evaluation and inclusion in the program risk portfolio.

By utilizing the program risk management process similar to the one described in Chapter 7, along with tools such as a P-I matrix (Chapter 9), the program manager can effectively manage the overall risk of the program throughout the execution process.⁹ Program risk must trend downward over time, as cumulative risk is an indicator of program health. As the program approaches the end of execution, program risk will be a deciding factor on whether to release the program's capability.

Managing Change

Change management is a critical practice necessary to control the strategic direction and scope of a program. Changes that impact programs can originate at the business, program, and project level. The organization's governance policies and procedures will normally specify which responsible managers must be consulted and involved in change-based decisions depending upon the impact on the program's benefits objectives. Generally, project-level change focuses on realignment to the program plan. All other types of program changes need to be assessed as to their impact on the business benefits and program objectives.

Historically, uncontrolled change has been a primary cause of program teams' failure to meet their intended goals.¹⁰ During program execution, rapid change is common. Shortly after a baseline plan is approved, changes begin to occur. It is important that the program manager establishes a robust change management process to evaluate change benefit versus cost to the program.

Implementing Program Governance

Program execution never occurs exactly as planned, creating a need for effective program tracking and control practices on the part of the program manager. A program manager can neither eliminate changes in the environment nor avoid all errors made during program definition and planning, but he or she can use good tracking and control techniques to minimize the impact of these factors on the program objectives. Tracking progress of work consumes a large portion of a program manager's time and mind share during program execution.

Whenever possible, the control of the program should be administered within the team. This is a function of the empowerment from senior management to the program manager. Trust and credibility will be further enhanced in the eyes of management when they observe program managers and their teams properly monitoring progress and performance, and taking the appropriate corrective action when the need arises. Program tracking and control consists of the following elements:

• Determining what elements of the program to track
• Deciding what metrics and tools to utilize
• Managing program deviations

What to track: Deciding on what elements of the program to monitor is the foundation of good program governance. Many of the important and critical elements of the program to track will have been decided between the sponsoring executive and the program manager during identification of the critical success factors for the program. This is an area in which a program manager can get buried in the details of the program, if not careful. The program manager should focus on monitoring program-level elements such as major program milestones, overall program budget, cross-project risks, and changes to the program success criteria. He or she should then delegate the detailed tracking and control to the project managers. Project managers will track the progress of the critical elements associated with their functional specialty, with guidance from the program manager on standard elements that he or she wants tracked on all projects.

Metrics and tools: Selection of the program elements to be monitored will influence the metrics used to measure progress, and the tools used to collect the measurements. The same process applies to the elements that will be monitored on each of the projects. The program manager, however, needs to drive standardization of metrics and tools across the project teams.

The business success factors and the KPIs are the fundamental metrics of the program and are fully defined at the completion of the planning phase. During program execution, the program manager should monitor the progress of the program toward achievement of the success factors, as they represent the targets for successful program completion. The program strike zone is an excellent tool to identify the business success factors of a program and to help the organization track progress toward achievement of the key business results desired (Chapter 9).

The program dashboard is a tool that highlights and briefly describes the status of a program based upon the primary metrics selected. It can be used to address a specific program or by senior management to summarize multiple programs within an organization. On a specific program, it provides status information relative to progress toward achievement of major business goals. For executive managers, dashboards can be used to summarize multiple programs underway in order to provide a quick understanding of the status of all programs.

Managing variances: The purpose of program metrics and tools is to monitor the progress of the program team in execution of the program as laid out in the integrated program plan (Chapter 8). If effective, the metrics and tools will give the program manager an early indication that deviations in progress as compared to the program plan have occurred. However, it is not enough to simply detect a variance between actual performance and planned performance. The important aspects of managing the deviation involves understanding what it means, what caused the deviation, and then determining what to do to correct it.¹¹ The program manager may need to adjust project team activities or resources to bring performance back into alignment with the plan. He or she may also need to adjust the integrated program plan to compensate for errors or unexpected changes.

Preparing the Capability Release Checklist

As program execution nears completion, the program team must begin preparation for release of the capability that the program has produced. The capability release plan is part of the overall integrated program plan and is completed during the planning phase. In preparation for the capability release decision checkpoint meeting at the end of program execution, the program manager will lead the team through preparation activities, including the completion of the capability release checklist.

The checklist is a summary-level listing of the primary release activities, with a complete or incomplete indication shown for each activity. Figure 6.3 illustrates this type of checklist, which identifies a set of activities and completion status. Keep in mind that each program is unique, and therefore each will have its own set of activities. The checklist will be a primary item for evaluation during the capability release decision meeting.

Many organizations have found these release checklists so important that they have implemented them for preparation at each decision point for the program team.

Releasing the Program Capability

This step involves formally releasing the output of the program into the operational environment of the business. For a product development program this means beginning to produce the product in saleable quantities. Production processes, supply-line processes, and distribution channels are all turned from development to regular production status. Additionally, the order and fulfillment process begins to take formal orders and fulfills those orders to customers.

For a service or infrastructure program this means formally moving the capabilities from the development and test environment to the operational environment and integrating the capabilities with all other systems within the organization. At this stage, end users are able to exercise the capabilities to their full extent.

For a change transformation program this means introducing the change into the market or organizational environment. Operational support, training and mentoring, and discontinuance of old processes and capabilities have to be carefully managed.

As customers or clients begin to use the capability, the support team begins to respond to requests for assistance and information. All procedures developed by the team now become operational, and customer support metrics are collected.

Likewise, operational support for the capability begins. This may include such things as performing maintenance procedures, fault isolation, testing and repairs of failed units, or technical operational assistance at the customer sites. Many organizations add the new capability to their ongoing sustaining group to ensure that needed quality and process improvements are managed as needed.

The tracking and analysis of the early capability support metrics are critical in effective management of the capability release. With any new capability, defects or other problems may show up once the customer begins using it. Besides ensuring the customer's problem is resolved as quickly as possible, it is also important to understand the cause of the defect or problem and fix it so it does not reoccur. This field data is also of great value to the architects that may be defining the next generation of the capability.

Assessing Benefits Realization

The responsibility for managing the program business continues through program operations as it is during this stage that the business goals from which the program was spawned should be realized. For example, the ROI predicted in the business case should be achieved, the cost savings targets should be met, market segment share gains should be realized, or a new market or market segment should be opened to the company.

Benefits realization during program operations involves ensuring that the business case supporting the program has been achieved and that the program objectives have been realized. Achievement of the business case ensures the realization of the anticipated business results, while realization of the program objectives gives an indication that the strategic business goals of the enterprise have been at least partially attained.

Program governance during operations should focus on ensuring that both the business case and the program strike zone, which contains the program objectives, are continually monitored for progress against business benefits.

Program Knowledge Capture

A program retrospective should be conducted to assess, document, and discuss the successes and recommended improvements for future programs. Collecting and acting upon program key learnings is a necessary step in becoming a learning organization and, in doing so, strengthening the foundation for the next generation of programs.¹² When collecting data, include inputs from the IPT core team, extended team, sponsors, and other stakeholders affected by the program.

Findings should be documented and communicated to key stakeholders in the organization, including the program team, other program managers, functional managers, and executive management. The information should also be used to build a key learnings report and identify process improvement initiatives, as appropriate. Senior managers should understand and convey that the retrospective exercise is directed toward continual improvement of the organization, rather than letting it come across as finger pointing or assigning blame if all did not go well on a program. A manager does not want to limit or minimize the open flow of needed information.

We present the program retrospective at the end of the program, but best-practice companies typically perform a program retrospective following each major business decision checkpoint that focuses on the prior work cycle. The benefit of this approach is that the information is fresh, more comprehensive, more focused on a single work cycle, and learnings are fed back into the organization more quickly.