The previous chapter began with the discussion of how to successfully implement a program utilizing the program management discipline and practices. This chapter continues the discussion with a focus on how to successfully define and plan a program. Program definition and planning are the first two phases of the PLC, as shown in Figure 6.1.
Simply stated, program definition involves the integration of business strategy with customer (or end user) and technology research to develop a product, service, or infrastructure concept. The feasibility of the concept is then tested through the process of developing and analyzing the program business case that, if successful, ensures the concept is viable from a business perspective. In effect, program definition aligns business objectives with strategy through the development of a new product, service, or infrastructure concept and then proves that the concept makes business sense and will serve as the means to achieve the intended objectives.
Program planning channels the work completed in program definition toward the creation of a cross-project, multidiscipline execution plan that will guide the work of the program team to turn the concept into a tangible product, service, or infrastructure capability.
The role of the program manager during program definition and planning is to facilitate and manage the horizontal collaboration between key representatives of the disciplines involved and to ensure that their work remains in synchronization to produce a well-defined concept, business case, and integrated execution plan. This chapter will put forth a process for program managers to channel research and strategic activities toward the creation of these key program deliverables.
In doing so, this chapter will help program managers and others involved in programs understand how to do the following:
Channel research and business strategy into a concept and business case
Convert a concept and business case into a plan that aligns execution to business objectives and strategy
Define and structure the projects within a program based upon the concept and requirements
Integrate project plans into a cohesive program implementation plan
We described the closed-loop relationship between strategic management, program management, and project management in Chapter 3. Program definition is an extension of strategic management and is the critical element that binds all the functions together to effectively execute the business strategy. Inputs into the definition process include the results of the business strategic management efforts, the customer and/or end user research findings, and the results of technology research programs. Program definition involves integrating the goals, objectives, and ideas generated from these inputs to create potential product, service, or infrastructure concepts and then testing the feasibility of the concepts from a business perspective.
Concept definition and approval is a critically important and difficult exercise due to the lack of incoming quantifiable data. As discussed in Chapter 2, this phase of a program is commonly referred to as the fuzzy front end because people are working with ambiguous information at this stage. Concept definition is as much of an art as it is a science because the people defining the concepts have to predict multiple scenarios that may play out anywhere from one to ten years in the future. As one product marketing research analyst from Intel said, "When I ask our customers what they envision a personal computer being able to do in the next five years, they look at me somewhat strangely and tell me that they're not sure. Right now they're just trying to focus on staying in business and staying relevant in their business."
Regardless of the well-documented challenges associated with the fuzzy front end, as we pointed out in Chapter 2, some of the greatest opportunities for business success lie in the work and the output of the program definition phase. The output of the synthesis of business, end user, and technology inputs to the program definition phase is a set of product, service, or infrastructure concepts (see Figure 6.2).
The role of the program manager during this initial stage of a program is to lead the small concept definition team, define a framework for collaboration, facilitate the cross-discipline team interaction, and focus the team's work on the business objectives desired.[78]
The initial program definition team is normally a small, highly experienced, cross-discipline team. Because a concept is an integration and synthesis of business, customer (or end user) and technology ideas, at a minimum, representatives of each of these disciplines must be part of the definition team. A small, but well represented, definition team may be composed of the following people:
Program manager: Responsible for leading and facilitating the work of the program definition team in the creation of the product, service, or infrastructure concept and championing the intended business objective driving the need for the program
Customer and/or end user representative: Responsible for assessing the market, representing customers' or end users' wants and needs
Engineering representative: Responsible for assessing the early design considerations to determine if the new idea can be designed and built
Architect: Responsible for technology research findings and ideas and for assessing the use of existing or new architectures and processes to create the product, service, or infrastructure capability
Financial representative: Along with the program manager, responsible for assessing the financial feasibility of the concept
The following steps constitute a generic approach for a program manager to use in leading the program definition team through the development and approval of a product, service, or infrastructure capability concept. This process can be used as a foundation for creating a customized process by tailoring the steps for any organization.
The business, customer, and technology objectives that the program is intended to achieve must be clearly identified in this early stage and communicated throughout the life cycle. They become the cornerstone on which the product, service, or infrastructure concept and program are built, as well as the primary success criteria against which program execution and closure are measured. The objectives are 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. The objectives must be specific, measurable, realistic, and time related.[79]
The program manager will derive the initial business objectives from the output of the strategic management process and decompose them into more detailed requirements for the specific program being defined. Customer objectives can be derived from the information gained by performing customer and end user research. Technology objectives are the primary output of technology research efforts that invest in the development of new materials and technologies to be transferred to products, services, or infrastructure applications. The transfer of technology discussions occurs early in the strategic planning process and become more comprehensive as specific programs are defined.
The program manager uses the business, customer, and technology objectives to develop the initial critical success criteria for the program. The program strike zone is an exceptional tool for collecting and communicating the program success criteria (see Chapter 11); it can also be used by the program manager to keep the program definition team focused on achieving the intended objectives.
The heart of the definition phase is the product, service, or infrastructure concept. Technology research, customer research, and strategic planning efforts must converge to create a concept that will best achieve the business objectives of the program. Deriving a concept, or set of concepts, is an iterative process that involves the integration and synthesis of the ideas of the subject matter experts on the definition team. The program manager should lead the ideation process and continually focus the output toward the 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 critical success criteria, and testing the concept feasibility from a business perspective.
The final stage of the concept definition process is the presentation of the product, service, or infrastructure concept to the primary program stakeholders for approval. This is normally the first major decision checkpoint in the PLC. It is effective if the program manager facilitates the concept approval meeting and presents the initial program critical success criteria for review and approval by the stakeholders. The program manager can then turn the review over to the other members of the program definition team to present their aspects of the product, service, or infrastructure concept.
One of the following three decisions should be made during the concept approval meeting: (1) reject the concept(s) with the direction to redefine all or part of the concept(s), (2) reject the concept(s) and cancel the program, or (3) approve the concept(s) with direction to move into the back half of the definition phase to develop the business case.
The program business case is a guiding document used by senior management to assess the feasibility of a program from multiple business perspectives; it is also used by the program team as its primary chartering document. It establishes the program vision by describing a business opportunity in terms of alignment to strategy, market, or customer needs; technology capability; and economic feasibility. It also provides a balanced view of the business opportunity versus business risk.
The program business case contains the most important information available at this early stage of a program. It will be used to determine if the business unit should invest financial, human, and capital resources to plan, develop, launch, and support a new product, service, or infrastructure capability.
The role of the program manager during this aspect of the program definition phase is to lead the definition team toward the creation of a successful business case and present the business case to the primary program stakeholders for approval (see Figure 6.2).
The steps in the following sections constitute a generic approach for a program manager to use in leading the program definition team through the development and approval of a product, service, or infrastructure business case. This process can be used as a foundation for creating a customized process by tailoring the steps for any organization. See Chapter 10 for a description of the elements commonly found in a program business case.
Business and high-level technical requirements must be developed, documented, and delivered during the program definition phase. The program manager is responsible for collecting and documenting the high-level requirements during this phase of the program. The importance of diligently defining requirements cannot be overstated, as requirements are the basis for program planning and engineering activities. Poor requirements will result in poor planning that will result in poor execution and failure to meet the business objectives.
Once the concept is approved, gathering and documentation of requirements should begin. The program manager should work with the content experts who represent the various functional disciplines on the program definition team to collect the requirements. At the close of the definition phase, requirements must be documented in sufficient detail to describe the product, service, or infrastructure concept; key features and functions; end user needs; time-to-money window; and cost and financial targets at a minimum.
Once the product concept is defined and high-level requirements documented, a thorough risk analysis can be conducted to properly estimate the probability of both technical and business success of the proposed program. This risk-based approach allows managers to make decisions based on greater knowledge of the product, service, or infrastructure concept under evaluation.
The program manager should lead the risk identification and assessment activities, with involvement of the program definition team. The objective of this exercise is to attempt to identify as many unknown events that may occur and potentially prevent the program from succeeding. With the risks identified, the team can assess the severity of each risk event, with respect to both the probability that the risk event will occur and the impact to the program if it does occur. It is important to note that this exercise happens very early in the program and little is actually known about the risk events. Therefore, quantifiable data to support the risk analysis will be difficult to develop. It is recommended that each risk be evaluated on a qualitative basis as high, medium, or low severity.
The program manager and definition team should next evaluate the level of complexity and how well the program aligns with the business strategies of the organization. This information will be used to evaluate the program within the context of the entire portfolio of programs, once the program business case is approved. It is recommended that this assessment be completed as part of the program business case.
The program manager can evaluate the complexity of his or her program through the use of the complexity assessment tool described in detail in Chapter 10. Program complexity will help identify the categories of risk the program will be faced with and can be used to determine the amount of contingency reserve to build into the program budget and schedule—the more complex the program, the larger the reserve. Finally, the complexity assessment can give the program manager an indication of the level of skill and experience needed for the program team.
The program alignment matrix (see Chapter 10) can be used to establish the degree to which the program is aligned with the organization's business strategy. The alignment assessment aids the program manager to understand how well his or her program supports the strategic objectives of the firm. It also gives senior management another important dimension for evaluating the feasibility of a proposed program concept. With this in place, each program concept can be evaluated on the basis of cost, benefit, risk, and strategic importance.
Multiple concepts may be developed during the definition phase. If this is the case, a feasibility assessment is required prior to the business case completion to select a single concept to present to the primary program stakeholders. With the concepts defined and a risk assessment complete, the program team can validate the concepts from business, customer, and technical perspectives. Each concept is evaluated on its own merit and then compared to the feasibility results of the other concepts. At the end of the evaluation, a single concept should be selected and the business case completed.
The final step in the program definition phase is to present the program business case to the primary program stakeholders for approval. This is the first phase/gate decision checkpoint in the PLC. The program manager typically presents the program business case to the executive decision-making body in charge of the business's portfolio of programs.
One of the following three decisions should be made during the business-case approval meeting: (1) reject the business case with direction to repeat the appropriate elements of the program definition phase, (2) reject the business case and cancel the program, or (3) approve the business case with direction to move into the planning phase of the PLC.
Successful completion of the program definition phase should culminate in the commitment of funds and resources to develop a detailed implementation plan and the addition of the program to the business's portfolio and the program road map.
"Planning is everything." That's how a program manager from Ford Motor Company describes the importance of program planning. It seems to be innately attractive to many individuals to just jump in, start taking action, and doing things. Action-oriented individuals many times have a difficult time with planning activities. How many times have you heard it said, "Let's just do it; we know what needs to be done and how to do it."? Many believe that spending time in meetings doing planning is a waste of time. However, as we have observed on several occasions, these same individuals eventually learn to appreciate the value of planning before execution begins in earnest once cost overruns, schedule slips, and program cancellations begin to occur. Most of us have learned through experience that early and effective planning does prevent poor performance and problems such as late time to money, missed commitments to customers, and quality issues.
In the program planning phase, all work is focused on developing an integrated master program plan. Program plan development involves integration of information from all functional elements represented in the definition and scope of the program. The primary objectives of the program planning phase are threefold, as follows: (1) develop and understand the scope of the program, (2) develop the integrated cross-project implementation plan, and (3) submit and review the implementation plan with executive decision makers to gain approval to enter into the program implementation phase of the PLC. After the program plan is developed and approved, it becomes the road map to program success. Figure 6.3 illustrates the sequencing of the primary steps in developing a program implementation plan.
The steps in the following sections constitute a generic approach for a program manager to use in leading the PCT through the development and approval of a detailed program implementation plan. This process is based upon the planning models used by multiple companies that we deem highly effective in program planning. The process described can be used as a foundation for creating a customized process by tailoring the steps for any organization, keeping in mind that program planning can be situational in nature (see the box titled, "Different Programs, Different Planning Situations").
Different Programs, Different Planning Situations
We certainly subscribe to good program planning. The question always arises, however, how much detail is needed in a program plan? The answer to this question usually lies in the type of program to be planned.
Using a simplified 2×2 matrix of program types (see Figure 6.4), a program manager can determine the amount of detail needed in his or her program plan.[80] The program type is based upon the following two variables: technology novelty and program complexity.
A routine program is one having a low level of technology (less than half of the technologies are new) and low complexity (few cross-project interdependencies). An administrative program is low in technology but high in complexity (many cross-project interdependencies). A technical program is high in new technology use (more than 50 percent of the technologies are new) and low in complexity. A unique program is high in both technology content and the number of cross-project interdependencies.
The amount of detail needed in a program plan depends upon the type of program, referred to as situational planning. In general, the higher the program complexity, the greater detail required in the program plan. The greater the technology content, the greater the uncertainty or technical risk of the program outcome. This calls for a plan with fewer details but more schedule and budget buffers included in the plan.
The first step in developing a program plan is to collect as much information about the program as possible. The program manager should have the information from the program concept and business case at his or her disposal, but if this is not the case, this information should be the first to be collected.
A clear understanding of the strategic business objectives that drive the need for the program is critically important to ensure the program implementation plan is in alignment with company strategy; therefore, any output information from the strategic management process should be collected. This includes all information about the program that is contained in the portfolio of programs and the program road map.
The high-level requirements in support of the program business case also need to be collected, as they become the foundation for developing the detailed requirements. The high-level requirements should provide information on customer and end user needs, primary features and functions, technology strategies and targets, and business requirements such as cost and schedule targets.
Program planning is a team effort involving the program manager and his or her PCT members. Following the approval of the business case, and in conjunction with collecting program inputs, the program manager will set out to form the full PCT. As described in Chapter 5, program team structure is a case of form following function. In other words, the make up of the PCT members is driven by the functions that need to be involved in the program to provide the whole solution, as described by the program concept and business case.
The role of each functional project manager is to develop the detailed plan within his or her domain. The role of the program manager is to integrate the functional project plans into one cohesive program plan. Depending on the size of the program, planning can require a large commitment of time and energy from the PCT.
A key responsibility for the program manager is to set the vision for the team. The program vision grounds the team on where the business is going, what it takes to get it there, and how this particular program fits into that picture. [81] The program manager should ensure that the vision and requirements for the program are sufficiently understood to the point that the members of the team internalize the program objectives as their own and are as motivated as the program manager to achieve the program's success.
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 normally will get filled but later in the program in the form of scope changes, which become more expensive as time progresses due to increased amounts of rework. 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 the definition phase of the program. Each member of the PCT 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 functional project teams will create their work breakdown structures and functional plans.
Once completed, the detailed requirements constitute the program scope and should be managed as a living document (see the box titled, "The Situational Approach to Scope Management"). From the requirements, a program-level work breakdown structure (WBS) can be developed if the program manager feels it will be helpful and useful to the PCT. It is recommended that the program manager initiates 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 sufficient.
It needs to be understood that more will be learned about the program as time progresses, and there may be many changes in requirements during the remainder of the planning phase and the implementation phase that must be captured and documented in the detailed program requirements.
The Situational Approach to Scope Management
It is no secret that scope needs to be defined in a timely manner. We have witnessed some programs that were fully scoped early in the PLC, and others that weren't fully scoped until later in the PLC—with both approaches being praised as sufficient and timely. So why the variation in the scope timeline between the programs?
The answer again is that there are varying types of programs, with varying requirements for scope timeliness. The 2×2 matrix shown in Figure 6.4 identifies the four program types—routine, administrative, technical, and unique. Detailed program scope can be frozen at varying points in the PLC, depending upon the program type (see Figure 6.5).
Routine programs have low levels of technical uncertainty and cross-project interdependencies; therefore, program scope can usually be frozen quite early in the planning phase of the PLC. Administrative programs require more cross-project collaboration, which means that program scope freeze takes longer than for routine programs. However, scope freeze can be achieved by the midpoint of the planning phase.
By contrast, technical and unique programs carry a high level of technology risk that usually delays the completion of the detailed scope definition. For technical programs, therefore, program scope freeze usually occurs early in the implementation phase, even later for unique programs due to the large number of cross-project interdependencies involved.
This process is referred to as situational scope management in which program scope and scope freeze is dependent upon the type of program defined.
Once the program-level requirements and scope definition are completed, the requirements must then be dissected by each of the project teams on the program to create their respective project-level WBS and project plan. The WBS is a deliverable-oriented grouping of all functional elements that organizes and defines the total work scope of each project.
The WBS is a hierarchical representation of the project that facilitates the scheduling, budgeting, resource allocation, and control activities for the functional project manager and the program manager. It is a key element of the planning process utilized to transform requirements into functional project elements (tasks) and deliverables. When managers create a project-level WBS, they must understand the project deliverables within the program and envision each functional project as a hierarchy of goals, objectives, and tasks that must be accomplished to successfully begin and end a project.
With each 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 the integrated program plan is created. At that point, the initial project plan is updated to reflect the changes that were made during the integration process.
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 and objectives
Project deliverables
Critical success criteria
Project schedule
Project budget
Team structure
Resource profile and staffing plans
Project risk analysis
Tracking and controlling methods
Change management methods
Team communication strategy
To keep the work of the various project teams synchronized, the program manager should set clear milestone dates for project plan maturity and completion. He or she should also set up periodic project plan reviews with each of the project managers 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 PCT, so the changes can be incorporated in the project plans.
Once the initial project plans are completed, the program manager can lead the PCT through the creation of an integrated master program plan. The program plan incorporates the work of all project teams, the interdependencies between the teams, and all other functional representatives that are part of the program team.
The program plan will vary by program type and situation (see box titled, "Situational Program Planning") but should include the details necessary to execute program implementation, launch, transfer and/or sustaining, and closure.
Situational Program Planning
Program planning approaches, as well as the details contained in each program plan element, vary by program type. This is the basis of situational program planning. Figure 6.6 summarizes this variation according to the four program types previously identified—routine, administrative, technical, and unique.
Routine programs are low in technical novelty and complexity and are, therefore, quite stable in nature. This normally results in clear business goals and a well-defined scope, requiring a simple WBS with few levels of detail. Program schedules can be created using simple Gantt charts, which informally recognize the cross-project interdependencies without showing them in detail. With precise business goals, scope, and a simple schedule, the team can develop a precise bottom-up cost estimate and risk response plan.
Administrative programs are high in complexity and low in new technology introduction. Business goals and scope are normally well-defined, stable, and detailed. Added complexity requires mapping of the many cross-project interdependencies, but the technical stability allows for standard scheduling techniques. The same added complexity generally means larger program size, with higher financial exposure, justifying the need for detailed bottom-up cost estimates reconciled with financial targets contained in the program business case. Risk is primarily related to the increased number of interdependencies between the project teams; therefore, risk management should be tiered, focusing on both program-level and project-level risks.
Technical programs have a high number of new technologies that often requires time to fully define the business goals, scope, and WBS for the program. Still, the goals, scope, and WBS are simple due to the low level of complexity. For the same reasons, the schedule becomes fluid and readily reshaped to account for goal and scope changes. The rolling wave approach (RWA), or similar approach, can be used. This means that only the schedule for the following 60–90 days are planned in detail, while the remainder of the program schedule is represented by milestones. Similarly, cost estimates are fluid as well. A detailed cost estimate for the next 60–90 days can be detailed, while cost estimates for the remainder of the program are at the summary or rough order of magnitude level. The increased technical novelty results in increased technical risk and the need for more rigorous risk management implementation and tools.
For unique programs, business goals, detailed scope definition, and WBS development takes time to evolve as a result of many new technologies and cross-project interdependencies. The evolving nature of scope leads to the need for fluid schedules. Program mapping and rolling wave scheduling processes can be used to contend with the fluidity. Similarly, cost estimates for milestones are more detailed in the near-term and more summary level for the longer term. Combined novel technologies and complexity push risks to the extreme, making it the single most challenging element to manage. In response, a rigorous risk management plan is needed, as well as a combination of tools such as the P-I matrix (see Chapter 10) and Monte Carlo Analysis (MCA).
Program Schedule: To create an integrated plan, the work of the various project teams and the interdependencies between them first have to be comprehended. This is accomplished through the program mapping and scheduling processes (see Chapters 8 and 11). The interdependencies between the project teams are identified and planned through the mapping process, which when complete also yields an initial timeline for the program. This is the basis for developing the program schedule, which is the heart of the program plan and of the program itself.
It should be noted that the timeline developed during the program mapping process is a low-confidence-level schedule, usually lower than 50 percent probability of success (same as flipping a coin). Nevertheless, we consistently hear war stories of missed delivery and launch dates because the program was planned on a low-confidence-level schedule that was the result of a program mapping exercise. The schedule must go through several iterations to account for errors, misjudgments, and unknown events (risks) that will occur.
Resource Planning: Once the initial program schedule is developed, the functional project managers and the program manager can identify the resources needed to complete each task within the required time constraints. 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. The result of resource planning is the program resource profile, which details the resource demand for the program.
The program manager is responsible for working with the functional managers of the organization to make sure each functional project is adequately staffed. If resource capacity is insufficient to meet demand, the program scope and/or timeline must be reconciled to balance capacity and demand—the triple constraints apply to a program as well. In some cases, time estimates need to be adjusted based upon the skill and experience levels of the people assigned to the various tasks.
Detailed Program Budget: The program budget represents the organization's financial investment in the program. Much like the development of the program schedule, each project team is responsible for the development of their respective project budgets. The program manager works with the PCT to integrate the project budgets into an overall program budget. Budgeting is addressed in the planning phase of the program management model, but is a key element of each phase of the life cycle. A rough order of magnitude estimates are established in the definition phase to determine financial feasibility of the program, the detailed budget is established in the planning phase, and budget expenditures are monitored and controlled during the implementation, launch, and sustain phases.
The Program Strike Zone: The initial program critical success criteria that were established in the definition phase of the PLC can now be completed based upon the program planning work to date. A tool called the program strike zone (see Chapter 11) is very effective for identifying the success criteria against which the program will be measured for completion and for establishing the boundaries within which the PCT can manage the program and make decisions without direct involvement of senior management. The program strike zone needs to directly reflect the program objectives established in the business case, as well as key elements of the program plan such as completion date, product cost, budget, and quality targets. As part of the plan approval process, the program manager and senior management negotiate and agree on the success criteria and what actions will be taken when success criteria thresholds are compromised.
Risk Assessment: Once the primary program elements are developed, the PCT should perform a detailed program-level risk identification and assessment. Each functional 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 from the functional teams and leading the PCT through a risk analysis exercise to determine which of the risks are program-level risks and which are project-only risks (see Chapter 8). The program risks are then categorized and prioritized by potential impact to the program. As discussed in Chapter 11, the P-I Matrix tool can be used to identify program risks, assess the probability of occurrence and potential impact, and provide a representation of risk severity to facilitate effective program decision making.
It is recommended that only the highest-level risk events be formally included in the program plan. However, all risk events need to be tracked and managed through the program risk management process for the duration of the program. During planning, the risk information should also be utilized to estimate schedule and budget buffers that are used to protect the program success criteria in the event any of the risks come to fruition.
With the primary elements of the integrated program plan now completed, each project plan needs to be updated to reflect any changes that occurred during the integration process. This step ensures that the project plans stay in synchronization with the master program plan.
Once the detailed program plan elements are completed, the program manager and key PCT members need to validate that the program business case is still viable. At a minimum, this involves reevaluating the program financials, alignment index, and benefit versus risk analysis, plus verifying that the results still support the strategic business results of the program.
This seems like an obvious step in the planning process, but in practice it is a step that is often overlooked for a number of reasons. Once detailed planning and execution activities begin in earnest, it becomes difficult to view the program from business and strategy perspectives. It is crucial that the business case is periodically reevaluated to keep the program viable from a business perspective. This is especially true at major decision checkpoints of the program.
The final step in the program planning phase is to present the implementation plan to the primary stakeholders for approval. The implementation plan approval is the next major phase/gate decision checkpoint in the PLC. The program manager typically presents the program implementation plan to the executive decision-making body, with assistance from key members of the PCT. Additionally, the updated program business case should be reviewed to ensure that the program remains viable from a business perspective.
One of three decisions should be made during the implementation plan approval meeting: (1) reject the implementation plan with direction to repeat the appropriate elements of the program planning or definition phase (2) reject the implementation plan and cancel the program, or (3) approve the implementation plan with direction to move into the implementation phase of the PLC.
Successful completion of the program planning phase should culminate in the full commitment of funds and resources to develop the product, service, or infrastructure capability on the part of executive and functional managers. Communication to customers and end users concerning the details of the program can now begin to take place.
Table 6.1 summarizes the steps involved in defining and planning a product, service, or infrastructure program.
There are a set of important behaviors that we have seen demonstrated on successful programs by both program managers and functional project managers, specifically during the definition and planning phases of a program.
Table 6.1. Program definition and planning steps
Program Definition Phase | Program Planning Phase |
|---|---|
|
|
Willingness to take the lead: The program manager needs to take a leadership role during both the program definition phase and program planning phase. The early program team is primarily composed of specialists from multiple functional disciplines that normally are not effective in leading a cross-discipline team. When the program manager fulfills this role, all viewpoints are considered and the work is focused toward achievement of the program vision and business objectives intended.
Empower the team: The program manager must be willing to share the empowerment granted to him or her with the functional project managers on the program team. Likewise, the project managers must share their empowerment with their respective team members. Full-team empowerment is a powerful tool in quick and effective decision making in which people closest to an issue are able to evaluate the situation and decide the proper course of action.
Demonstrate integrity and trustworthiness: The program manager and project managers should set the example in the areas of working with a high degree of integrity and build the trust of team members and program stakeholders. As a leader, integrity and trust are the foundational elements of credibility.
Take ownership: The program manager needs to display total ownership for the management and outcome of the program. He or she needs to be ready to take total responsibility for his or her own actions and the actions of the team. Additionally, the program manager should champion the program inside and outside the organization.
Exhibit fairness: The program manager needs to exhibit fairness and balance between cross-discipline representatives on the program team. This means being able to set aside any historical bias toward or against a particular discipline that he or she may have had in the past. Exhibiting fairness also means setting the expectation that all others on the program team behave in the same manner. Failure to do so can foster unhealthy team dysfunction.
Be organized and disciplined: Program managers and project managers alike need to be good at organizing and managing the details on a consistent and continual basis. Programs are complex undertakings, and without a high degree of organization on the part of the team leaders, program details can quickly become unmanageable.
Communicate effectively: The program manager is the voice of the program during the definition and planning phases. He or she must be willing and able to communicate in all directions and at all levels within the organization. It also means being good at both verbal and written communication methods, being consistent in delivering messages, and being able to tailor the communication for the level and interest of the recipient.
The program definition process involves the steps necessary to integrate business strategy, customer and end-user research, and technology research into a viable product, service, or infrastructure concept. Then, test the viability of the concept through the creation and analysis of a comprehensive program business case.
The program planning process involves the steps necessary to channel the product, service, or infrastructure concept into a cross-project, multidiscipline implementation plan. When executed, the program plan will guide the work of the cross-project implementation team to turn the concept into a tangible product, service, or infrastructure capability that will become the means to achieve the business objectives intended.
A set of important behaviors that highly effective program managers exhibit during the program definition and planning phases ensure that the work is accomplished efficiently and effectively.
[78] Martinelli, Russ. "Taming the Fuzzy Front End", Project Management World Today (July-August 2003).
[79] Doran, George T. "There's a S.M.A.R.T. Way to Write Management Goals and Objectives." Management Review (November 1981): pp. 35–36.
[80] Shenhar, Aaron J. "One Size Does Not Fit all Projects: Exploring Classical Contingency Domains". Management Science, 47(3), 2001: pp. 394–414.
[81] Wheelwright, Steven C. and Kim B. Clark. Revolutionizing Product Development. New York, NY: Free Press Publishers, 1992.