In presenting the business case for program management in Chapter 2, we noted that consumer demand for customized solutions, increased integration of features and functions, and incorporation of the latest technologies are powering ever-increasing product, service, and infrastructure complexity. Many business leaders have come to the realization that their current methods of development are no longer sufficient to manage the higher levels of complexity and have turned to the program management model as the solution.
In this chapter, we describe how the program management discipline is deployed to manage increased complexity of design and process. In doing so, we utilize the concept of the whole product to demonstrate the value of program management in meeting ever-increasing customer expectations. First, we explain the whole product concept and how companies are utilizing it to win in business. Then we define the steps used to develop and deliver the whole product through the program management discipline.
The purpose of this chapter is to fully explore the following concepts of program management:
The relationship between the whole product concept and program management
How program management is used to manage complexity driven by customer wants and needs
The role of program management in the development and delivery of the whole product
These concepts lead to an understanding of the value of program management as a critical business function within a company to effectively manage increasing complexity by developing and delivering complete solutions that fulfill customer expectations.
The concept of the whole product is not new. In marketing terms, the whole product is defined as the products and services that best meet the customer's wants and needs (see box titled, "The Concept of the Whole Product").[56]
If we shift from a marketing focus to a product, service, or infrastructure development focus, the whole product can be defined as the integrated product solution that fulfills the customers' expectations.[57] It is important to note that the whole product can be a physical product, service, or infrastructure capability. If we purchase a personal computer, for example, we wouldn't consider it acceptable if we were delivered a box of circuit boards, a second box containing the enclosure and power supply, another box containing peripheral devices such as disk drives, network adapters, and sound cards, and finally an envelope containing the computer software applications and operating system on a series of compact disks. Rather, unless we're a computer hobbyist or a systems integrator, we expect to receive an integrated computer that we can unpack, set up on a computer station, plug in, and begin using. Thus, we want to experience the delivery of the whole product. For a good example of how market leaders practice the whole product concept, see box titled, "Delivering the Whole Product at Dell Computers."
For companies that use the program management discipline to develop products, services, or infrastructure capabilities, the program manager is responsible for the delivery of the whole product to the marketplace or customer's environment. This means he or she must have a full understanding of what customers expect in the total solution. The project managers for the program are responsible for the development and delivery of the individual elements of the whole-product. Figure 4.1 graphically illustrates the whole-product concept in the development of a personal computer. In this simplified example, the whole product consists of the integration of six elements: the motherboard development, the memory circuit board development, the software development, the enclosure development, product manufacturing, and product testing. Other functions normally involved in the development of a personal computer—such as architecture, product marketing, quality, customer support, quality assurance, and finance—are purposely not shown for the sake of simplicity.
The development program is organized in a similar manner. Each of the six elements of the personal computer shown in Figure 4.1 is organized as a functional project, which is led by a project manager and consists of a team of functional specialists in the domain they represent (see Chapter 5). The job of each project team is simple: plan, develop, and deliver its respective element of the whole product to the other members of the program team.
The program manager, in turn, leads the development program and is responsible for integrating the elements into a whole product and delivering it to the customers and stakeholders. In this case, the whole product would be the personal computer consisting of the integration of the various circuit boards, the memory devices, the enclosure, the software stack, and the manufacturing and testing of the product. In addition to delivery of the product, the program manager is responsible for the achievement of the business objectives for which the product development effort was initiated, ensuring the whole product meets the expectations of the customers.
As many companies have learned, meeting the customer's expectations becomes the means to achieve the strategic business objectives of the firm. If customers put a priority on receiving the whole product, the concept then needs to be part of a company's business strategy. Once it is part of the strategy, the program management discipline becomes responsible for developing and delivering the whole product to the customer. Managing the development and delivery of the whole product involves the following aspects:
Understanding cross-project dependencies
Determining the level of development complexity
Selecting the management approach
Planning the whole product program
Executing the whole product program
One should clearly understand the extent of the dependencies between the projects before choosing a management approach. In the development of a whole product solution, effective management of the interdependencies between the project teams is critical. The interdependencies between projects consist of a series of cross-project deliverables, coordinated tasks, cross-discipline decisions, and shared management of risks and problems that will be encountered on the product, service, or infrastructure development effort.
As the term implies, interdependent projects are those that have a dependence upon the delivery of an output from other projects. For development programs, project interdependencies normally equate to deliverables. A deliverable is a tangible output from one project team that is delivered to one or more of the other project teams. For example, a completed software module handed off from the software development project team to the system test team is a deliverable between two project teams involved on a program. Interdependency between the project teams is formed when a deliverable from one project team is needed to successfully complete the work of a second project team.
To illustrate how interdependencies between projects are a determining factor in program management, let's look at a simplified product development effort. Four of the projects represented on the product development effort are circuit board development, software development, preproduction manufacturing, and system test as shown in Figure 4.2.
The circuit board development project team is responsible for the design and development of the primary control board in the product, the software project team develops the software stack used for command and control of the product, the manufacturing project team builds the physical circuit boards, and the system test project team is responsible for all functionality testing.
Let's examine a few of the cross-project deliverables in Figure 4.2 that form the interdependencies between the projects. The three deliverables shown are: (1) the computer aided design (CAD) files delivered from the circuit board project team to the manufacturing project team, (2) the circuit board control software delivered by the software project team to the manufacturing project team, and (3) the physical circuit boards delivered from the manufacturing project team to the system test project team.
This series of deliverables creates a highly interdependent relationship between the projects. For the first deliverable, the manufacturing project team needs the CAD files from the circuit board project team for the production of the physical circuit boards. A hard interdependency is established between the circuit board development and manufacturing project teams.
The manufacturing team cannot build a circuit board that will be capable of powering and controlling the circuit boards without the command and control software from the software project team. This, of course, would lead to failure of the system test project team to complete the test and validation of the product.
Finally, the system test project team will not be able to successfully complete, let alone start, the product functionality test cycle without the circuit boards delivered by the manufacturing team. The three deliverables described create a highly interdependent relationship between the four project teams. The program manager needs to manage these interdependencies as closely as the independent deliverables created by the project teams.
The level of development complexity is highly dependent upon the number of cross-project interdependencies and has a vital influence on businesses choosing either a project management-only approach or a program management approach. To illustrate, we will simply add two elements to the example above. First, we will assume that the product requires the development of application specific-integrated circuitry by an integrated circuit (IC) development project team. Second, we will assume that the product requires the development of an enclosure to power, cool, and contain the product, requiring the work of an enclosure development project team. Our expanded product development effort is shown in Figure 4.3, with each arrow representing a potential deliverable interdependency between the projects.
One can visualize that the complexity of the interdependency structure between the projects increases with the addition of just two product elements. The original three interdependencies from the previous scenario—CAD files, command and control software, and physical circuit boards—are still required, but many additional interdependencies are required as well. Examples of additional interdependencies due to the expanded development effort may include delivery of the following:
IC characteristics to the circuit board team
ICs to the manufacturing team
Circuit board characteristics and dimensions to the enclosure team
Power and cooling limitations of the enclosure to the circuit board team
Power management software to the enclosure team
In fact, a total of 30 potential interdependencies between the 6 projects are now possible (see box titled, "How Many Dependencies are There among Five Projects?").
To further add to the challenge, the interdependencies above may only represent those required for one phase of the development effort. The same number of deliverables, or more, may be required for each phase of the PLC. One can quickly see that as the magnitude of the development effort increases, the number of interdependencies between project teams becomes unmanageable without an effective approach to structure the development effort.
One could make the case that the project managers from the four projects shown in Figure 4.2 could adequately manage the development effort described on a cooperative basis without the need for a program manager. We do not disagree that this may be true. In fact, development efforts of this nature are managed every day by capable project managers. Many times, one of the project managers is assigned as the lead project manager of the project. The small team of managers is able to plan, execute, and deliver their respective elements of the solution, while cooperatively managing the interdependent deliverables between the projects. In effect, the management of the project is handed from one project team to another, as the development effort moves from design to development to manufacturing to system test. However, industry benchmarking, research, and personal experience shows us that this project management-only approach is sustainable to fairly low levels of project complexity.
Four serious problems are consistently encountered when complexity overrides the project management-only approach. First, as complexity rises, the project managers are required to spend the majority of their time planning, executing, and delivering their pieces of the development effort. This eventually results in a classic waterfall approach in which deliverables are heaved over the wall to the downstream team. Eventually the team comes to rely on the big bang event near the end of the development effort—when all elements of the product, service, or infrastructure capability are expected to integrate flawlessly. Unfortunately, this rarely happens, and the development effort can experience significant schedule and cost overruns due to rework and extended integration efforts. Schedule and cost overruns directly hit a company's bottom line.
A second problem is encountered when the schedule gets tight due to internal or external pressures. When schedule pressure exists, the natural tendency for project managers is to hunker down and execute their project deliverables, with little or no time allocated to managing the cross-project interdependencies or the fundamental business aspects driving the development effort. Business requirements such as design wins, ROI, and cost goals may be left unattended. In this scenario, the product, service, or infrastructure capability may achieve all technical features and functional requirements intended and may be delivered to the aggressive schedule target, but something in the external environment, such as an early release of a competing product, may cause the business aspect of the development effort to go awry. Therefore, while the project managers are focusing on the completion of their respective deliverables, no one is left to focus on the changing environment. The result is normally a product, service, or infrastructure solution that fails to meet customers' expectations. This negatively affects a company's bottom line.
Problem three is that someone needs to be responsible for delivering the whole product to the customers and stakeholders. As the scenarios in the first two problems begin to unfold, the project teams begin focusing on their respective elements of the solution exclusively; after all, they are functional specialists. Therefore, the technical aspects of each functional discipline take precedence over the integrated solution when, in fact, just the opposite has to occur to adequately meet customers' expectations, as the whole product concept teaches us. In the personal computer example, this project management-only approach will most likely create a good basic personal computer that the company can bring to the market. However, as discussed earlier, the basic computer is only one element of the whole product solution that the customer is expecting.
The last problem that can be encountered is that interdependencies between projects grow at a rapid rate. Eventually, the cooperative approach by the project managers to manage the mesh of interdependencies breaks down, and no one is left to manage the large number of interdependencies between the projects. This is a critical point. There are two vectors of complexity that need to be managed. The first vector is the definition of responsibilities and deliverables for each individual project manager and his or her project team. The second vector of complexity involves defining, sorting out, and managing the large number of interdependent tasks, responsibilities, and deliverables that require joint sharing of information, planning, and executing between the project managers and members of the various project teams. Both vectors must be considered when deciding to use either a project management-only or a program management approach to managing products, services, or infrastructure development efforts.
When the level of project complexity increases to the point in which it is no longer effective to utilize a project management-only approach (experience shows that this approach is only sustainable to fairly low levels of complexity) the most effective solution is to adopt the program management model for development.
Two activities that dominate program planning from the whole product perspective are defining the program strategy and developing the program plan. We define the program strategy as the approach, position, and guidance of what to do and how to do it to achieve the highest competitive advantage and the best value from the whole product. This is done by means of spelling out the four elements of the program strategy: the product, service, or infrastructure definition; the business case; the success criteria; and the integrated program plan. Each element is entirely focused on the whole product. For example, the whole product concept describes the feature set for the whole product, as well as other services and ancillary devices needed to maximize customer value. Details of developing a program strategy are covered in Chapter 3.
Developing the program plan requires a business's understanding of all the elements needed to provide the whole product solution, identifying the project deliverables and cross-project interdependencies and integrating multiple project plans into a master program plan that will meet customer expectations and achieve the intended business results.
When utilizing the program management model to plan the synchronized work of multiple interdependent projects to develop and deliver the whole product, it is helpful to view management responsibilities within the program in two dimensions: vertically and horizontally. This concept, as illustrated in Figure 4.4, is a core characteristic of the program management model. The figure shows a simple example of five functional elements that may be involved in a product development program—circuit board development, enclosure development, software development, manufacturing, and system test. Once again, other functions such as system architecture, product marketing, quality, customer support, and finance are normally involved in a product development program but are not represented in the diagram for the sake of simplicity.
Both the vertical and horizontal elements involved in the management of a program are clearly evident in the figure. First, let's look at the vertical or project management element. The work of each functional organization involved in the development effort is structured as a project and is led by a functional project manager. These project teams of functional specialists are responsible for the development and delivery of their respective pieces of the product under development—each piece represents one element of the whole product. During program planning, each project team develops its respective plan, based upon interdependencies with the other project teams.
The work of the program manager cuts across the functional project teams; therefore, he or she manages the horizontal dimension of the program. To create an integrated product, service, or infrastructure solution, the program manager is responsible for ensuring the following three primary things: (1) the deliverables from the project teams form an integrated whole product solution, (2) the highly complex network of project interdependencies is synchronized and coordinated throughout the PLC, and (3) the program business case remains viable.
During program planning, the role of the program manager is the master integrator. As the project plans are being developed, the program manager and his or her core team ensure the plans integrate with one another to form the master program plan. Program planning is covered in detail in Chapter 6.
Program execution is about implementing the program plan and adapting to the operating conditions, as needed. We present a big picture view of program execution in relation to developing and delivering the whole product. Details of program execution are covered in Chapter 7.
The end result or output of the work accomplished by each project team is known as the project deliverables. As an example, the circuit board development project team is responsible for delivery of the various circuit boards that make up the whole product; the software project team is responsible for delivery of the software stack (application, drivers, and utilities) for the product; and so on for each of the functional project teams. Again, the project managers are managing vertically, or within their functional domain, to develop their respective element of the whole product and deliver it to the other members of the program team.
A distinguishing factor of the program management model from other forms of management is that the functional project teams cannot take a silo approach to developing and delivering their element of the whole product. Each project team within the program is highly dependent upon cross-project deliverables from the other project teams to be successful, as demonstrated earlier in this chapter. The cross-project deliverables are the second aspect of the horizontal dimension of a program. They form a highly interdependent relationship between the project teams that must be managed as closely as the effort to create the individual product deliverables. In Figure 4.4, the cross-project deliverables are represented by the horizontal lines between the projects. We call this cross-project interdependency the "space" between the project teams. Management of the space between the projects is the responsibility of the program manager and involves the identification and synchronized delivery of the project interdependencies. This is accomplished through interface defintion, cross-project coordination, communication, decision making, problem solving, and team-based risk management.
The third dimension of the program management model is time, specifically time to money or time to go live. Management of time is accomplished through the use of a PLC to synchronize the work of the cross-project, cross-discipline program team. The development of the interdependent cross-project deliverables must be synchronized in time to achieve the time to money goal. Thus, effectively managing the work output of multiple projects to achieve time to money is a competitive advantage provided by the program management discipline. The program manager utilizes the PLC to accomplish this synchronization in a concerted manner. Much like a conductor who ensures each instrument section within an orchestra is synchronized in time and measure until the concert is completed, the program manager utilizes the PLC to establish the cadence and synchronize the work of the project teams to develop the whole product.
The three dimensions of the program management model—the vertical management by the project managers, the horizontal cross-project management by the program manager, and the synchronization of work through time—are combined to create the integrated output of the whole product. Thus, program management enables competitive advantage through delivery of the whole product and accomplishing the business goals. It's about the business.
The final piece of the whole product concept involves viewing the development of the whole product from a company perspective. With such a perspective, the system itself is the whole product, which is defined earlier as the final product, service, or infrastructure capability under development. The system is comprised of subsystems or the elements delivered by each of the project teams. The subsystems are, in turn, comprised of components that are derived from technologies and human capabilities within each of the functional teams.
For those familiar with the concepts of systems development, the whole product approach to developing products, services, and infrastructure capabilities should seem very familiar. The whole product approach encompasses systems concepts with a slight twist of terminology. For example, in the systems approach, a system is decomposed into smaller modules called subsystems but called elements in the whole product approach. Figure 4.5 demonstrates the direct correlation between the whole product and a system.
It also shows the division of responsibilities for development of the whole product. Functional managers and their organizations are responsible for developing and delivering the technologies and human capabilities needed to create the elements of the whole product. The project managers are responsible for developing and delivering the functional elements of the whole product. Finally, the program manager is responsible for the integration and delivery of the whole product to the market or customer's environment.
Lastly, it is important to understand the environment within which the whole product exists. As shown in Figure 4.6, the whole product is a single system that is part of a greater business ecosystem, which is comprised of the business unit that is funding the development of the whole product, the enterprise that is comprised of multiple business units, the partner and supplier businesses that support the enterprise, and finally the market that consists of both customers and competitors within which the enterprise operates.
By viewing the business ecosystem in the model shown in Figure 4.6, one can see that the whole product has an enormous impact on the success of the business unit. Likewise, the impact on the business unit will affect the enterprise as a whole and have influence on the partner and supplier businesses, as well as the markets within which the enterprise operates. The program management discipline, as owner of the whole product, has responsibility for effective delivery of the whole product into the ecosystem. Thus, this discipline helps to execute the business strategy of the enterprise and positively affects partners and suppliers of the enterprise, as well as the markets that the enterprise serves.
This chapter introduces the concept of the whole product, which we define as the integrated product, service, or infrastructure solution that fulfills the customer's expectation. The whole product concept demonstrates the true scope and nature of the program management discipline and explains how it can be utilized to manage ever-increasing levels of development complexity.
Managing the whole product involves multiple aspects. First, the whole product solution is broken into multiple elements that become the projects within the program. Then, understanding the project dependencies as the foundation of development complexity. Determining which management approach to employ is largely based upon the level of complexity. The project management-only approach to product, service, or infrastructure development is sustainable to lower levels of complexity. When complexity overrides the effectiveness of the project management-only approach, the program management model becomes a viable alternative. To deliver the whole product, program management involves the management of highly interdependent projects that must be collectively managed in a concerted manner to meet customer expectation and achieve improved business results. The program manager's role is to lead a cross-project team in defining, sorting out, and managing the large number of interdependent tasks, responsibilities, and deliverables that require joint sharing of information, planning, and execution between multiple project teams. The whole product can have a huge influence on the entire ecosystem within which a company operates. By owning the development and delivery of the whole product, the program management function owns achievement of a portion of the business objectives. Thus, it operates as a critical business function within the organization.
[56] Moore, Geoffrey A. Crossing the Chasm. New York, NY: Harper Collins Publishing, 1991.
[57] Martinelli, Russ and Jim Waddell. "Aligning Program Management to Business Strategy". Project Management World Today (January-February 2005).
[58] Moore, James F. and Jonathan Reese. Death of Competition: Leadership and Strategy in the Age of Business Ecosystems. New York, NY: Harper Collins, 1996.