Chapter 7
Program Management Practices
The previous chapter described how a program can be managed through a series of business decision checkpoints and work cycles. Rather than advocating a prescriptive approach, we presented a framework in which an organization can nest its preferred processes and methodologies.
In like manner, we do not advocate a prescriptive approach to implementing a set of program management practices. We know from experience that each organization is unique and needs to implement the practices that best fit its business processes, culture, and level of program management maturity.
There are, however, a number of core program management practices that we see being used consistently across business sectors. In this chapter we present this set of core program management practices and explain how they are commonly used to manage a program to success.
Benefits Management
Benefits management is about realizing the business results desired from the investment in a program. In a recent blog, a gentleman made the case that the primary directive of program management was to achieve the program objectives.1 Another person joined the discussion and made the case that program management was instead about achieving business results and benefits management was really the primary directive of program management. We are in this person's camp. This extension in thinking was encouraging to observe and demonstrated to us that people understand the true value of program management. Benefits management at the program level is about management of the business goals and achievement of the business results driving the need for the program.
Benefits Management Strategy
Creating a benefits management strategy in effect involves identifying the specific business results that a program must deliver to directly support the strategic goals of the business. As we explained in Chapter 6, this occurs early in a program and is central to the program definition work cycle.
The benefits management strategy is the foundation of the business case for a program. It defines how a program will contribute to the realization of a firm's strategic goals if the program is funded and properly executed.
In Chapter 3 we described how, for program-oriented organizations, program management is part of the business engine of the firm. The benefits management strategy is the keystone element that ties the strategic management, portfolio management, and program management components of the business engine together as a coherent management system.
Benefits Mapping
Creating strategy is critically important, but can be a wasted effort if the setting of strategy is not followed by successful execution of strategy. This is true as well for benefits management. The process of benefits mapping ensures the execution outputs from the constituent projects of a program support the benefits management strategy and the business results anticipated.
First created during program definition and then refined during program planning, the benefits map establishes direct alignment of project deliverables or outcomes to the program objectives, and then to the expected business benefits and strategic goals of the firm. Creating a benefits map is detailed in Chapter 9.
Benefits mapping and the resulting benefits map are necessary elements for defining the program scope and the benefits realization plan, both of which are core components of the program business case (Chapter 6).2
Benefits Tracking
The process of benefits tracking involves periodically examining the progress of a program toward achievement of the expected benefits. In practice, firms have found that it becomes increasingly more difficult to terminate a program the longer it is in existence.3 If the critical business success factors are properly defined and consistently reviewed as part of the program governance system, the means to objectively evaluate the value of a program is available to the program sponsor and governance board at any time during the life of a program. More importantly, the sponsor and board have the ability to stop or realign a program to the benefits desired if changes to the environment or program make it necessary.
Program managers should ensure there is a specific distinction between the business success factors for a program and the key performance indicators. Both are important for tracking progress of a program. But a key performance indicator such as performance to budget may not define program success in the way that a business success factor such as $200,000 in sales force expense reduction per year does.
Benefits Realization
As pointed out in Chapter 6, there is often a delay between the release of the program capability and the full realization of the business benefits resulting from the use of the capability. Effective program management means diligent benefits management through focused attention on achieving the program business case. It is necessary to spend the time and effort to get the business case right and to gain support by the key stakeholders. Managing the program to the intent of the business case and delivery of the program output become the means to realize the business benefits desired.
Benefits Management Practices
Benefits management is the foundation of program management, and for this reason a program should be defined by the benefits it delivers. Benefits management runs throughout the life of a program, from initial ideation to program closure and beyond. Benefits management begins with business benefit identification during the program definition work cycle when specific business results needed to attain the strategic goals of the program are identified. As part of this process, the business success factors are documented and validated by key program stakeholders.
Key to benefits management is the development of the program business case that supports an investment decision. The potential business benefits to be gained are weighed against the investment cost of implementing a program.
Execution of a program is guided by the business success factors contained in the business case that keep a program aligned to the business benefits desired. Ultimately, program closure occurs when it becomes clear that the business benefits have been realized, are well on the way to being realized, or in the case of termination, cannot be realized. Program success is assessed against the attainment of business benefits and realization of the strategic business goals.
Stakeholder Management
A stakeholder is commonly defined as anyone who has a vested interest in the outcome of a program. More importantly, for a program manager, a stakeholder is anyone who can influence, either positively or negatively, the outcome of a program. This includes people and groups of people both inside and outside the organization. Stakeholder management is a process with which a program manager can increase his or her acumen in managing the political, communication, and conflict resolution aspects of his or her program to ensure a positive outcome.4
In Chapter 1 we introduced the concept of the program management continuum that identifies various ways in which program management is implemented and practiced in organizations. As the program management function within an organization grows stronger and more influential (moving from left to right on the continuum), the more important effective stakeholder management practices become in order to successfully manage programs on a consistent basis.
This is due to the fact that as an organization transitions from a project-orientated to a program-oriented business, the accountability for success relies more and more on the program manager—a person who has limited positional power within the organization, yet still owns the responsibility for program success. In addition to empowerment from senior leadership, a program manager must work to earn cross-organizational empowerment from the building of strong relationships and successfully influencing key stakeholders.5
Stakeholders are many and varied on a program, and come to the table with a variety of expectations, opinions, perceptions, priorities, fears, and personal agendas that many times are in conflict with one another.6 The challenge, therefore, is to find a way to efficiently manage this cast of characters in a way that does not become all consuming. Fundamental to efficiency is being able to identify and separate the highly influential stakeholders and then create and execute a stakeholder strategy that can strike a balance between their expectations and the realities of the program.7
Stakeholder Identification
Effective stakeholder management begins with identification of all stakeholders associated with a program. To begin with, the list of stakeholders should be comprehensive in order to cast a wide net over all players who may have a vested interest in the outcome of a program.
Tools such as a stakeholder map are common, and can be effective in helping a program manager identify the various stakeholders. The stakeholder map should include internal stakeholders such as executive managers, program governance board members, department or functional managers, support personnel (accounting, quality, human resources), and the program team. External stakeholders should also be listed and may include contractors, vendors, regulation bodies, service providers, and others. The objective of stakeholder identification is to include anyone who might have influence on the outcome of the program.
Stakeholder Analysis
Stakeholder analysis begins with the categorization of stakeholders into the logical groups that they belong to. Such categories may include senior sponsors, executive decision makers, team members, and resource providers to name a few. It is important to realize that some stakeholders may belong to multiple groups. The intent of stakeholder categorization is to bring structure to the stakeholder list based upon common interests in the program.
With categorization complete, stakeholder analysis turns to determining what type of influence each stakeholder has on the program, such as decision power, control of resources, or possession of critical knowledge, and their level of allegiance to the program. In other words, does the stakeholder prefer the program to succeed, to not succeed, or is he or she indifferent about the program?
Being able to determine the influential, or primary, stakeholders is critical to the program manager because he or she will not have time to engage with all program stakeholders. To effectively build relationships with the right stakeholders, the program manager must flush out who the primary stakeholders are, understand what level and type of influence they have, and determine how they feel about the program. A stakeholder analysis tool such as the one shown in Figure 7.1 can be very useful.
Figure 7.1 Example of stakeholder analysis tool.
Now, let's be honest. Widely sharing the information shown in Figure 7.1 may be a career-limiting move. Detailed stakeholder analysis information should be considered confidential and tightly controlled by the program manager. Why do we say this? Because true and honest stakeholder analysis brings to the surface the realities of corporate politics and unique biases that have to be managed properly; usually that means actively, but delicately.
Many program managers have told us that they do the analysis in their head, which is good. However, when they hold the information in their heads, it tends not to be used consistently or correctly, which is to sort the primary stakeholders from the remainder of the stakeholders and to develop a concise stakeholder strategy. Performing the additional step of documenting the stakeholder analysis information, either physically or electronically, helps to maintain history and clarity in developing the stakeholder strategy.
The Stakeholder Strategy
Stakeholder analysis is about sense-making. This means understanding the significance of the information gained about the various program stakeholders. Significance of the information is then used to develop a strategy for engaging and managing the right set of stakeholders. The right stakeholders are those who have power and influence to affect the outcome of the program.
Most of the literature on stakeholder management immediately classifies the primary stakeholders as those with both high power and strong allegiance to the program. This is significantly inaccurate because it leaves out the most potentially dangerous stakeholders: those with high power and negative allegiance to the program. These people also need to be considered primary stakeholders. Figure 7.2 helps to illustrate why. Stakeholders with high power and negative allegiance fall in the category of significant engagement required.
Figure 7.2 The power/allegiance grid.
If a program manager uses the power/allegiance grid to map their stakeholders, a core stakeholder strategy will begin to emerge. The strategy should consist of a communication and action plan for each of the primary stakeholders. It should also keep the program advocates engaged, describe how they can be used to influence others, and plan how to win over or neutralize the stakeholders who are not current advocates.
The stakeholder strategy should consider the following aspects:
- What is wanted or needed from each stakeholder?
- What is the message that needs to be delivered to each stakeholder?
- What is the best method and frequency of communication with each stakeholder?
- Does the strategy reflect the interests and concerns of each stakeholder?
The stakeholder strategy is not a static exercise or event to be performed once on the program. Rather, it needs to be both continuous and iterative throughout the life of a program to accommodate changes in program stakeholders and changes in attitudes and needs of the stakeholders.
Stakeholder Engagement
The primary goal of stakeholder engagement activities is to establish stakeholder alignment to the strategic goals, intended business benefits, program objectives, and success criteria of a program. It involves putting action to the stakeholder strategy through the building of professional relationships to influence for program advocacy and to monitor stakeholder actions, words, and decisions. The program manager should maintain focus on the primary stakeholders to prevent the job of stakeholder engagement from being all-consuming at the detriment of other critical aspects of managing a program.
Stakeholder engagement work will test the courage of program managers who need to be brave and bold when faced with building relationships with stakeholders who are not a fan of the program, or may be professionally threatened by the outcome of the program. Do not follow the human tendency to avoid these stakeholders. Rather, seek them out and most importantly, listen to what they have to say. Only by listening can a program manager begin to find middle ground to use as a means to positively influence.
Use the stakeholder management techniques described above to increase your political acumen, and to become politically astute. This means understanding and being sensitive to the concerns, interests, and personal agendas of the powerful stakeholders, and using the information learned from them to counter the effects of political maneuvering on your program.
Risk Management
For many companies, establishing industry leadership means assuming a higher level of risk due to the uncertainties associated with navigating unchartered territories. Developing new capabilities in today's environment is risky business by nature, especially if a company wants to establish or maintain a leadership position. However, risk taking does not mean taking chances. It involves understanding the risk/reward ratio, then managing the risks associated with a program.8
By understanding and containing the uncertainties on a program, the program manager is able to manage in a proactive manner. Without good risk management practices, the program manager will be forced into crisis management activities as problem after problem presents itself, forcing the program manager to constantly react to the problem of the day (or hour). Risk management is a preventive practice that allows the program manager to identify potential problems before they occur and put corrective action in place to avoid or lessen the impact of the risk. Ultimately, this behavior allows the program team to accelerate through the program cycle at a much faster pace.
Understanding the level of risk associated with a program is crucial to the program manager for several reasons. First, by knowing the level of risk associated with a program, a program manager will have an understanding of the amount of schedule and budget reserve needed to protect the program from uncertainty. Second, risk management is a focusing mechanism for the program manager. It provides guidance as to where critical program resources are needed—the highest risk events require adequate resources to avoid or mitigate them. Finally, good risk management practices enable informed risk-based decision making. Having knowledge of the potential downside or risk of a particular decision, as well as the facts driving the decision, improves the decision process by allowing the program manager and team to weigh potential alternatives, or tradeoffs, to optimize the reward/risk ratio.
Program-Level Risk
Managing risk on a program involves many of the same tactics as managing risk on a project. The difference, however, begins with the need to view risk from an expanded perspective. At the project level, project managers on a program are concerned with risk events that will prevent successful execution of their project. Since program managers are responsible for the delivery of business benefits, risk management at the program level is concerned with the factors that may prevent full realization of those business benefits.
Figure 7.3 illustrates the two dimensions of risk management that need to be performed on a program.
Figure 7.3 Project and program risk.
The figure shows a small program consisting of three projects. As an example, the program could consist of a software project, a hardware project, and a manufacturing project. Each of the project managers are responsible for identifying, analyzing, tracking, and responding to all risks that may prevent his or her project team from delivering their component of the solution on time, within budget, and with the features and quality levels specified. Each project, therefore, will have its own specific set of risks to manage based on specialty function(s).
The program manager needs to take a holistic perspective of risk, which includes risks from each of the projects as well as risk from outside of the project, such as risks associated with the business environment and organizational factors.
This does not mean, however, that all risks get elevated to the program level and become the responsibility of the program manager. The key is to filter the collective risks to delineate program-level risks from project-level risks, and then divide responsibility for managing the risks accordingly. This activity creates a risk management hierarchy that is present on programs and not normally found on projects (see Figure 7.4).
Figure 7.4 Program risk hierarchy.
The hierarchy of risk on a program consists of three levels: 1) project-specific risk, 2) an aggregation and collection of all project risks, and 3) program-level risks.
At the first level, each project team identifies the risk events specific to creating the outcomes and deliverables for their project. Each project team will have a registry of risks for which they are responsible for managing and for keeping up to date.
At the second level, the risk events for each of the projects on the program are collected in a joint-project risk repository. The joint-project risk repository is an amalgamation of all risks identified on the program. The IPT core team has the responsibility of keeping this risk registry current. As a word of caution to the program manager, know that the joint project risk inventory can potentially be very large and unmanageable. It should only serve two purposes: 1) to be the central database of risk events on a program, and 2) to distinguish risks that have both project and program-level impact.
The third level of the hierarchy, program-level risks, is a subset of the joint-project risk repository. During the assessment process for each of the project risks identified, the team must think beyond project-specific risk impact and carry it one step further to assess a risk event from a program perspective as well.
The Risk Management Process
The major steps involved in program risk management are similar in nature to the steps associated with project risk management. The primary difference is again in the mindset—all risks must be viewed from both a project and program perspective. Figure 7.5 depicts the primary steps of program risk management.
Figure 7.5 Program risk management process flow.
Risk Identification
The first step in the risk management process is to identify all of the events that could possibly affect the success of the program. Although risk identification is the first step in the risk management process, it is not a one-time event. Risk identification is an iterative process that occurs throughout the life of a program.
Risk identification is most effective when a bottom-up approach is applied. Specifically, each project team within the program should be responsible for identifying risks to the success of their project. Some program teams first begin by identifying the categories of risk, such as technology risk, market risk, business risk, and human risk, and then use brainstorming and other problem identifying techniques to identify all potential risk events within each category.
The key element of this step is to attempt to identify all potential risks. If risk identification is done well, it can be overwhelming, especially early in a program when the number of uncertainties is at the highest. Remember that the goal of risk identification is to flush out as many potential risks as possible to get them on the table for discussion.9
Project Risk Assessment
Not all risk events require action. The risk assessment step is needed to sift through all of the risk events identified in the previous step to identify those that pose the most serious threat to the success of each project. Scenario analysis is one of the most common methods for assessing risk events.10 Scenario analysis involves analyzing each risk event in terms of the outcome, weighing the severity of the impact of the outcome, evaluating the probability of risk events occurring, and understanding when the risk event may occur.
An effective technique to assess the impact of a risk event is to write an “if/then” statement. The “if” is the identified risk event, and the “then” is the impact of the event. For example: If the user interface designers are not assigned to the program by July 1, then the capability go-live date will be delayed two weeks. The impact is a delay in the go-live date, and the severity of the impact is two weeks.
When assessing project risk, the project manager is responsible for evaluating the impact of each risk event on the program as a whole. This responsibility lies with the project manager as he or she represents the project at the program level and possesses a more holistic view of the goals and activities for the program and business. The risk event in the example above has the potential for being a program-level risk since it affects the go-live date.
Program Risk Evaluation
Project risks that could affect the business benefits of the program or that could affect more than one project are better managed at the program level where higher perspective and authority will increase the quality of risk responses.
Each risk identified at the project level should be entered into the collective project risk registry for review and evaluation by the program core team. Each project manager will have performed an initial assessment of their project risks and should be prepared to make a recommendation on whether a risk is contained within his or her project, or should be considered a program-level risk.
Evaluating risk from a program perspective involves asking two key questions:
- Does the risk event have the potential to affect the business success factors of the program?
- Does the risk event affect more than one project on the program?
A “yes” answer to either of these questions identifies the risk event as a potential program-level risk, requiring it to be evaluated by the IPT core team.
If a risk event has the probability of impacting one or more of the program objectives, then it has the potential to affect the business results driving the program and must be managed at the program level.
Likewise, if a risk event affects multiple projects on a program, it must be elevated to the program level where the cross-project interdependencies are monitored and managed. The result is a prioritized list of program risks that the IPT core team can then manage.
We recommend that a program team begin with a qualitative approach to risk assessment, at least for the first iteration of analysis. By this we mean assessing whether the severity of impact and the probability of occurrence is high, medium, or low for each of the risks identified. This gross analysis will accomplish two important things. First, it will quickly prioritize the risks so the highest risks can be identified for immediate action. Second, it gives the program manager and team an understanding of the overall risk level of the program.
If additional analysis is needed, more quantitative methods of risk assessment can be utilized on the next iteration. For the more sophisticated programs of medium and large size, the Monte Carlo analysis technique for quantitative analysis can be applied.11 The important thing to consider, when engaged at this level of analysis, is to ensure that the value of the quantitative information gained is greater than the cost of obtaining the information. Make sure the results are worth the resources (time, personnel effort, and energy) invested.
Risk Response Planning
At this point in the process, the IPT core team has a relatively short list of program-level risks identified, assessed, and prioritized. The next step in the process is to decide which risk events need action plans. The most common risk response options available to a program team are risk acceptance, avoidance, mitigation, and transference.
Risk acceptance: This involves accepting the impact of a risk event when it occurs, but fully understanding the severity of the impact prior to its occurrence. Risk acceptance is not a common response option in low-risk tolerant companies and industries, but it is relatively common in high-risk tolerant companies and industries.
No risk mitigation or avoidance plans are needed for risk acceptance, and no changes to the program plan are required. However, a contingency plan is needed to identify alternative courses of action if the risk event occurs.
Risk avoidance: Risk avoidance involves changing the program plan to avoid the potential cause of an identified risk event, therefore removing the probability that the particular risk event will occur. For example, a program team may recommend removal of a particular new technology because the risk of the technology is too high and may adversely affect the program's success. Risk avoidance requires a risk-response plan, as well as appropriate changes to the overall program plan and relevant project plans.
Risk mitigation: There are two basic strategies for mitigating a risk event: 1) reducing the probability that the risk event will occur, and 2) reducing the impact that the risk event will have on the program if it occurs. Risk mitigation is a powerful technique because it targets the root cause of the risk event.12 It requires a risk-response plan and may also require changes to the program plan.
Risk transference: If a program team recognizes that it lacks the expertise or the ability to respond to a risk event internally, they may choose to transfer the risk response to another party. This, however, neither removes the risk from the program, nor does it remove the responsibility for the risk from the program manager. It simply transfers the response to the risk. Warranties and insurance are a form of risk transference, as is outsourcing of knowledge work.
Risk Tracking and Control
The last step in the risk management process involves monitoring the trigger events associated with the program risks, identifying new risks, and executing risk response plans or contingency plans when risk events occur. The program manager and the IPT core team need to track and control the program risks with the same diligence that they track and control the program schedule and finances. They also need to keep an open mind that new risk events will come to light throughout the duration of the program that will need to be assessed and potentially responded to.
Risk Management Practices
Risk management should not be viewed as a one-time event. It's not uncommon practice for a program team to present the risks associated with a program at each decision-checkpoint meeting, then set the information aside until the next decision. Practicing risk identification without practicing risk management is a fatal flaw. Risk management must be practiced consistently throughout the life of a program.
To ensure successful implementation of risk management practices on a program, a safe environment should be created for the team to discuss potential problems, an understanding should be established that risk management is not an exact science, the risk-tolerance levels of program stakeholders should be considered, and risk-based buffers to safeguard against the risks that cannot be resolved or anticipated should be utilized.
Don't Shoot the Messenger
For the risk management process to be effective, the program manager needs to establish an environment in which the team members feel comfortable raising potential problems and concerns. If the program environment is such that bad news and mistakes are punished rather than tolerated, team members will be reluctant to speak freely. This will choke the risk management process.
Risk Management Is Not an Exact Science
When we say risk management is not an exact science, we're referring to the fact that the program manager is always working with subjective risk information. After all, we're trying to predict what may happen in the future, not analyzing what did happen in the past. Therefore, two things come into play. First, it's not possible to identify and manage every risk. There will always be problems that have to be contended with (problems are risks that weren't identified or managed). Second, don't get lost in trying to quantify every risk. This can be contentious because many people have created quantification models and algorithms to help with managing risk. These models and algorithms are great tools for people in some industries, but in most industries there are so many potential risk events that a program manager could be consumed by risk modeling. For these program managers, learn to trust your experience and instincts.
Consider the Concept of Risk Tolerance
Risk tolerance is the level of risk an organization is willing to accept to achieve its business goals. Every organization and every individual within an organization has a different level of risk tolerance, with corporate culture and values being a primary influencer of acceptable tolerance levels. Figure 7.6 illustrates risk tolerance as a continuum, from complete risk avoidance on one end to complete disregard of the consequences of risk on the other.
Figure 7.6 The risk tolerance continuum.
For example, companies whose products involve human lives (automotive, aerospace, medical) have a low tolerance for risk due to customer requirements and product use conditions. For these companies, low risk tolerance means many risk avoidance steps are included in the program plan. In contrast, in some industries (application software, home electronics) risk taking is necessary to attain and maintain a competitive advantage. As a result, many risk events are accepted, program plans are aggressive, and schedule and budget contingencies are used to allow for some level of risk impact.
So, how does this affect the program manager? First, the program manager must understand the individual risk tolerance of primary stakeholders involved with the program, especially the sponsor, functional managers, project managers, and the governance board. Second, understanding tolerance levels provides excellent guidance for how much risk a program manager can assume, and what response actions (avoidance, acceptance, mitigation, or transference) are accepted as preferred options within the organization.
Unfortunately, there is no mathematical formula, no statistical calculation, and no model to help manage the various levels of risk tolerance the program manager will encounter—that's why we refer to this as the “art” of risk management. Experience, understanding the corporate culture, and developing personal interaction with the people on and surrounding the program are the best methods for learning to manage organizational risk tolerance.
Utilize Risk-Based Contingency Buffers
Because programs operate in a less than perfect world, savvy program managers use the information they gain from risk management practices to safeguard their programs against the suite of risks that will occur regardless of the best efforts to avoid them, and the suite of risks that simply were not able to be identified in a proactive manner. One of the most effective ways to safeguard a program is by applying contingency buffers to the program timeline and program budget.
Based upon the risk analysis step, the program manager can estimate the buffer amount he or she needs to include to increase the probability of program success. There are multiple ways to estimate the buffer amount. Three of the most common and effective approaches are: 1) utilize historical schedule and budget variance data from previous programs, 2) employ critical chain scheduling tools (schedule only),13 and 3) use simple statistical analysis techniques (see “Calculating Schedule Buffer”).
The job of the program manager is to determine the amount of risk the organization is willing to assume, calculate the amount of risk contingency needed, and then add it to the master program schedule and program budget. It is important to note that the management style and philosophy of the senior leaders for various companies all have different risk tolerance thresholds and therefore it is recommended that the program manager discuss risk tolerance and risk buffer strategies with their management to ensure agreement on the risk strategy for the program.
Financial Management
Since program management is part of the business engine of an organization, good financial management practices are a necessity for consistent success in managing an organization's programs. This involves setting clear financial targets, cost estimation and control, financial feasibility analysis, cash flow management, and budgetary management.
Develop Financial Estimates
The first step in financial management is to develop budgetary-level financial estimates as part of the definition and planning activities of a program. This may include program budget estimates for use in the program business case, return on investment estimates, financial break-even estimates, and estimated average selling prices or capability cost. This activity requires a strong partnership with a financial representative for the program who understands the intricacies of the financial department of the company. In fact, many firms ensure that a financial department representative is assigned to more business critical programs.
Determine Financial Feasibility
As part of the program business case, the program manager is responsible for a robust financial feasibility assessment. The feasibility assessment tests the viability of the program by evaluating the financial estimates developed in the previous step to determine if the program is a viable investment option for the business. This analysis should answer the following questions:
- How much will the program cost to implement?
- How much will this program contribute to the company bottom line?
- Is the program worth investing in?
Develop Project Budgets
Once the financial feasibility of a program is determined and approved, the next step is to engage in detailed cost estimation. The detailed cost estimation activities occur at the project level and are “rolled up” and managed at a summary level by the program manager. Each project manager uses traditional project-cost estimation techniques and information contained in his or her project work breakdown structure, detailed schedule, and staffing plan to estimate the resource costs for the project. In addition, any fixed costs such as equipment and subcontractor support should be included in each detailed project budget.
Integrate the Project Budgets
With the detailed project budgets complete, the program manager can integrate them into a program budget that represents the total investment in the program. Any costs outside of the project budgets, like the cost of the program manager's salary or subcontractor cost, are added to the program budget in this step. The program budget should include all variable costs, fixed costs, and overhead charges that the program will incur. The budget should encompass the cost to develop a capability and also the cost of program operations following the delivery of a capability.
Add Budget Reserve
Using the risk assessment data generated, the program manager can estimate the amount of budget reserve he or she needs to include to increase the probability of program financial success. By taking an average financial exposure—for the top ten risks, for example—the program manager can determine the amount of budget risk he or she needs to add. Another commonly used technique is to use a standard percentage of the overall budget; a good rule of thumb is 5 to 10 percent. Once estimated, the program manager should add the risk contingency to the budget to develop a high-probability program budget that he or she can put in front of senior management for negotiation and approval. It is recommended that the program manager discuss the use of this strategy and amount of the budget reserve with the program sponsor and senior leaders of the organization.
Negotiate Final Targets
In this step, the program manager negotiates the financial elements of the program with the senior sponsor or the customer. Financial targets such as the ROI, profit margin, manufacturing costs, and time-to-breakeven can all become negotiable items as long as they still comply with the business goals of a program. In addition, the program budget itself, especially the budget reserve, is commonly negotiated. It helps tremendously if the program manager comes to the negotiating table armed with the data supporting the financial elements of the program to focus the negotiation on the data, not the overall targets. At the end of the negotiation, program managers have a set of program financials that senior management will hold them accountable for achieving.
Manage and Control Program Finances
The program team now has the financial information needed to manage the remainder of the program. Managing program finances involves tracking actual progress against budget and comparing it to planned progress. This should be performed in a two-tiered approach. The project managers should manage the financial details within their projects, and the program manager should manage the finances at the summary level.
When a variance between planned versus actual financial performance is detected, or when issues and changes are encountered, the variance must be effectively controlled to ensure the financial viability of the program. The specific control techniques that are employed will depend upon the type of financial variance encountered. For example, if the bill of material cost for a product exceeds the targeted amount, the team can look for lower cost part substitutes or recommend removal of one or more features to eliminate material cost. Managed consumption of the budget reserve is also a viable option for managing budgetary variances.
The program manager also has to monitor and control the cash flow on the program, especially in smaller or cash constrained companies. Once a program enters the implementation phase, it can become a large financial drain on the company. Jeff Singleton, a former Boeing program manager, explained that on a program consisting of 100 people (large by some standards, low by others), his program expenditures exceeded $120,000 per day to pay for the work of his program team. That's $600,000 per week! Effective cash flow management is necessary for the program finances to remain solvent.
Financial Management Practices
To ensure successful implementation of the financial aspects of a program, special consideration should be paid to the financial competency of the program manager and utilizing an effective budget estimation process.
Financial Competency
As a business leader within a company, the program manager must possess strong financial competency (Chapter 11). In the role of the business manager proxy, the program manager assumes the financial responsibility of a program from the business manager. This means that he or she needs to have the financial acumen to carry out this responsibility. Short of getting a degree in finance, the program manager should look for education and training opportunities to bolster his or her ability to understand, manage, and speak to the financial aspects of managing a program.
Budgeting Methods
We have witnessed multiple methods used to develop detailed budget estimates, most of which have been successful. The most common are bottom-up estimation, top-down estimation, and iterative estimation. Any of the three will work, as long as both the program manager and his or her senior management can come to an agreement on the financial targets. From the program manager's perspective, it is our experience that the iterative approach to budget estimation yields the best opportunity for deriving a budget that has the maximum buy-in from both the program and senior management teams.
Change Management
Rest assured, change will occur on a program. This is primarily due to the fact that programs exist within dynamic and ambiguous environments—the very reason why program management is a preferred management approach for these environments.
Effective program change management practices begin with a fundamental change in mindset. Most humans, even those populating a program team, are not fond of change, especially if it affects them personally. As a result, they tend to resist change.15 However, if change is a near certainty for a program, this resistance to change must be dealt with through establishment of a pro-change mindset by viewing change as an opportunity to improve. The program manager must be the advocate for controlled changed on a program.
This underscores the basic difference between change management practices for projects versus programs. On projects, change is viewed as a deviation from the project baseline that needs to be corrected in order to realign to the existing baseline. On programs, change is viewed as a result of something learned and therefore an opportunity to improve the business benefits delivered. Thus, an opportunity exists to establish an improved program baseline. This change in mindset is necessary due to the uncertainty that normally surrounds a program.
Change management practices allow for uncertainly and ambiguity in the program environment, while at the same time keeping change bounded by the established business success criteria. Program change management is about enabling change within a predefined, desired business end state.
Change Management Elements
For consistency in practice, it is important to have a documented change management process. The process is normally part of the program-level governance system and does not have to be complicated to be effective. In fact, effort should be expended to simplify the process as much as possible.
Figure 7.7 illustrates an example of a change management process that is used by a major automobile manufacturer. This can be used as a starting point for developing a customized version for any organization.
Figure 7.7 Change management process.
Submitting Change Proposals
The first step in the change management process is for the person requesting the change to submit a written change request proposal. This proposal should include a detailed description of the change requested, a justification for the change, and the benefits to the program for implementation of the change.
The justification and benefits are critical pieces of information that the program manager should require for any change request. Cursory statements such as “the customer has requested the change” provide good reason to consider a change, but are not good enough to approve change. The change request proposal should present a compelling argument for the program team to change its current course of action.
Assessing a Change Proposal
Change assessment involves evaluation of why the change is necessary, if it is in alignment with the business success factors, and what it will cost and require for implementation. The assessment culminates in a change benefits/cost/impact analysis.
Change proposal assessment takes resource time and effort away from members of the program team that would ordinarily be spent developing their project deliverables. By filtering poorly justified or non-value-added changes, the change review board prevents wasted effort on the part of program resources.
Once the change is assessed by the appropriate members of the program team, the change benefits and costs in the form of schedule, budget, and resource impact are submitted to the change decision body of the program.
The Change Decision
With the benefit/cost/impact assessment completed, a decision is needed to approve, disapprove, or send the change proposal back for further evaluation. The level of impact of the change will require the decision to be made at varying levels of the program. Tactical, project-specific changes can be decided upon at the project level; changes that don't affect the business success criteria and can be implemented by the use of schedule and budget reserves can be decided upon at the program level; and changes that affect the business success criteria have to be elevated to the appropriate senior manager.
Implementing a Change
If approved, the change proposal can potentially change the definition, plan, and implementation strategies of the program. For the change to be appropriately disseminated across the program, it has to be included in the program documentation. The impact of the change also has to be fully comprehended in an update to the program plan and respective project plans. This includes new or modified deliverables and tasks, changes to the timeline and schedule, and possibly changes to the program budget.
Communicating a Change
The last step in the change management process is to broadly communicate the change and the impact of the change to all affected and interested program stakeholders. Communication should include the change description, impact to the program, and the benefit of implementing the change. This follows our philosophy of no surprises to management (and customers).
Change Management Practices
Change management should begin on a program as soon as the requirements are identified. This can be as early as the program definition if it makes sense to manage the high-level requirements driving the concept and business-case development efforts. However, change management processes and protocols must be in place once the detailed requirements begin to be documented. If the requirements continue to change without being adequately managed and documented, the outcomes from program execution will not accurately reflect the program requirements. This situation results in the need for reconciliation between the requirements and work outcomes later in the program, when it is much more costly and painful. It is better to begin managing the changes to the program requirements before the program plan is fully developed, communicated, and committed.
During program execution, changes have to be tightly managed. Even the smallest changes can have significant impact due to the potential high cost of rework and risk of performance errors once the output of a program is operational.
Change Management Hierarchy
Best practice organizations often implement a change management hierarchy for their programs. At the lower level, change is managed within each of the projects, and is focused on tactical changes specific to the particular project discipline. A change review board is typically used and consists of a subset of the project team leaders and is led by the project manager. To be effective, the program manager must empower the project managers to make the appropriate change decisions.
At the higher level, cross-project and business specific change is managed by the program manager and a subset of the IPT core team.
Change Management Protocols
Change management protocols define how changes are to be addressed once the program is underway and should be clearly communicated by the program manager.16 The purpose of protocols is to ensure the change management process functions as efficiently as possible. The easy part of establishing an effective change management process on a program is defining the process; the hard part is changing the behavior of the people expected to follow the process. Change management protocols are meant to help with the behavioral challenges that will be encountered.
Example protocols include the following:
- All proposed changes must be made in writing and include justification for the change and benefit to the program and business.
- The change management process must not be sidestepped by escalation to a senior manager.
- All change decision members are required to attend all change management meetings or send an empowered delegate.
- Any change impacting the business success factors must be elevated to a designated senior manager for approval.
Fast-Track Change Requests
To ensure successful implementation of a change management process on a program, special consideration should be given to establishing a fast-track process for time-sensitive decisions. In a fast-track process, all change requests must be reviewed and evaluated in the shortest time possible to prevent unneeded overhead burden on the program. This is normally instituted through an email system that requires a minimal set of decision makers and limited time to review, analyze, and recommend a change decision. For any fast-track change approval practice to remain effective, it needs to be maintained as the exception, rather than the norm.
Program-Level Governance
Program-level governance is a subset of organizational governance, and is performed within the context of the overall organization.17 At the highest level, a firm's board of directors governs an organization's strategic direction and investment decisions. The senior executive team governs the direction of various business and operational units within the firm. The program governance board provides oversight of the various programs in flight within the organization, and the program manager establishes the program-level governance for a specific program.
The program and project management standards bodies have provided a variety of governance models. In practice, we have found that the models seldom provide a perfect solution for an organization. The reality is that an organization must first understand where it sits with respect to program management maturity, and then tailor a governance system based upon their needs. To demonstrate, we use the program management continuum first introduced in Chapter 1, and modified as illustrated in Figure 7.8.
Figure 7.8 Program-level governance continuum.
If an organization is on the far left of the continuum, or administration-focused, it is likely that no formalized program governance model exists, or is needed. For organizations that operate in the middle of the continuum, it is common to see a traditional controlling approach to program-level governance. This is because a single-project approach with traditional project management methods remains the primary philosophy and influence. The collection, analysis, and reporting of project performance data, with the intent to measure conformance, is the primary approach.
For program-oriented organizations, those operating on the right side of the continuum, an integrated approach to program-level governance is necessary.18 The integrated approach recognizes the collaborative relationship between the project teams, the program team, and the business team of an enterprise.
An integrated approach to program-level governance incorporates many elements, but is primarily centered on three factors: 1) setting and maintaining strategic alignment, 2) reviewing progress, and 3) making decisions that affect program strategy.
Setting and Maintaining Strategic Intent
Program-level governance begins with ensuring that a program and its constituent projects are aligned to the strategic goals of an organization. In the early stages of a program (program definition and investment), appropriate due diligence should be applied to create alignment between the strategic goals driving the need for a program, the business results the program will deliver, and the program objectives. Program-level governance then ensures that there is alignment between the outcomes and deliverables for each of the projects to the program objectives. We detail the process of benefits translation and alignment in Chapters 3 and 6 respectively.
Setting strategic alignment is a critical first step. Maintaining alignment as a program progresses through work cycles and time is equally important and continual focus and priority on the part of the program manager and the IPT core team is necessary.
To maintain alignment from strategic business goals to project outcomes throughout the life of a program, a system of measures, metrics, and data collection needs to be established and implemented by the program manager (Chapter 8). This system then has to be incorporated into the program work cycle and continually used to ensure alignment is maintained and adjusted if and when it becomes necessary.
Reviewing Program Progress
A program manager spends a lot of his or her time communicating 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 with senior management and other key stakeholders. Regardless of whether the status is formal or informal in nature, the message should remain consistent.
Consistent communication of program progress is a critical element of cross-project collaboration. 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 to a program.
So, how does the program manager 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 other integrated core team members.
IPT Project Reviews
The IPT core team should review detailed status for each of the projects on a regular basis. For most programs, the primary agenda for each core team meeting is project status. Reporting project status facilitates the flow of information within the program and importantly, intentionally creates a means for conversation about expectations and integration points among the project teams.
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 document that shows pertinent project status (Chapter 9).
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 program status is reviewed by the program governance board or the executive sponsor. Each program manager is required to present the status for the program he or she manages. Even though the program review is primarily a status meeting, it can also be used as a decision-making forum for factors that affect the program objectives.
For consistency in reporting format and message, it is most effective to have an established program indicator for use by all program managers. Much like the project indicator, the program status indicator is a one- or two-page summary brief that shows pertinent program status (Chapter 9). Much of the information contained in the indicator is derived from the most recent project indicators and presented in summary format.
In addition to the program status indicators, the program strike zone and program dashboard tools are normally used in the program review to communicate status toward achievement of the program success factors and the business goals (Chapter 9). The objective for 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 if needed.
Keep in mind that the program review serves dual purposes. It provides the data and information necessary to ensure that a program and its constituent projects are progressing as anticipated, and it provides the data and information necessary to enable the senior executive or program governance body to make good decisions with respect to business value and strategic direction.
Making Effective Decisions
Due to the complexity of most programs, program teams need to draw upon a wide array of information to make effective decisions. This means all disciplines and projects must be involved in generating information for and participate in the decision-making process. Because of the cross-discipline and cross-project nature of programs, information must be presented in a manner that all parties can understand and be able to use in the decision process. It is no longer the case that engineering utilizes technology-only data, or marketing utilizes customer-only data, or finance utilizes accounting-only data to drive program-related decisions. Discipline-specific data and information must be combined with cross-discipline information for program-level decisions.
An effective program decision is described as one that has the following characteristics:
- Not reached by a single individual
- Based upon input provided by each team member involved in the decision process
- A sound solution to the problem
- Aligned with the program objectives and business success criteria
Program teams are charged with making three types of decisions: 1) strategic decisions, 2) tactical decisions, and 3) operational decisions. Strategic decisions may include such things as which technologies to include in a design, what product cost is needed to maintain competitive leadership, and what key partnerships or alliances in which to engage. Tactical program decisions may include which features to incorporate, how many prototypes to build, and how to manage changes to the program schedule. Operational program decisions may include how to coordinate factory scheduling, which common cross-project processes and tools to employ, and how to communicate progress to program stakeholders.
Effective program decisions require well-coordinated and communicated interplay between the project teams and empowerment on the part of organization's management team to make the strategic, tactical, and operational decisions necessary. By empowering the program team to make decisions, decision making becomes quicker and more effective. If a program team is required to rely on functional or line managers for decisions, these managers will quickly become a bottleneck in the program's implementation, thus, reducing efficiency and effectiveness.19 Program team empowerment means giving the program manager and his or her project managers the responsibility and authority to make decisions. In the book The Power of Product Platforms, Marc Meyer and Alvin Lehnerd state, “There is no organizational sin more demoralizing to teams than lack of empowerment.”20 The program team must have confidence that their empowerment will not be undercut by the firm's management. If such action occurs, it must be immediately eradicated by the firm's senior management (see “The Battle of Powerville”).
Just as the program manager must be empowered by senior management, the program team must also be empowered by the program manager to make key decisions. As Rich Nardizzi, a senior program manager from a major aerospace company told us, “Empowerment is something that builds over time through gaining the confidence of the leader.” He also pointed out that there needs to be empowerment boundaries because, as he put it, “One big screw-up on the part of someone wipes out ten attaboys.”