The previous chapter continued the discussion of how to successfully manage a program utilizing the program management discipline and practices by focusing on program definition and planning. This chapter will complete the discussion by describing how a program is successfully executed.
The role of the program manager during program execution is to manage the horizontal collaboration between the project teams and to ensure that the work of the multiple project teams remains in synchronization, with cross-project interdependencies and deliverables executed as planned. The project managers and other members of the PCT manage the work of their respective functional teams and ensure that the deliverables, milestones, and success criteria are achieved.
In practice it is common for a program to transition from a program manager who specializes in definition, planning, development and launch, to a program manager who specializes in maintenance of business and sustaining activities between the launch and sustain phases of the PLC. The role of the program manager does not change, only the person leading the program team. However, we are beginning to see more companies that are assigning a single individual throughout the life of a program—from concept to end of life. We mention this not to advocate one approach over another but to point out that there is not a single "best approach" to managing a program.
This chapter will put forth a process for program managers to use in program execution. It will explain how to create the intended product, service, or infrastructure capability; launch the solution into the market or customer environment; and sustain the program until end of life.
In doing so, this chapter will also help program managers in the following ways:
Understand the process for implementing the program plan
Describe the primary steps involved in launching a product, service, or infrastructure capability
Discuss key elements in sustaining a program to end of life
Explain behaviors of successful program managers during program execution
Program execution is focused on carrying out the work documented in the master program plan and the functional project plans; it encompasses the implementation, launch, and sustain phases of the PLC, as shown in Figure 7.1.
The primary objectives of the implementation phase are to (1) successfully accomplish all of the design and development work necessary to complete the elements of the product, service, or infrastructure capability under development; (2) integrate the functional elements to create the whole product, service, or infrastructure; and (3) prepare for the launch of the program output into the market or customer's environment.
With the elements of the product, service, or infrastructure capability developed, integrated, and the solution approved for release to the customer or end user, the program enters into the launch phase. The objectives of the launch phase are to (1) methodically and successfully transition the product, service, or infrastructure capability from the development environment (sometimes referred to as the preproduction environment) to the customer environment; (2) ensure that customers are fully supported; and (3) ensure all production and sustaining systems are in place and effectively operating.
Once the necessary start-up activities to turn the product, service, or infrastructure capability into a sustainable and on-going entity are completed, the program enters into the sustain phase of the PLC. The sustain phase of the PLC is the final phase of the program and traditionally signifies the transition from development to support and maintenance of business. The primary objectives of the sustain phase are to (1) keep the program business running as effectively and efficiently as possible, (2) fully support the customers and end users, (3) ensure that the business objectives of the program are attained and that the program remains viable from a business perspective, and (4) efficiently close out the program when it reaches end of life.
The majority of the program team anticipates the program implementation phase of a program. It is when an intangible concept becomes a real, usable, tangible asset for realization of the business objectives that the program is meant to achieve. It is also the part of the program in which the quality of the program plan and the ability of the program manager to lead will be put to the test.
The job of managing a program becomes much more challenging during the implementation phase due to a couple of natural factors. First, the size of the program team and the number of cross-project interdependencies to track and manage grows rapidly between planning and implementation. Figure 7.2 demonstrates this phenomenon. The program profile shows that many elements of the program, such as staff size, budgeted dollars spent, and number of interdependencies, are at their highest levels and peak during the implementation phase of a program. These factors need to be closely managed both vertically within the projects by the project managers and horizontally across the projects by the program manager to ensure that the program stays in alignment with the business objectives. The challenge for the program manger is to remain at what we call the 10,000-foot level of a program and focus on managing the horizontal cross-project collaboration. This means that the program manager has to empower the project managers to manage the details of the five-foot level within their functional discipline. The program manager cannot get sucked down to ground level for very long, or the horizontal collaboration begins to break apart.
The second factor that complicates the management of the implementation phase is that all program stakeholders suddenly become aware of a program's existence, seemingly overnight. It is as though many stakeholders don't pay attention to a program until it becomes real in their eyes, meaning that until a plan has been approved and resources are working to implement it, a program doesn't really exist. When this happens, the program manager has to spend more time away from the program team to manage the expectations and inquiries of the stakeholders—plus, manage the politics now surrounding the program.
In the implementation phase, work of the program team is focused on creating the product, service, or infrastructure capability that was conceived and planned; then, preparing for its introduction into the market or customer environment. Figure 7.3 illustrates the sequencing of work associated with program implementation.
The following steps constitute a general approach for a program manager to use in leading the PCT through the implementation phase of a program. This process is based upon the models used by multiple companies that we deem highly effective in program execution. The general process described can be used as a foundation for creating a customized process by tailoring the steps for any organization.
Like the other phases of the PLC, thus far, the first step in the program implementation phase is to collect as much information coming out of the planning activities as possible. Foremost, the program manager should have the program implementation plan at his or her disposal and should have intimate knowledge of its details.
The detailed requirements in support of the program implementation plan also need to be collected, as they become the foundation for developing the detailed specifications. The detailed requirements are used to create a design, which is used to create a set of deliverables that meet the needs of the end user.[82] The detailed requirements should provide information on customer and end user needs, primary features and functions, technology strategy and targets, and business requirements such as cost and schedule targets.
The program success criteria are the final critical input needed to begin the implementation work. At this point in the program, the entire set of success criteria should be established. They are the set of business, technological, and customer targets that the program plan is aimed toward achieving. These become the boundary conditions within which the program manager and his or her program team can work without senior management intervention. All members of the extended program team should have access to and be familiar with the program success criteria.
Upon approval of the baseline plan, and in conjunction with input collection, one of the first activities that takes place during program implementation is the selection and assignment of all human and nonhuman resources to the program. The program manager is responsible for ensuring the PCT is fully staffed, while the functional project managers are responsible for staffing their respective project teams. This is not to say that the program manager does not assist the project managers in obtaining the qualified personnel, if necessary.
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. Where gaps exist in these areas, the program manager will work with functional management, executive management, and the human resources department to fill resource gaps. If critical gaps cannot be filled, changes to the program plan may be required. In early PCT meetings, during the implementation phase, 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 implementation plan, the program manager should only need to review staffing levels if there is a change in personnel or a change in requirements and scope.
Design specifications are discipline specific and are derived from the detailed requirements of the program. They drive the project team execution and provide technical data concerning functional characteristics, interfaces, integration requirements, operational characteristics, as well as the technological and design constraints of the various subsystems and components.[83] The specifications are the guiding documents for each of the specialized project teams.
The program manager is not directly involved in the creation and documentation of the design specifications. His or her responsibility is to monitor the documentation of the design specifications across the project teams by requiring that the project managers report on specification status during the PCT meetings. This is especially crucial in the early part of the implementation phase until the specifications are fully documented. A program manager for Daimler Chrysler Motor Company shared with us that she will occasionally attend specification peer review sessions to send the message to the execution teams that this activity is important to her and to create a sense of urgency within the program team. She also admits that she always comes away with a better understanding of the program she is leading.
Managing cross-functional collaboration is not new to most experienced project managers. But at the program level, program managers not only have to manage cross-functional collaboration but also cross-project collaboration across the various disciplines needed to create the whole product, service, or infrastructure capability under development. This brings us back to the horizontal nature of programs and the need for program managers to be able to manage in the horizontal dimension (see Chapters 1 and 4).
Cross-project interdependencies: Managing the horizontal or cross-project collaboration during the implementation phase of a program first involves managing 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 the planning phase of the program, is one of the most helpful tools in managing the implementation of the deliverables. If constructed properly, the program map shows each cross-project deliverable, which project team is responsible for delivering it, when it is to be delivered, and to which project team(s) it is to be delivered. The program manager can use the program map in the PCT meetings as a rolling wave planning tool, focusing the core 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.
Risk management: As discussed in the last chapter, team-based risk management is a powerful cross-project collaboration practice. Through team-based risk management, the PCT and extended program team have a greater knowledge of the risks to the program. This helps them think of risk in a broader perspective, in terms of the impact of risk outside of their functional domain and how cross-project risks must be managed collaboratively to be successful.
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 PCT is responsible for identifying and tracking the key program-level risks across the functional elements of the program, and the functional project managers are responsible for identification, assessment, and management of all program and project risk events specific to their functions. The project managers are also responsible for bringing new risk events identified within their function to the program level for cross-functional evaluation and inclusion in the program risk portfolio.
Effective risk management must be practiced throughout the PLC as discussed previously. During the implementation phase, risk management becomes tactical in nature. Trigger events and hinge factors for each of the risks identified in earlier phases need to be monitored and response plans acted upon as necessary. In addition, new risk events should be identified and analyzed throughout execution of the program. It is recommended that the program manager schedule time in the core team meetings on a periodic basis to review risk management activities and progress.
By utilizing the program risk management process similar to the one described in Chapter 8, along with tools such as a risk scorecard and P-I matrix (see Chapter 11), the program manager can effectively manage the overall risk of the program throughout the implementation phase.[84] Program risk must trend downward over time, as cumulative risk is an indicator of program health. As the program approaches the end of the implementation phase, program risk will be a deciding factor on whether to transition from the program implementation phase to the program launch phase of the PLC.
Change Management: Change management is a critical process necessary to control the scope of a program. Historically, uncontrolled scope creep has been a primary cause of a program team's failure to meet its intended goals and success criteria.[85] During program implementation, rapid change is common. Shortly after a baseline plan is approved, changes begin to occur. It is important that a program manager establishes a robust change management process (see Chapter 8) and cross-project change control board (CCB) to evaluate change benefit versus cost to the program. Change management normally begins as early as the definition phase of a program and coincides with documentation and ratification of program requirements. Therefore, the primary factor that the program manager needs to deal with when entering the implementation phase is to ensure the right representatives are a part of and are actively participating on the CCB.
The program manager needs to be the advocate for change management on the program and be persistent and diligent in enforcing consistent behavior across the program. He or she is responsible for implementing the CCB and chairing the CCB meetings, which may be part of the PCT team meetings or a separate meeting. This usually is determined by the number of changes introduced to the program. Many program managers have a fast-track process that they implement via e-mail or collaboration software to handle changes needing a quick decision. The fast-track process, however, needs to be used as the exception instead of the norm to remain effective.
A simple change management process, such as the one described in Chapter 8, a change request form,[86] and a change control log are all that is needed to successfully manage change to the program baseline plan. The program manager should focus on these important elements for successfully managing program change: (1) All proposed changes should come into the process and be reviewed by the CCB, (2) changes should be reviewed repeatedly and consistently, (3) the CCB should have the right membership and active participation on the part of the participants, (4) the CCB should be empowered to approve changes within the program success criteria boundaries, and (5) an established escalation process should be in place to disposition those changes that are outside of the CCB's empowerment boundaries.
Managing cross-project interdependencies, managing program risk, and managing change are three significant program management processes that facilitate the cross-project collaboration efforts involved in the implementation phase of a program. The key factor in all of these processes is getting the project teams to consistently communicate and actively work together to create the integrated solution.
Program implementation never occurs exactly as planned, creating a need for effective tactical program tracking and control practices on the part of the program manager and PCT members. A program manager can neither eliminate changes in the environment or customer needs 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 to the program implementation plan consumes a large portion of a program manager's time and mind share during the implementation phase.
One of the most powerful techniques for minimizing negative impact on a program is proactive program management, which is described in the five boxes throughout this chapter, beginning with "The Five Practices of Proactive Program Management."
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 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
Reporting progress and problems
Requesting assistance
What to track: Deciding on what elements of the program to monitor is the foundation of good management tracking and control practices (see the box titled, "The First Practice of Proactive Management: Program Management Process"). 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 (see boxes titled, "The Second Practice of Proactive Management: Program Management Tools," and "The Third Practice of Proactive Management: Program Management Metrics").
The program critical success factors are the fundamental metrics of the program and are fully defined at the completion of the planning phase. During program implementation, 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.[86] The program strike zone is an excellent tool to identify the critical success factors of a program and to help the organization track progress toward achievement of the key business results desired (see Chapter 11). In our experience, this is one of the most powerful tools available to program managers for tracking and communicating the progress of a program to both senior management and the full-program team.
The program dashboard is a tool that highlights and briefly describes the status of a program (see Chapter 11) based upon the primary metrics selected. It provides specific status information relative to progress of a program toward achievement of major business goals. The report is color coded to signify the status. Green indicates that the program is on track and progressing well. Yellow indicates a key goal of the program is in jeopardy of being missed and represents a "heads-up" to management. Red indicates that a key goal has been compromised and immediate management action is required to recover the situation. In the case of yellow and red status, the report also indicates the actions that the program team is taking to resolve the issue(s). It is expected that management action and priority will intensify as programs are turned yellow and red.
Managing variances: The purpose of program metrics and tools is to monitor the progress of the program team toward implementation of the program as laid out in the master program plan. If effective, the metrics and tools will give the program manager an early indication that deviations in team performance 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 is understanding what it means, what caused the deviation, then determining what to do to correct it.[87] 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 implementation plan to compensate for estimation errors or uncontrolled changes.
Reporting progress and problems: Consistent communication of program progress is a critical element of cross-project collaboration on the PCT. Any significant deviations or changes to the program must be communicated to the project teams by the program manager. In like fashion, any changes that have occurred on any of the projects must be communicated to the program manager and other project teams by the project managers. Late or ineffective communication can quickly result in rework, delays, and added cost during the implementation phase of a program. To ensure open and honest communication between program team members, the program manager needs to create an environment of trust, in which the messenger of bad news will not be punished.
Requesting assistance: The final step in tracking and controlling program progress is recognizing when to ask for assistance and making the request. The request may be for schedule relief, additional budget, and additional long-term or short-term resources. At times a program manager can be hesitant to request help outside of the program team, which is a behavior that has doomed more than one program.
The program manager spends a lot of his or her time reporting the status of the program to various stakeholders. This reporting takes the form of both formal and informal communications, from hallway conversations to formal program reviews and decision-checkpoint meetings. Regardless of whether the status report is formal or informal in nature, the message should remain consistent.
So how does the program manger know he or she is reporting a consistent, comprehensive, and accurate message about a program? The key is in consistent, comprehensive, and accurate collection of status from the project teams and the remainder of the PCT members.
PCT reviews: The PCT should review detailed status for each of the projects on a regular basis. For most programs, the primary agenda for each weekly PCT meeting is project status. Reporting project status facilitates the flow of information within the program, as depicted in Figure 5.9 in Chapter 5.
The program manager needs to be specific on what elements of the projects he or she wants reported, what metrics to use, and what level of detail to include to gain consistency in reporting across the project teams. In practice, this will take some work and time in coaching the core team members, especially with a new team.
An effective tool for establishing cross-project reporting consistency and concise communication of project status during the internal program status reviews is the project indicator. An indicator is a brief, one to two page presentation slide set that shows pertinent project status (see Figure 7.4).
By working with the project teams in developing a consistent format for the indicators, and a consistent set of metrics to report, the program manager will receive a comprehensive and concise report of project status that he or she can use to develop a formal or informal program report.
Program reviews: The program review is an organizational meeting in which each program currently funded within the organization will be reviewed by senior management. Each program manager is required to present the status for the program he or she manages. Even though the program review is a status meeting, it can also be utilized as a decision-making forum for factors that affect a program's key objectives.
The chair of the program review meeting is the executive with financial responsibility for the organization in which the program is funded and executed. He or she is typically a vice president or general manager of development and engineering, business unit manager or, in larger organizations, the director of program management. Required participants in the program review meeting include the business unit manager's staff as well as other invited executives. Attendance by the business unit manager and his or her staff is mandatory. The program review is normally held on a monthly basis. Details associated with preparing for and conducting a program review are covered in Chapter 11.
For consistency in reporting format and message, it is most effective to have an established program status indicator template for use by all program managers. Much like the project indicator used in the PCT meetings, the program status indicator is a brief one to three page presentation slide set that shows pertinent program status (see Figure 7.5). Much of the information contained in the indicator is derived from the most recent project indicators and presented in a summary.
In addition to the program status indicators, the program strike zone and program dashboard tools (see Chapter 11) are normally used in the program review to communicate status toward achievement of the program success factors and the business goals. The objective of the program manager in the review is to communicate both operational and strategic status of the program at the executive level and to use the forum to gain executive help when needed.
As program implementation nears completion, the program manager and core team must begin preparation for program launch. For the launch phase to be executed successfully, preparation for launch must begin during the program implementation phase. This is an example of the overlap between PLC phases.
The program launch plan is part of the overall program plan and is completed during the planning phase. In preparation for the launch approval decision-checkpoint meeting at the end of the implementation phase, the program manager will lead the team through preparation activities, including the completion of the launch-preparation checklist.
The launch preparation checklist is a summary-level listing of the primary launch preparation activities, with a complete or incomplete indication shown for each activity. Figure 7.6 demonstrates this type of checklist, which lists a set of primary launch preparation activities and completion status. Keep in mind that each program is unique and, therefore, each will have its own set of activities, as defined in the program plan. The checklist will be a primary item for evaluation during the launch approval meeting.
The final step in the program implementation phase is to present the status of implementation and launch preparation to the primary program stakeholders for review. Program launch approval is the next major phase/gate decision checkpoint in the PLC. The program manager typically presents the status to the executive decision-making body in the form of a launch proposal in the approval meeting, with assistance from key members of the PCT. As in every program decision-checkpoint meeting, the business case should be updated and reviewed to ensure that the program is still viable from a business perspective prior to moving to the launch phase.
One of three decisions should be made during the launch approval meeting: (1) reject the launch proposal with direction to repeat the appropriate elements of the program implementation phase, (2) reject the launch proposal and cancel the program, or (3) approve the launch proposal with direction to move into the launch phase of the PLC.
Successful completion of the program implementation phase should culminate in the full commitment of funds and resources to launch the product, service, or infrastructure capability into the market or customer environment and to begin sustaining activities (see the box titled, "The Fourth Practice of Proactive Management: The Program Management Organization").
The objective of the program launch phase is to transition the product, service, or infrastructure capability into its intended state of ongoing use. This may be represented by a launch of a new product into production and delivered to customers, the launch of a new information system into the operational environment, or the launch of a new set of services for use by the intended end users.
A successful launch is recognition by senior management that the necessary start-up activities to turn the product, service, or infrastructure into a sustainable and on-going entity have been achieved. It also signifies the transition of the program from solution design and development to solution sustaining and maintenance of business. Figure 7.7 illustrates the sequence of work associated with a program launch.
The following steps constitute a general approach for a program manager to use in leading the PCT through the launch phase of a program. This process is based upon the models used by multiple companies that we deem highly effective in launching products, services, and infrastructure capabilities. The general process described can be used as a foundation for creating a customized process by tailoring the steps for any organization.
The program launch phase signifies the first time the extended program team begins to decline in numbers and the PCT focus shifts from development to delivery activities. A refocus of the team is needed to redirect the work of the program team toward the specific activities of a product, service, or infrastructure launch. Most of the definition, design, and test teams that have been part of the program begin to exit, and teams such as customer support, product support, sales and advertising, and supply chain begin to increase in number and have a more prominent role in management and execution of the program.
The primary responsibility of the program manager is to facilitate the transition of team structure and makeup as quickly and efficiently as possible. This involves integrating new members into the appropriate discussion, decision, and work forums, opening and facilitating new lines of communication and performing team building activities to sustain the identity and motivation of the team. Part of this is communicating the program vision once again and setting direction on the business and program goals.
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 development program this means formally moving the capabilities from the 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.
This represents the formal declaration to the public and general customer base by the company that a new product, service, or infrastructure capability has been released and is ready for sale or use. It is generally accompanied by a publicity blitz at trade shows, in newspapers and trade periodical articles, and other forms of getting the word out regarding general availability.
As customers begin to buy and use the product, service, or infrastructure capability, the customer 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, technical support of the product, service, or infrastructure capability begins as well. This may include such things as performing maintenance procedures, fault isolation, testing and repairs of failed units, or technical operational assistance at the customer site. All performance metrics for products, services, or infrastructure capabilities are also collected.
The tracking and analysis of the early customer and product or capability support metrics are critical in effective management of the launch phase. With any new product or capability release, 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 doesn't continue to reoccur. This field data is also of great value to the architects that may be defining the next generation of the product, service, or infrastructure capability.
The final step in the program launch phase is to present the launch status to the primary program stakeholders for review in the launch completion approval meeting. Program launch completion approval is the next major phase/gate decision checkpoint in the PLC. The program manager typically presents the program launch status to the executive decision-making body in the form of a launch report, with assistance from key members of the PCT.
One of two decisions should be made during the launch completion approval meeting. Management should either reject the results of the launch report, with direction to continue the launch process, or approve the launch report, with direction to move into the sustain phase of the PLC.
Successful completion of the program launch phase should culminate in the full commitment of funds and resources to turn the product, service, or infrastructure capability into a sustainable and on-going entity within the market or customer environment.
When a program transitions from the launch phase to the sustain phase, it transitions from definition, development, and delivery to support and maintenance of business activities. It is important to realize that this new set of activities is just as crucial for achieving the business objectives than those of program definition, planning, and implementation.
The sustain phase of a program is critical for several reasons. Most importantly, it is the phase in which the business objectives of a program are achieved (or not, as the case may be). The sustain phase is also when improvements in the product, service, or infrastructure capability, or the processes supporting them, can be made to increase the profitability of the program. There is also a lot of direct interaction with the company's customer base during this time, more so than any other phase of the PLC. Therefore, customer support activities during this phase are important and will greatly influence the customer's perception of the company. Finally, the sustain phase is the part of the program where the majority of the key learnings about the business, products, or capabilities and the customer can be collected and fed back into the organization for improvement purposes.
Unfortunately, modern literature and training seem to ignore the critical nature of this phase. In most cases, any information about the sustain phase only encompasses the events surrounding program or project closure and auditing, ignoring the other activities. In the following section we provide much detail about this missing information and focus on the primary responsibilities of the program manager and the program team, as illustrated in Figure 7.8.
It is quite common for a program to experience a transition of program managers during the early stages of the sustain phase. This is due to a couple of primary reasons. First, some companies have a set of program managers who specialize in development and a second set who specialize in support and maintenance of business. Second, some companies transfer ownership and management of a program from one organization to another when it transitions into the sustain phase—normally from a research and development organization to an operations organization. However, even though the program manager may change, the program management function does not.
In conjunction with the transfer of ownership of a program from one manager to another, the program team will likely transition too. Program support and maintenance of business requires a different set of specialists and project teams. Most significantly, nearly all the teams associated with developing and launching the product, service, or infrastructure capability will exit the program, and the customer and product support, sales and marketing, supply chain management, and product improvement specialists will take a more prominent role in managing and executing the program.
During this time, the program manager should lead the program team through implementation of the program transfer plan. The transfer plan is part of the overall integrated program plan that was presented in Chapter 6. Implementation of this plan will drive the transfer of functional responsibilities and tasks to the sustaining team.
A significant portion of a program manager's work during the sustain phase is keeping the business surrounding the program operating efficiently. This involves ensuring the cross-project program team continues to provide excellent customer support; provides product support in the form of maintenance, repairs, and replacements; and manages the supply chain and distribution channels cost-effectively.
The responsibility for managing the business for the program and functioning as the GM's proxy continues through the sustain phase. This, in fact, remains one of the program manager's primary responsibilities as described in Chapter 12.
During this phase, the business objectives 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. Tracking and overseeing the strategic goals and tasks of the program is called strategic program control.
Achievement of the business objectives is one of the most rewarding aspects of managing a program during the sustain phase of the PLC. Continued focus on the program vision and business objectives remain the means to ultimate program success.
Part of the overall program plan and business strategy may be to make improvements to the product, service, or infrastructure capability during the sustain phase of the program. These may be minor or major in scope depending upon the goals of the improvement exercise. Likewise, improvement in maintenance of business or support processes and procedures may also be undertaken during this phase.
For example, Intel will normally make both product and process improvements during the course of the sustain phase of a product development program. Improvement to the product in the form of the addition of new features or new technologies are performed to increase the life of the product in the market, to increase or maintain the average sales price (and gross margin), or to increase sales volume. When there are decreases in the product bill of material costs through supplier negotiation and economies of scale purchases, the cost of goods sold decreases and gross margin increases. Improvements in the manufacturing processes and procedures also decreases the cost of each product sold.
Like all other aspects of a program, managing improvements during the sustain phase requires effective cross-project collaboration between specialists by the program manager.
Program closure begins with program planning. The closure plan should be developed as part of the integrated program plan during the planning phase and executed during the sustain phase. When this occurs, the program manager leads the team through all activities necessary for discontinuing the program.
Exact elements of the closure plan vary from company to company, as well as from program to program. But, in general, closure implementation by the program team encompasses the following activities:
Conduct the closure approval meeting: The closure approval meeting is the final decision-checkpoint meeting of the PLC. The objective of the meeting is to review the closure plan and formally approve the discontinuation of the program and of the sale or use of the product, service, or infrastructure capability. The senior executive team of the business is the decision body.
Manage product, service, or infrastructure phase out: Upon approval to close the program, the activities necessary to formally discontinue the sale and/or support of the product, service, or infrastructure capability begin. This includes notification to the customers, vendors, and all support personnel; plan for final buys and production runs; disposition of inventory; finalization of program documentation; and closure of all accounts payable and receivable.
Phase out may also encompass the timing and functional overlap with a replacement product, service, or infrastructure capability. In this case, the program manager will work closely with the program manager of the replacement program to ensure a smooth transition from the old system to the new.
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.[88] When collecting data, include inputs from the PCT, extended team, customers, sponsors, and anyone else affected by the program. Successful elements of the program should be documented, as well as any elements that require improvement.
The role of the PCT is to evaluate, prioritize, and select the key learnings from the information collected. The functional project managers are responsible for gathering input from their functional teams. The program manager is responsible for documenting and presenting the key learnings to the organization.
Findings should be 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 exercise is directed toward continual improvement of the organization, rather than letting it come across as finger pointing or assigning blame. 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 at the end of each phase of the program. The benefit of this approach is that the information is fresh, more comprehensive, more focused on a single phase, and learnings are fed back into the organization more quickly.
Table 7.1 summarizes the steps involved in executing a product, service, or infrastructure program.
Table 7.1. Program execution steps
Program implementation phase | Program launch phase | Program sustain phase |
|---|---|---|
|
|
|
There are a set of important behaviors that we have seen demonstrated on successful programs by both program managers and functional project managers during the execution phases of a program.
Persistence: One of the most important behaviors that a program manager needs during program execution is persistence. During the life of a program, the numbers and wide variety of problems and barriers that arise are enormous. It can take a tremendous amount of drive and persistence to achieve program success. The job is hard work and not for the faint at heart.
Innovative: Due to the number and complexity of problems and barriers mentioned above, many times it will take a great deal of innovation and ingenuity to find winning, acceptable, and reasonable solutions. The program manager must create solutions in a cost-efficient and timely manner and still successfully achieve the objectives of the program.
Firm but flexible: We have made the point throughout the book that the program manager is considerably more than a facilitator for a program. Successful program managers are champions for their programs and are strong leaders that need to be capable of quickly rewarding the team when it is doing well but also possessing the toughness to manage through the hard times. This includes being comfortable with pulling team members aside privately and providing constructive feedback when required.
Networking: The program manager needs to be astute at broad-based communication and networking and also be aware of what's happening across the organization as it directly or indirectly affects a program. He or she should be communicating regularly with senior management and the major stakeholders of the program to ensure that the base of support is there and is continuing.
Program culture also plays a role in effective program execution, as described in the box titled, "The Fifth Practice of Proactive Management: Program Management Culture."
Program execution is focused on implementing the work established in the program plan and the functional project plans and encompasses the implementation, launch, and sustain phases of the PLC.
The program implementation process involves the steps necessary to successfully accomplish all of the design and development work necessary to complete the elements of the product, service, or infrastructure capability under development; integrate the functional elements to create the whole product, service, or infrastructure; and prepare for the launch of the program output into the market or customer's environment.
The program launch process involves the steps necessary to methodically and successfully transition the product, service, or infrastructure capability from the development environment to the customer environment, ensuring that customers are fully supported and all production and sustaining systems are in place and effectively operating.
The program sustain process involves keeping the program business running as effectively and efficiently as possible, fully supporting the customers and end users, ensuring that the business objectives of the program are attained and that the program remains viable from a business perspective, and efficiently closing out the program when it reaches end of life.
A set of important behaviors that highly effective program managers demonstrate during program execution ensure that the work is accomplished efficiently and effectively.
[82] Frame, J.Davidson. The New Project Management. San Francisco, CA: Jossey-Bass, 1994.
[83] Keogh, Jim, Avraham Shtub, Jonathan F. Bard, Shlomo Globerson. Project Planning and Implementation. Needham Heights, MA.: Pearson Custom Publishing, 2000.
[84] Smith, Preston G. and Guy M. Merritt. Proactive Risk Management. New York, NY: Productivity Press, 2002.
[85] Archibald, Russell D. Managing High Technology Programs and Projects. Hoboken, NJ: John Wiley & Sons, 2003.
[86] Milosevic, Dragan Z. Project Management Toolbox. Hoboken, NJ: John Wiley & Sons, 2003.
[87] Lewis, James P. Fundamentals of Project Management. New York, NY: AMACOM publishers, 1997.
[88] Wheelwright, Steven C. and Kim B. Clark. Revolutionizing Product Development. New York, NY: Free Press Publishers, 1992.