Organizational transformation is always a challenging endeavor and transitioning to a program management-based organization to developing products, services, or infrastructure capabilities is no different. Implementation of the program management model will change the culture and politics of the organization because it affects all levels of management. Additionally, it changes the rules of engagement, the decision-making hierarchy, roles and responsibilities, core competencies required of some functions, and the political landscape of the organization.
Our experiences in leading organizations through this transformation have revealed several key factors that come in to play and must be appropriately managed. These factors include the following:
There must be a compelling reason to change.
Senior management must drive the transformation and have a clear vision and end state in mind.
Changes to the organizational structure may be required, which may change the culture of the organization.
People need to understand their new roles and responsibilities and the new power equation.
New core competencies may be required within the organization.
Behavior change on the part of individuals affected has to be modeled, monitored, and managed.
This chapter will focus on the management of these factors through a disciplined three-step transition. First, we will address understanding the transition. Some of the drivers that motivate companies to change the way they develop and deliver their products, services, and infrastructure capabilities. During this process, we will characterize the continuum between projects and programs and identify the key factors that determine when projects should be redefined and restructured as programs. Next, we look at the critical elements that constitute a firm foundation from which a strong and sustainable program management model can be built, and, then, present a detailed stage-by-stage transition using the SECURE process. This chapter, therefore, will help senior managers attain the following objectives:
Understand the factors that indicate a need for transition to program management
Explain the major steps for implementing program management in an organization
Describe the fundamental elements that must be in place to sustain the program management model
Present the case for doing a cultural risk analysis and political plan
Understand common challenges to expect and suggested methods for resolving them
There are three major steps in transitioning to program management, each including several substeps (see Figure 14.1):
Understand the transition
Execute the transition
Continuously improve
Understanding the transition to program management tells us in broad terms what factors push for the transition, and whether there's a compelling case to transition or not. If the case is good, it drives the next step—execution of the transition process. The deployment of program management practices on real-world programs will reveal its glitches and generate new learning, resulting in a need for continuous improvement—the third step. Details about each step follows.
The goal of the transition is to achieve a fully functioning program management discipline with as little organizational pain as possible. To achieve the goal, you need to fully understand the whole game, the associated risks, and roadblocks surrounding the transitioning. This can be achieved by performing the following steps:
Understand the need for change
Understand that it is mostly revolution, not evolution
Understand business factors driving change
Understand operational factors driving change
Decide whether or not you need to transition
How development efforts are managed within a company is the result of the firm's management philosophy and the business model they practice. Many companies have found that the traditional project management approach is sufficient to meet their development needs and are quite satisfied with the results. Other companies have either chosen, or are seeking, a more strategic approach to optimize their business results. When a firm decides to undertake a major organizational transition, such as moving from a functional to a program management-based organization, there are many key factors that must be considered. We will look at these factors in detail later in this chapter, but let us first explore why companies make major organizational changes.
Many companies over their life span face times of severe difficulty in meeting the performance expectations of their shareholders and other stakeholders. These performance problems are many times the result of a major upheaval or shift in the business environment within which the firm operates—such as a shift in the primary markets, competitor actions, or macro- and micro-economic change. These changes usually result in some form of adverse or negative impact to the firm's ability to maintain market share, generate sales, sustain profits, and experience growth in earnings. These adverse conditions result in actions on the part of a senior management team to search for opportunities to remedy the performance problems and make necessary changes to get the enterprise back on track to deliver planned and expected results.
This then becomes the crux of the discussion for whether a company needs to consider moving to a program management-based organization. If a disconnect exists between the company's ability to convert business strategy to work output, or if they have identified that they lack an integrated systems approach for developing and delivering their new products, services, or infrastructure capabilities, then it may be the appropriate time for senior management to consider transitioning to a program management-based organization.
To obtain the broad-based benefits of applying program management to the business model of the firm, several fundamental changes may be required. Our experience has been that the probability that a firm can successfully convert a functional or project-based organization to a program management model by evolving into the model over time is low. In other words, can the firm increase the responsibility of the project manager and the capability of the project team to deliver upon the strategic and business objectives by providing training for these individuals over time? Our belief is that the answer is no and this is not likely to happen. The successful transition to a program management-based organization is unfortunately not evolutionary but mostly revolutionary in nature.
The senior management team of the firm must consciously decide that they will make the fundamental structural and cultural changes necessary to move the organization to the program management model and then lead the organization through successful implementation of the changes. There are a number of key factors that typically drive a senior management team to decide if they are ready to implement the program management model. The key factors are broken down into two major categories of business factors and operational factors.
Firms that have their development efforts either functionally aligned or operationally and tactically focused are most likely missing the opportunity to leverage their efforts directly toward the core business objectives of the firm. This direct link between work output and business objectives provides the potential to drive improved business results. There are a number of business factors that senior management should assess to determine if this opportunity for improved business results exists in their firm. These include the degree of linkage between development output and strategic objectives, the need for time-to-money improvement, and the level of business expertise needed, as follows:
Degree of linkage between execution output and strategic objectives: This factor involves the degree of linkage between the deliverables and final output of a product, service, or infrastructure development effort to a specific set of strategic business objectives of the firm. If the current link is low or nonexistent, then consideration of transitioning to the program management model is an opportunity for the firm to pursue (see Figure 14.2). As we state throughout this book, a primary advantage of the program management model is the ability to directly close the gap between the firm's strategic objectives and the successful execution of plans and actions to achieve those objectives.
The need for time-to-money improvement: The level of importance the firm places on the need for time to money improvements is the second factor for senior management to assess. It is a well-known fact that in today's highly competitive world, time to money is a critical factor in gaining an advantage over one's competitors. Gaining time to money advantage means decreasing the development cycle time, and many companies have achieved some gains through the concurrent development approach. However, greater improvements in time to money may be deemed necessary by senior management. Best-in-class companies accomplish greater time to money gains through an integrated development approach driven by a program manager, as described in Chapter 4. In the integrated approach, the functional teams work shoulder to shoulder through the PLC, from conception to end of life. Achieving time to money advantage requires tight management of the cross-discipline interfaces, shared risks, and open communication channels between the interdependent project teams. This requires strong leadership from a program manager to orchestrate, coordinate, and direct the work of various cross-discipline project teams.
Level of business expertise needed: The degree of general management and business expertise required of the team leader to successfully manage the product, service, or infrastructure development deliverables is another business factor to consider. A direct indicator as to whether the firm's management is using their development teams to drive strategic business objectives is the degree of knowledge, training, and skills required of their team leaders. For complex, multi-discipline development efforts, the team leader must be able to fulfill the role of the generalist who coordinates the efforts of the functional specialists toward achievement of a set of business results (see Figure 14.3). The program manager is a generalist who manages the overall program, and must possess the knowledge and capability based on broad-based cross-discipline experience and understanding to be successful in this role.
A continuum may be the best way of visualizing and characterizing the distinction between project and program management-based organizations, with complexity and degree of cross-discipline interdependency being the distinguishing factors along the continuum (see Figure 14.4). The further a development effort moves toward increased complexity and cross-discipline interdependency, the greater the need for a program management approach for managing the development effort. Those who have been involved in more complex efforts appreciate that the challenges facing the leaders and members of these teams surpass the typical or traditional project team requirements. There is a point in which the increased complexity of a project makes it ineffective to manage as a single entity. At that point, the best option is to break the project into multiple interdependent projects that deliver one or more elements of the total solution and reorganize the development effort into a program.
Complexity: To better understand complexity as a determinant for transitioning to a program management-based organization, we need to review what we mean by complexity (also see details about this topic in Chapter 4). Complexity manifests itself in several areas as follows: product, service, or infrastructure designs have become more complex as features and integrated capabilities increase; the process to develop and manufacture the solutions has become more complex; the ability to integrate technology and end-user needs has become a very complex undertaking; and the current global, multinational approach to development, where teams are geographically dispersed across multiple sites and time zones, has added yet another level of complexity to the problem. Thus, complexity of a development effort occurs from elements related to technical, structural, and business complexity factors.
Technical complexity is driven by a number of factors. It may be directly related to the technical aspects of the product, service, or infrastructure under development, or from the knowledge and capability of the existing resources of the firm to successfully address the technical complexities. Examples of variation in technical complexity are illustrated in Table 14.1.
Structural-complexity factors are those that involve the organizational elements of the development effort. Like technical complexity, structural complexity may also be exacerbated by the lack of skills, knowledge, or capability of the firm's existing personnel to address or have experience in addressing structural complexities. Examples of variation in structural complexity are shown in Table 14.2.
Business-complexity factors are those that involve the external business environment in which the firm operates. Examples of variation in business complexity are listed in Table 14.3.
Complexity factors will vary for each company, but the primary point that is being made is that greater technical, structural, and business complexity drives a greater need for transition to a program management-based structure.
Cross-discipline interdependency: The size and number of cross-discipline groups involved in a development effort is also a consideration in the decision to transition to a program management-based organization. Cross-discipline interdependency is directly related to the complexity and scope of the development effort.
Table 14.1. Examples of Technical Complexity
Technical Complexity | |
|---|---|
Low complexity | High complexity |
|
|
Table 14.2. Examples of structural complexity
Structural Complexity | |
|---|---|
Low complexity | High complexity |
|
|
Table 14.3. Examples of business complexity
Business Complexity | |
|---|---|
Low complexity | High complexity |
|
|
For example, a small development effort addressing a software feature enhancement to an existing product in the marketplace may require only three cross-discipline teams to implement. Conversely, a requirement to develop a product with new hardware and software architectures, along with a platform design utilizing a new user interface and electro-mechanical package, may require a large team with ten or more disciplines involved.
Figure 14.5 shows just how explosive the growth in the number of interdependencies can be as more cross-discipline elements of a solution are required. By looking at the chart, we can see that the small software feature enhancement project requires three cross-discipline teams to implement; the technical complexity is low and the potential number of interdependencies between disciplines is less than ten. By contrast, on a new product development project that requires ten cross-discipline teams, the potential number of interdependencies between disciples increases to nearly 100! This requires a strong development model that facilitates the required horizontal cross-discipline collaboration between teams.
So then, one might ask, When a project becomes large enough in scope, should it just be considered a program? The answer is no. It is not a matter of size or scope alone. Rather, there comes a point in which interdependencies between functional teams become large enough in number that the best option is to reorganize the development effort into a program consisting of multiple interdependent projects. The focus of the program then shifts from development of technical discipline-specific solutions to development of a cross-disciple solution provided by the interdependent relationship between functional project teams. The horizontal nature of this cross-discipline solution is a key indicator that an organization needs to move to a program management-based organization to become more effective and efficient in its product, service, or infrastructure development efforts.
Skilled personnel: The availability of trained and experienced personnel in the firm that are capable of fulfilling the role required is the next factor for senior management to consider. If management is convinced that the program management model is the right model to pursue, then, before they proceed, they need to assess the current availability of skilled talent within the organization. Candidates with the requisite skills can be derived in the following ways:
Hire qualified candidates from the external marketplace
Grow the talent internally through training and development
An appropriate combination of external and internal acquisition of talent
Hiring qualified candidates externally is by far the quickest approach for obtaining the much needed talent and capability. Program management is not a new discipline and experienced and qualified program managers exist in many industries today. A focused search for external talent should be fruitful. There is, of course, the traditional risk all firms face in hiring externally—properly assessing a candidate's skills for the role and his or her ability to successfully meld into the firm's culture.
Growing program management talent internally has the advantage of utilizing known company personnel for this new role. Internal candidates may lack the total breadth of skills necessary to perform the program management role (see Chapter 13), but they may have the talent and potential to grow into the role. Management can pick high achievers that have demonstrated they are leaders in the firm and are well respected by their peers and team members. This may contribute to more rapid team building than by hiring a program manager externally. The key disadvantage to this approach is that it may take considerable time and cost to achieve the necessary skill level and experience for the internally grown candidates.
In our experience, the third approach, a combination of external hiring and internal development offers the best opportunity for successful long-term growth of the program management capability within an organization. This approach provides an appropriate percentage of the total resource acquired externally, while also growing the firm's current talent pool with the remainder of the positions needed. The externally hired resources can initially help institute the new model and provide mentoring and assistance to those internally attempting to learn the new role. Additionally, this adds motivation to the internal candidates, as it encourages a "promote from within" philosophy with the existing staff. Melding the two sources of program management candidates enables the chance for a more balanced model that fits the culture of the firm.
Now that we understand some important factors involved in the transition decision, we can essentially consider the following two options: stay with a functionally oriented, project approach or transition to a program management-based model. Each fits one situation better than another. To decide whether to transition or not, we devised a simple tool in Table 14.4
Table 14.4. Decision table for transitioning to program management
Factor | Project Management | Program Management |
|---|---|---|
Understand business factors driving change | ||
Degree of linkage between execution output and strategic objectives | Loosely Connected | Tightly Connected |
The need for time-to-money improvement | Lower | Higher |
Level of business expertise | Specialist | Generalist |
Understand operational factors driving change | ||
Technical complexity | Lower | Higher |
Structural complexity | Lower | Higher |
Business complexity | Lower | Higher |
Cross-discipline dependency | Lower | Higher |
In Table 14.4 we listed which of the two approaches may be a better fit in each of the seven factors. (We also assessed and explained earlier how and why the factors favor each of the two approaches.) For example, for factor one in the table, we assessed and explained that if the degree of linkages between execution output and strategic objectives is required to be tightly connected, a company should favor program management. And, so goes assessment for the remaining six factors.
Table 14.4 can be used as a guide in the decision to transition to a program management-based approach. First, tailor the factors for your case. Determine if each factor favors project or program management by placing an X beside your choice. Repeat the process as needed.
If the majority of X's are on the project management side, stay your current course and do not transition. If the majority of X's end up on the side of program management, you have the case to transition. A word of caution may be of help here. This is a simple but practical tool to make your transition decision. Like any other tool, it is only as good as the information contained in it. Therefore, prepare excellent quality information for your case and assess the factors professionally.
Before transitioning to the program management model, a firm foundation has to be established from which to build upon. This foundation consists of a strategically focused management philosophy and strong senior management sponsorship.
Senior management's philosophy as to whether they choose to view development efforts strategically and linked to the success of the business, or rather to view the efforts as tactical and operational in nature, is critically important for a successful transition to a program management-based organization. For a program manager and his or her program team to perform at their highest potential, senior management of the firm must make it apparent that they believe the team's efforts are directly tied to the success of the core business and are integral to the strategic success of the enterprise. With this view in place, it elevates the importance and resulting influence of the program managers within the firm and enables them to coalesce action to get things done throughout the enterprise.
Additionally, senior management should position program management as a core business function within the organization. Too often, program managers are embedded in other functions within an organization, such as engineering or marketing. This is counterproductive because program managers are generalists who are effective in managing across functional lines. By embedding them within one specific function, an inherent functional bias is established based upon the direct reporting relationship between the program manager and his or her functional manager. Senior management must be careful to preserve the functional neutrality of the program management function. Firms that view program management as a true functional discipline that is equal in influence to the other functions of the organization experience increased program management talent and capability; ensure the long-term viability of the discipline; and, potentially, develop future GMs and business leaders for the enterprise.
Firms that have been most successful in implementation of the program management model have had strong sponsorship from the senior management team of the organization. Implementation of the model works best when it is managed from a top-down approach, rather than a bottom-up approach. When senior management buys into the approach and drives the implementation, the rest of the organization begins to fall in line. It is difficult to derive the necessary and significant changes in an organization when it is attempted through middle management, as barriers across the functional organizations quite often become too difficult to overcome.
One senior executive told us how his first attempt at implementing program management within an organization was a complete failure. As he told us, "The transition failed because it didn't have executive support, and, worse yet, the executives weren't even open to learning about the value of program management." This was an organization that was too hard to move without top management supporting and driving the transition and necessary change in culture. According to the senior executive, their philosophy was "if a person was not a technologist, he or she wouldn't be able to lead a development team." The problem with this philosophy is that technologists get rewarded for developing technologies, and product development managers get rewarded for integrating system technologies into successful products—an obvious mismatch of skills and responsibilities within this organization.
The senior sponsor must be an influential change agent. This means someone with sufficient power and influence in the organization who can ensure that the organizational structure, behavior, and culture move in a new direction. The change agent must have a clear vision of what the change is and why is it important for the success of the organization. This value proposition should be sufficient for the senior executive to champion the change.
Once a strong program management foundation is established, transition to a program management-based organization can begin. Many day-to-day tasks have to be managed during the transition, but several structural and cultural elements are worthy of focus for a successful transition. To illustrate this, we chose to demonstrate the transitioning through the SECURE process (Figure 14.6). Other processes can be used just as effectively, provided that they are comprehensive and systematic.
One important point must be made. It is highly recommended that a qualified organizational development expert within the business or an experienced consultant be hired to lead the transition process and team. They have the requisite skills to scale the barriers that will be encountered, and they represent a neutral position within the company.
To proclaim that the old way is dead and shift overnight to the new way of program management, may lead to chaos in an organization. Therefore, major changes call for planning. To create a program management-based organization, a good road map is needed. The SECURE process is such a road map. It guides the transition from the current business model to the program management model by a stage-by-stage process. We shall describe each stage in short, and then we will delve into the details.
In stage 1 (scope), a situation analysis is conducted to clarify why the transition to program management is needed and explain it in a business case. Next, a scope statement is developed detailing the "wills" and "won'ts" of the transition. Finally, the team vision, values, and objectives for program management are established. Stage 2 (engineer) includes developing a program management design or blueprint that shows all details regarding changes in structure, systems, and culture that are needed to build a program management function. In stage 3 (confirm), a pilot test of the program management model is conducted. The purpose is to see if the program management design performs as expected in a contained environment. In small-scale transitions this stage is sometimes skipped.
During stage 4 (ultraplan), a realistic action plan for implementing the program management design is developed. The reason we called it "ultraplan," rather than "plan" is simple—organizational transition requires planning to an extreme degree. Part of planning is the development of a political plan and cultural analysis. Stage 5 (realize) focuses on implementing the program management design to turn the design into reality. This is the most difficult stage when the real changes happen and people respond, resist, or fight back. In stage six (enhance), the transition project team activities come to a close and focus shifts to continuous improvement, in which the emphasis is on line organizations continuing to improve the new program management environment.
If you think thoroughly about the program management transition you want to undertake, it will significantly increase your chances for success. Think through every step of the changeover to program management. But first, justify the need for program management and determine what it will include. The scope stage has six steps:
Form initial team
Understand the issues and opportunities
Develop a cost/benefit analysis
Develop the scope statement
Define objectives and expectations
Develop a game plan
First, form an initial team to pursue the transition implementation plan. The transition effort is most effective when it is managed as a project in and of itself and is properly planned and executed. In doing so, a formal implementation team can be established to develop and execute the whole SECURE process. As mentioned earlier, the team should be led by a qualified organizational development expert or experienced consultant who is in charge of forming the transition team.
The transition team will work to understand the issues and opportunities, involve knowledgeable personnel to conduct the gap analysis between the current situation and where the firm wants to eventually be, and identify the problems and make recommendations for improvement. For this, it is best to conduct a situation analysis, observe the work flows, identify the problems, and perform root-cause analysis. Don't forget to analyze customer relations, market conditions, and organizational culture. This is a basis for the subsequent steps.
What is the business case for implementing the program management model? What does your cost/benefit analysis say? Your case will demonstrate what would be the benefits of having program management and the costs of sticking with the old way. If the case creates "massive discomfort with the status quo," you are destined for change.
The scope statement should clearly spell out what will be done and what won't be done during the transition process. It includes details on functional scope; organizational boundaries; interface points; possible benefits; political and cultural issues as to the transition project; root causes of the current problems; risks of inaction and action; and assumptions, constraints, and limitations.
Defining the purpose of the program management function means defining the vision, objectives, and values then communicating them to all appropriate personnel. Vision is the end state that you want the program management discipline to fulfill. Values set the ground rules for expected behaviors and cultural shifts needed to make program management successful.
To get approval from senior management to proceed to the second stage, a preliminary transition plan needs to be developed. It should include scope of work; the transition team; the transition process, schedule, and resources needed; and, most importantly, a risk assessment.
The next stage in the SECURE program management transition process is engineer. Based upon the outcomes of the scope stage, design of a program management function can now be completed. The engineer stage has three steps:
Expand the project team
Conduct design sessions
Develop the program management design
In the first step, the initial team formed in stage one is expanded to include all those who will be affected during the implementation of the program management transition. Hence, the team will include business executive sponsors, a project director, a core team, business-unit champions, and subject experts. The implementation groups will be added once the transition enters the realize stage.
Conducting design sessions is a bit of an art. The challenge of having all key players present (and with very diverse ideas about how to design the program management function) calls for firm direction and superb coordination skills on part of those conducting the sessions.
When refined, the design should include the elements necessary for building the program management function—structure, systems, and culture components (see Figure 14.7).
Structure components: program management process, organization, information, and other technology
Systems components: program management systems, tools, and metrics
Culture components: program management culture, power, and on-the-job behaviors
We will now address each element, some that are including referring to in other parts of this book or not deemed critical to our scope of the book. These elements are as follows:
Program management structure: Structure consists of process, organization, and information technology elements. This process is to be designed as described in Chapters 5 through 8. The options for organizational structure are described in the following section.
Cross-project and cross-discipline program structure: New products, services, and infrastructure capabilities are designed and developed through the combined efforts of many personnel across an organization. These employees work together to address the tremendous number of activities and tasks necessary to achieve a complex development effort. This combined effort requires effective communication, coordination, ability to resolve issues and barriers, and effective decision making both within the team and by senior management. An organizational structure that supports and facilitates this collaborative approach is necessary.
Traditional organizational structures range from the purely functional structure to the purely project-oriented structure. Both extremes create some significant limitations from the perspective of the program management model. The purely project-oriented approach minimizes the critical importance played by functional managers in providing for the long-term viability of the functional capabilities by staying current on the latest technology and maintaining the highest-skilled and best-trained resources to support the enterprise. However, a purely functional organization minimizes the importance of cross-discipline knowledge and a broader view of the development effort. Functional organizations tend to stifle cross-discipline thinking, which is paramount to the program management model. Authority rests only with the functional managers and tends to be inwardly focused. As Christopher Meyer (author of "Fast Cycle Time") states, "By far, the most serious problem with the functional structure is that it serves its members better than its customers."[157]
The most effective organizational structures for the program management model is a compromise of the two extremes—the matrix structure and the program structure. With both approaches, formal responsibility and authority for the development effort resides wholly with the program manager.
The matrix structure: Figure 14.8 illustrates one form of the matrix structure that is used in various companies but is quite commonly used by electronic- and consumer-product companies. There are, of course, many variations of the matrix structure.
In a matrix structure, program team members continue to report directly into their functional organization (depicted as solid lines) and are loaned to the program manager (depicted as dotted lines). The program manager is responsible for integrating the cross-discipline contributions. The functional managers are responsible for overseeing the core capabilities, process, and tools within the function.[158]
Like all structures, matrix management has its strengths and weaknesses. The strengths of the matrix structure are considerable and include the following:[159]
The program manager has access to the entire pool of experts within the functional organizations.
Duplication of functional departments is eliminated, with a single organization for each function.
Resources can be shared intelligently across programs to ensure effective use of critical and scarce skills.
Integration of the functional disciplines is enhanced, which serves to reduce power struggles and improve collaborative teamwork.
However, the matrix structure also has its weaknesses that must be handled. These weaknesses create tension between functional managers and the program manager, it can lead to competition among program managers for scarce and critical resources, and program team members need to learn how to work for multiple bosses.
The second organizational structure that we will discuss is the program organization structure shown in Figure 14.9 This structure comes in many forms and can be found in the aerospace, defense, and automotive industries.
In the program organization structure, the project teams report directly to the program manager. Whether the functional managers report directly to the program manager is specific to the organization. All resources reporting to the program manager are dedicated to and work full-time on his or her program. Generally, cross-program functions such as marketing, finance, and human resources support all programs, therefore, are not dedicated to a single program.
Strengths of the program organization structure include the following:
The program manager is in direct control of all resources on the program.
Resources are completely focused on a single program, which leads to improved productivity and cycle time.
A high degree of cross-project integration occurs.
A high level of program identification and team cohesiveness emerges.
Like the matrix structure, the program organization structure also has its weaknesses. It tends to be more expensive due to the duplication of functions and middle management, divisiveness between a program and the parent organization and other programs can develop, the program manager may not have access to the most qualified expertise in the enterprise, and a dilemma can exist on what to do with personnel once the program ends.
An important element in both organizational structures is that program management is a stand-alone function. This is important to the program management model because the positive impact of program management is considerably diluted when it is contained or assigned within any one specific functional organization.
The last piece of program management structure is information technology. Information technology is the tool used by program management teams to communicate and store information. While collaborative technology tools vary widely in complexity and information richness and offer different grades of efficiency, the crucial point is to devise standard communication guidelines for the use of the tools. In one company, for example, the rule is to use mostly e-mail for daily communication, although it is an information-poor medium that has its own problems. This team member observed, "Sometimes e-mail has a one-day lag. A team member from Romania is going to send us e-mail to the United States and we are going to read it the next morning. By the time we send back the reply, we have wasted a day."
Help for this can come from exchanging instant messages, as in the case of another program management team. "We use instant messaging very heavily. It is installed on all of our laptops and desktops. Obviously during the day we do not expect all team members to be online but a lot of times they are." If more in-depth information is needed, companies use phone conference calls, such as weekly teleconferences. When even richer information is to be communicated, teams use teleconferences and net meetings. But before even thinking about specific collaborative technologies, companies first resolve the issue of the infrastructure. As one program manager pointed out, "I've made sure that everyone on the team has the right office setup at home, so everyone has DSL or cable-modem access [and] mobile headsets so they don't have to have a phone cradled to their ear for three hours, if they're working on a long call, and we'll pay for such an office."
Product and project management software are also elements of information technology design and may be a success factor in programs. For example, in a software development program management function, the most frequently used product management software is for development (for example, Visual Studio); source control system (for example, CVS); enterprise-based configuration management system; defect/issue tracking; test-case tracking spreadsheets (Excel); and document storage solution for sharing documents. Each piece of the information technology has a specific function; the overall purpose is to ensure efficient support to the success of programs. This approach to collaborative product management and project management technology tools—insisting on standardized, integrated, simple, and relatively few of the tools—not only provides a high-communication potential but also helps with all components of program success. The results are more punctual schedules, more satisfied customers, better cost effectiveness, and higher-quality accomplishments. If this approach is not offered to program management teams, programs end up struggling to find the right information technology and how to use it, introducing variability into the program management process. This may lead to subpar program performance. Therefore, information technology should be part of program management design.
Program management systems: These include systems, tools, and metrics. Systems, for example, may include the following:
Changes in policies and procedures
Well-defined roles for all positions that are important to the program management-based organization, including senior management; functional management; core team project managers; individual team contributors; and, of course, the program manager (see box titled, "Roles for Effective Program Management")
Skills to perform the program management role
Program management best practices (see box titled, "Program Teamwork")
Setting performance goals for the program teams
Rewarding performance
Employee development plans
Program management culture: The third element of the program management design (see Figure 14.7), culture, consists of organizational culture, power, and beliefs. No matter what approach is taken to handle the culture element of program management, a conscious effort should be invested to design it, not to let it evolve.
The third stage in the SECURE process, confirm, tests the program management design elements. During this stage, the transition team will see if the design performs as expected. Why would one test the program management design? A lot of time, money, and resources are involved in the transition, and expectations probably run high, at least on part of the transition team and primary sponsors. So, testing the implementation within a controlled environment to detect errors and correct them is wise and inexpensive insurance that the full implementation will succeed.
The confirm stage has five major steps:
Establish the need for testing
Select the pilot test approach
Develop pilot test plan
Conduct pilot testing
Develop benefits statement
There are several reasons for conducting tests of this kind. If executives are reluctant to allocate resources without "hard" data substantiating the expected benefits, or the program management design is radically different from the current model, it is wise to conduct a pilot test to gather data and gain learning (see box titled, "Pilot, Learn, Improve"). We recommend to pilot test a small number of programs, collect and analyze results, report preliminary results to the team, and change the design as needed.
This is stage 4 of the SECURE process. Developing the program management design is easy compared to implementing it. Without a meticulously, well-thought-out plan, the program management model will never become a reality. Like many projects, transition implementation always takes more time than anticipated simply because we have a tendency to look only at the technical, hard aspects of the transition. "Soft" aspects such as politics of change and resistance to change tend to be neglected. In addition, keep in mind that planning is generally no more than preparation for the future.
The ultraplan stage has three major steps, as follows:
Develop the implementation plan
Ensure that appropriate funding and priority is set and approved
Get the go ahead approval.
Getting the right set of people together who have diverse ideas about how to go about transitioning to program management and then developing a transition plan can be challenging. It will test one's ability to lead people and synchronize their ideas and activities.
When completed, the transition plan should have all elements necessary for building a program management function. For example, these elements are as follows:
An activity plan that clearly specifies tasks, deliverables, who does what, schedule, resources, and costs
Comprehensive training plan for executive management, functional management, program and project managers, and individual contributors
Plan for reviewing transition change progress and issues
Political plan
The first three bullets from the implementation plan are well known to practitioners undertaking change initiatives. What is less known are the cultural and political plans. The latter is described in Chapter 15. As for the cultural transformation plan, it is a key factor that a successful transition to program management hinges upon and, yet, very little is known about it. Therefore, we will discuss it in detail in the following section.
The cultural transformation plan: What is organizational culture? In academic books, culture is usually defined as a set of values and beliefs that are shared by members of the organization.[161] For example, believing that programs exist to support organizational goals and strategy. Practitioners define culture as "how we do things around here," such as using a matrix organization to manage programs. Some others argue that culture is collective programming of mind.[162] For example, a company's program team members are programmed by on-the-job training and management mandate to use their company's PLC.
The program culture should be designed to express a set of clearly articulated, performance-oriented values and on-the-job behaviors that are built into program practices. For example, one such value is "being proactive," in which team members practice a behavior of periodic progress reporting that includes predicting the business results, schedule, and budget at completion of their tasks. The intention is that program team members have a sense of identity with the cultural values and accept the need to invest both materially and emotionally in their program. This should make them more engaged, committed, enthusiastic, and willing to support one another in accomplishing the program goals. As a result, they should work harder and be more effective, thereby, increasing success.
No matter what organizational culture definition you use, two things are important. First, the organizational culture is used to direct general behaviors of company employees; for example, the use of consultative decision making. Second, the organizational and program culture are deeply ingrained in program members' minds and behavior. So why is this important knowledge in developing a program management transition plan? Roger Lundberg, director of Chrysler development and vehicle engineering operations for DaimlerChrysler provides this excellent explanation: "There is no single right organizational solution. Each company implementing program management will have to align it with their company's culture." If the program management design does not align with current company culture, there will be human resistance to the transition. Resistance may not result in cultural difficulties, but to put it brutally, it may kill the transition to program management if the resistance and cultural change are not properly managed. One way to manage cultural change is to develop the cultural transformation plan.
There are four steps to the development of the cultural transformation plan:[163]
Understand your current culture
Evaluate the strategic importance of the program management design
Assess cultural fit of the program management design
Develop the cultural risk plan
Understand your current culture: This step involves studying the current project management culture, which again is just a manifestation of your organizational culture when it comes to "how we do things around here." For example, let us assume that the project management culture in a fictitious company uses the same framework from Figure 14.7 Then, study all the elements. To demonstrate, we will give examples of one element of each—structure, systems, and culture.
Structure: We have been using a well-developed matrix organization for all projects, including smaller and larger, routine and innovative, and tactical and strategic ones.
Systems: We use project coordinators to lead projects. They do not have the decision-making power for important project decisions but collect and bring information to functional managers to make the decisions.
Culture: Some of our project coordinators apply a reactionary, others a proactive approach in how they coordinate projects. The former behavior means reacting to daily fires becomes the dominant mode of operation.
Again, this kind of the analysis is done for every major element of the framework.
Evaluate the strategic importance of program management design: In this step, the importance of each major element of the program management design is assessed. The design is that which was developed in the engineer stage and refined in the confirm stage of the SECURE process. We again follow the framework from Figure 14.7 and evaluate only one element of each—structure, systems, and culture.
Structure: According to the program management design, a matrix organization will be used. This structure is crucial to ensure program management is based on effective resource allocation for cross-discipline program teams. The matrix structure is of high-strategic importance for program management implementation.
Systems: According to the program management design, an empowered program manager who is responsible for all major program decisions and results will be in charge of the program (see box titled, "Empowering the Program Manager"). The concept of the empowered program manager is the cornerstone of program management and, logically, has high-strategic importance in the organizational strategy.
Culture: According to the program management design, the program managers will not use a reactionary approach to managing programs but a highly proactive approach. The strategic importance of this element is medium.
In Figure 14.10, we provide a way to organize and visualize the strategic evaluation of each element of design. Degrees of strategic importance are mapped on the y-axis as low, medium, and high. Assessments from this step are entered along the y-axis of the cultural assessment matrix.
Assess cultural fit of program management design: The purpose of this step is to evaluate how well each element of the program management design fits the current culture. Of course, the higher the fit, the lower the cultural risk and the easier it will be to implement the element. In Figure 14.10, assessment of the following is entered on the x-axis:
Structure: According to the program management design, a matrix organization is used. Our current culture has been using a matrix structure for all projects for a long time. Obviously, there is experience with the matrix, which supports the change to a program management matrix. Based on this analysis, the new structure is supported by the current culture, and we assess cultural fit as high.
Systems: According to the program management design, an empowered program manager is responsible for all major program decisions and results of the program. The current culture relies on project coordinators without power to make major project decisions. Obviously, the gap between the current culture and the program management's way of "how we do things around here" is large. Therefore, we assess the cultural fit as low.
Culture: According to the program management design, the program managers don't use a reactionary approach to managing programs but a highly proactive approach. The current culture uses both reactionary and proactive, apparently somewhat in conflict with the new way of managing programs. Hence, we assess the cultural fit as medium.
Develop the cultural risk plan: In this last step, we look at the strategic importance and cultural fit, which define the cultural risk, of each element of program management design. Again, we show only one element of each—structure, systems, and culture.
Structure: The implementation of the organization matrix is assessed to have high-strategic importance and high-cultural fit. Do we need a cultural risk plan for this element? Not really, because the high-cultural fit means the cultural risk is very small, simply, because our fictitious company's current culture is used to the matrix structure. In risk management, this is called the absorb strategy, which means accept the risk.
Systems: The concept of the empowered program manager is of high-strategic importance and shows low-cultural fit. This means high-cultural risk and a high probability of cultural resistance because it is so new to the organization. Several risk management strategies are possible to manage around the risk. We will show two of them. The first is termed the transfer strategy, which means that the high-cultural risk is transferred to a third party. For example, the company may outsource program management, as NASA does in some programs. If this is culturally unacceptable, the company may use the avoid strategy, in which case they would not use the empowered program managers. Instead, they would first have to develop a comprehensive training program for all prospective program managers and senior managers. The company should also hire several seasoned program managers and pilot test several programs prior to full implementation of the program management model to better manage the required changes of behavior and decision making. The idea is to slowly overcome cultural hurdles and implement the concept of the empowered program manager.
Culture: Proactive program manager behavior shows medium strategic importance and medium cultural fit; therefore, this has a medium cultural risk. One way to mitigate this risk is to have more experienced program managers who exhibit the correct behavior, serve as mentors to others, and still manage in a reactive manner (see box titled, Misunderstanding of Lines of Authority").
A successful cultural transformation plan is one that reflects the organization's current culture, evaluates the strategic importance of the program management design, assesses cultural fit of the program management elements, and includes a cultural risk management plan.
Using the approved transformation plan as a road map, the transformation can now be executed. In this stage, the organization begins to operate under the program management model.
The realize stage has three major steps:
Expand team
Hold regular meetings
Celebrate success
The first step, expand team, means that implementation groups should be added to the transformation team. The groups are assigned accountability for specific implementation actions such as develop materials, train people, change policies, develop systems, or restructure the organization. The transformation team will need to meet regularly to monitor implementation, evaluate it, face the implementation challenges, solve them, and share learning.
To not expect challenges when transitioning to a program management-based organization can be foolish, as challenges most likely will be many. From our experience and research, the most common challenges one can expect are resistance to change, tension between program management and functional management, and a misunderstanding on the part of program managers about their boundaries of authority. More details about the challenges are in boxes titled, "Resistance to Change" and "Tension Between Program and Functional Management."
Don't underestimate the power of celebrating success. Celebrate both small and big wins. The point is that social events (for example, team lunch) are necessary to show the team members that you appreciate their hard work. As improvement becomes visible, which is a big win, you need formal celebrations and rewards! Remember, celebrations keep executive commitment and focus strong.
As the organization transforms into a program management-based entity, it becomes self-reliant and no longer needs the support from the transition team. It is at that point when the transition ends and the never-ending game of continual enhancement of the reengineered operation begins.
Terminating the program management transition process involves tying up loose ends such as performing a final account of the transformation, developing a final transition report for historical reference, having a final celebration of success, and disbanding the transformation team.
Once the organization begins full operation under the program management model, continuous improvement in practices, methods, tools, and infrastructure begins. Without such improvement, the program management discipline will gradually deteriorate, losing the ability to support the business strategy of the organization.[164] Avoiding such a predicament and instead developing a continuously improved program management discipline can be achieved through the following steps:
Form a program management improvement team
Identify mechanisms for improvement
Follow improvement process
The program management improvement team is usually part of the team responsible for designing and managing the program management function, typically through a PMO which is the subject of the next chapter. This team has the responsibility for simplifying, improving, and managing the implementation of the program management practices. When forming a team, we recommend that the majority of the program management team members come from the program management ranks.
Ideally, there should be a continuous stream of suggestions and ideas to improve program management. To secure such a stream, one can require that program teams perform post-program retrospective reviews. If the reviews identify needed changes to the program management practices, a change request can be submitted to the improvement team. Additionally, change requests may come at any time from anyone involved in programs. Note that requests are not the only way to collect program management improvement ideas, other methods include surveys, small-focus groups, and one-on-one discussions with practicing program managers.
This process defines steps in acting upon change and deviation requests, as well as an escalation procedure, in case the requests are turned down and those proposing them want management to evaluate them. Change requests are suggestions for making changes to program management, most frequently coming from program teams. Quickly collecting and responding to them is of vital importance. Requests are also significant to deviate from program management. If appropriate, the deviation requests should be allowed to make sure the program management is flexible. These are requests to deviate one time only from some aspect of the program management model 1 for example, a change to the standard metric used. Because they are submitted while the program is in progress, it matters that management responds as soon as possible. Later, the requests can be evaluated to determine if program management should be adjusted.
Approved changes to the program management model should be implemented as quickly as possible, but too much change should not be introduced at any one time into the system. Additionally, to minimize risk and resistance to change, various changes may be best implemented through a pilot process prior to full deployment across all programs.
The process for transitioning to program management involves three major steps: understand the transition, execute the transition, and continuously improve. In the first major step, business and operational factors drive senior management teams to consider moving to a program management model for developing their products, services, and infrastructure capabilities. Business factors include the level of linkage between development output and the strategic objectives of a firm; the need for time-to-money improvements to gain or sustain competitive advantage; and the need to have team leaders with the requisite level of business expertise. Operational factors include the level of technical, structural, and business complexity of a development effort; the number of cross-discipline interdependencies that have to be managed; and the ability to attract and maintain skilled program managers.
We introduced the SECURE process for planning and executing the transition. This is only one model that can be employed. In the scope stage boundaries of the transition are defined. The engineer stage focuses on designing an organizational structure, systems, and culture that supports the program management discipline. The confirm stage is used for pilot testing the designed program management model. Emphasis in the ultraplan stage is placed on planning for full implementation and political and cultural changes that accompany the transition. The realize stage involves execution of the transition plan. The final stage, enhance, is used to terminate the transition and move into continuous improvement of a company's program management practices, methods, tools, and infrastructure.
Some of the most common challenges include resistance to change, tension between program management and functional management, and a misunderstanding about new lines of authority.
[157] Meyer, Chris. Fast Cycle Time: How to Align Purpose, Strategy, and Structure for Speed. New York, NY: Free Press Publishers, 1993.
[158] Gray, Clifford F. and Erik W. Larson. Project Management: The Managerial Process. New York, NY: McGraw-Hill Publishing, 2005.
[159] Larson, E. and D. Gobeli, "Organizing for product development projects", Journal of Product Innovation Management Vol. 5, No. 3 (1988), 180–190.
[160] McGrath, Michael E., Michael T. Anthony, and Amram R. Shapiro. Product Development: Success Through Product and Cycle-time Excellence. Stoneham, MA: Butterworth-Heinemann Publishers, 1992.
[161] Schein, Edgar H. The Corporate Culture Survival Guide. San Francisco, CA: Jossey-Bass, 1999.
[162] Hofstede, Geert. Culture's Consequences, 2 nd edition. London, UK: Sage Publications, 1984.
[163] Schwartz, H. and S. M. Davis. "Matching Corporate Culture and Business Strategy", Organizational Dynamics, American Management Association (1981).
[164] Juran, Joseph M. "Managing for World-Class Quality", PM Network, 6 (1992), pp. 5–8.