Like all other teams, program teams have a set of fundamental elements that distinguish effective teams from ineffective ones. Program teams must be effective in the following areas for success:

Decision Making

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 functional 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 utilize 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 to be effectively utilized for program-level decisions.

An effective program decision is described as one that has the following characteristics:

• Not reached by a single individual

• A sound solution to the problem

• Based upon input provided by each team member involved in the decision process

• Aligned with the program objectives and success criteria

Program teams are charged with making the following 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 key partnerships or alliances in which to engage. Tactical program decisions may include which features to incorporate and exclude, the number of prototypes to build, and changes to the program schedule. Operational program decisions may include factory scheduling, which common cross-project processes and tools to employ, and how to communicate progress to program stakeholders.

The final key aspect of program decision making is that it must incorporate what we describe as both vertical and horizontal decisions. As stated earlier, program-level decisions involve cross-project and cross-discipline input and involvement. Additionally, effective program decision making involves the empowerment of the project teams to drive functional, project-specific decisions.

All vertical or project-specific decisions have the potential to affect other projects on the program. When this occurs, the decision must be ratified at the program level. Conversely, all program-level decisions will impact one or more project teams. Therefore, the decision must be evaluated across the projects before a final decision is implemented. This requires a high degree of communication between the program manager and the project managers on the program. Figure 5.1 graphically illustrates the difference between the vertical and horizontal decisions that occur on a program.

Let's look again at a personal computer development example to illustrate the interplay between the vertical and horizontal decisions involved on a program. Competitive intelligence has indicated that a competing product will be introduced within two months of the computer launch with a higher microprocessor-base frequency (frequency is a measure of how fast a computer will operate). A program-level decision is needed to decide if the base frequency of the computer should be increased to stave off the competitive threat. The microprocessor project team is charged with evaluating the technical aspects of increasing the base frequency and the impact to their element of the computer product. It is determined that the higher frequency is achievable but will require a larger physical size, higher power requirements, and a new frequency control algorithm. This information is then brought back to the program level for evaluation by the program manager and the project teams. The computer motherboard project team must evaluate the impact and feasibility of the increased physical dimensions of the microprocessor, the power supply team must evaluate the higher power requirements needed, the enclosure project team must evaluate additional cooling requirements due to the added power, and the software development project team must evaluate the impact and feasibility of developing new code for the frequency-control algorithm. When analysis by the project teams is complete, a program-level (horizontal) decision is made by the program manager with consultation input from the project managers to increase the base frequency of the microprocessor. This then will spawn a series of tactical discipline-specific project (vertical) decisions to implement the new course of action. The entire program team now shares responsibility for the results.

Figure 5.1. Horizontal and vertical program decisions.

This example demonstrates how effective program decisions require well-coordinated and communicated interplay between horizontal and vertical decisions. For this process to be effective and efficient, two critical elements must be in place. First, the program team structure must support the high degree of communication and coordination between the project teams. Second, the program team must be empowered by the 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 implementation, thus, reducing efficiency and effectiveness.^[63] 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, Meyer and Lehnerd state that "there is no organizational sin more demoralizing to teams than lack of empowerment."^[64] 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.

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 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 screwup on the part of someone wipes out ten attaboys."

Team-based Risk Management

The final characteristic of an effective program team is cross-project or team-based risk management. As the term implies, team-based risk management involves a cooperative effort on the part of the program manager, the functional project managers, and program support personnel to identify and mitigate risks before they become problems.^[66] Team-based risk management requires a systems perspective in which risks are viewed as potential problems for any of the project teams involved and for the success of the program as a whole.

The Software Engineering Institute (SEI) states that the team-based risk management approach is founded upon a shared vision for the program that is structured out of the individual views of the functional project teams. It is also anchored by open communication between all members of the program team.^[67] Open communication is the vehicle by which the functional project-risk viewpoints are merged to form a shared-risk view for the product, service, or infrastructure capability under development.

Effective team-based risk management is built on nine core principles that are summarized in Table 5.1.

The relationship between functional project team risk management and program team risk management is illustrated in Figure 5.2 The program manager is responsible for evaluating risk of the whole product. Therefore, the program manager is responsible for any risk that can affect the success of the whole product, up to and including the business risk. In addition, he or she is responsible for the many risks involved in the interdependencies between the projects. The project managers, by contrast, are responsible for managing the risk associated with their respective functions, which can affect the successful delivery of their element of the whole product.

Table 5.1. Nine core principles of team-based risk management

Principle	Fundamentals of the Principle
Shared vision	A shared vision for success is based upon commonality of purpose, shared ownership, and collective commitment
Forward-looking search for uncertainties	Thinking toward tomorrow, anticipating potential outcomes, identifying uncertainties, and managing program resources and activities while recognizing the uncertainties
Open communication	A free flow of information at and between all program levels through formal, informal, and impromptu communication processes
Value of individual perception	The individual voice that can bring unique knowledge and insight to the identification and management of risk
Systems or whole-product perspective	Product, service, or infrastructure development that must be viewed within the larger systems-level definition, design, and development
Integration within program management	Risk management must be an integral and vital part of program management practices
Proactive strategies	Strategies that involve planning and executing program activities based upon anticipating future events
Systematic and adaptable methodology	A systematic approach that is adaptable to the program's infrastructure and culture
Routine and continuous	A continuous vigilance characterized by routine risk identification and management activities throughout all phases of the PLC.

Figure 5.2. Program and project risk management relationship.

Project-level risks that are identified as also being program-level risks become part of the program risk inventory, and the respective project manager assumes ownership for the resolution of the risk. We go into more detail on program risk management in Chapter 8.

Advantages of team-based risk management include the following.^[68]

• Multiple perspectives of a risk: Brings functional project teams together in identifying and mitigating risks and opens doors to strategies that the entire program team can cooperatively implement; this is more effective than a single team working alone.

• Broader base of expertise: The combination of cross-project representation brings together a richer pool of experience and expertise in perceiving and dealing with risks.

• Improved communication: By openly sharing risks, the cross-project program team is able to draw on one anothers resources to more rapidly identify and respond to risks.

• Shared vision: Risk management efforts are focused on a broader vision of shared program success than project-specific risk management.

• Better decision-making: Team-based risk management gives decision makers a more global perspective of risk impact on the success of the program.

Through team-based risk management, the program team collectively possesses greater knowledge about risks to the program, thinks in a broader perspective, and manages the mitigation of risks more effectively than a single project team.

The foundation for effective team-based risk management, as well as for all the other elements of effective team performance described on page xxx, with the implementation of a solid program team structure. A program must be structured in a way that enables all functional project teams to be part of all aspects of the development process. The most effective program structure we have encountered and utilized is PCT structure, the specifics of which are covered in the following section.

The program manager is the leader of the program team and of the program in its entirety. In this capacity, the program manager is the champion for the product, service, or infrastructure capability under development and has primary influence over the work of the people involved with the program. In the core team structure, the core team members report to the program manager in an indirect relationship for the duration of their participation. The direct reporting and career development of the core team members still resides with their respective functional managers.

The program manager integrates the work of the functional project teams (see box titled, "My Job was to Integrate Two Cultures,") and as the leader of the PCT, he or she has the following duties:

It should be apparent that the program manager must earn the respect and right to carry out these duties based on prior experience, well-developed skills and capabilities, and respect and empowerment that is established over time. Having a qualified program manager who can fulfill these responsibilities is a prerequisite to an effective PCT structure.^[70]

The PCT is the cross-discipline and cross-project leadership, and decision-making body of the program that is responsible for ensuring the program and business objectives, as well as customer satisfaction, are achieved.^[71] The PCT consists of the functional project managers who represent their functions and provide leadership for the delivery of their function's element of the product, service, or infrastructure capability under development. Collectively, the PCT constitutes the management team of the program that works under the direction of the program manager.^[72] The PCT must become a very tight and cohesive team that has a shared responsibility for the business success of the program. Each member of the core team must be committed to the success of the other members on the team. A primary responsibility of the program manager as leader of the PCT is to build a trusting, cohesive team and lead them to mutual success by way of program success.

The size of the core team is dependent upon the elements making up the item under development and complexity of the solution. This is defined by the program requirements, but typical PCT size varies between 4–12 members, including the program manager. To illustrate, let's look at an infrastructure development example in which a program is formed to convert a company's personal computing capability from a desktop to a laptop platform to increase worker productivity—the business objective. Figure 5.4 shows the primary interdependent projects that must be formed, planned, and executed to develop the whole product solution and achieve the business objective.

Figure 5.4. Infrastructure program elements.

The program consists of the following six primary elements that make up the whole solution: the hardware platform, the operating software, the application software, security, the infrastructure compatibility, and user support. Each element is organized as an interdependent project lead by a project manager who owns the delivery of their element of the computing capability to the rest of the program team. In the spirit of form following function, the PCT consists of six project managers and the program managers, as illustrated in Figure 5.5 Other support functions, such as quality and finance, may also be included in the core team.

Product development teams at Intel tend to be relatively large. Figure 5.6 shows a typical core team of an Intel program to develop a server computer. The core team consists of 12 members, as follows:

Figure 5.5. The infrastructure development PCT.

Figure 5.6. Intel server development PCT.

This core team is fairly large and is driven by the functional elements needed for the successful development, delivery, and support of the Intel server product under development.

PCT members have to fulfill the following two types of responsibilities: Program team responsibilities and functional responsibilities. Therefore, it is said that core team members wear two hats—the program hat and the functional hat.

Program responsibilities of the core team members include the following:

Functional responsibilities of the core team members include ensuring the following:^[73]

As the leader of the PCT, the program manager facilitates the communication and collaboration between the members of the core team. He or she also brokers any conflicts and issues that arise between core team members, the core team and the functional managers, and the core team and senior management.^[74]

The extended team consists of individual contributors that make up the functional project teams. They can be assigned to the program on either a full-time or part-time basis depending upon the work they are assigned. They are responsible for ensuring their respective project accomplishes all deliverables to the program within schedule, allocated budget, and with full functionality and performance.

The functional project managers lead the extended team and are the primary decision makers on each project team. It is common for many of the functional project teams to be organized in the same horizontal manner as the PCT.

For example, consider a software project manager who is a member of a PCT. In addition to representing the software function on the PCT, the software project manager also leads the software project team. The functional team leads on the project team may include the operating system team lead, firmware team lead, basic input-output software BIOS team lead, and the software drivers team lead, as shown in Figure 5.7 Each team lead will have a set of individual contributors reporting to him or her for the duration of the team's involvement on the program. The individual contributors are specialists in their respective functional areas or domains.

Figure 5.7. Software project team structure.

Management of the program occurs at multiple levels of the organization. Executive management sets the business strategy and objectives; the program manager and the PCT defines, plans, and implements the program objectives that help achieve the business objectives; the functional project teams plan and execute the specialized work to deliver their element of the product, service, or infrastructure capability; and the functional managers ensure the project teams are adequately staffed and that functional capability is sufficient to achieve the program goals.

With the program core team structure, the biggest fundamental change to roles and responsibilities within the organization is that of the functional manager. Under a functional or project structure, the functional manager has significant power and influence, but under the PCT structure, much of the power and influence for a specific program shifts to the program manager. Power and influence for the functional managers is diminished as they take on a program support role.

Under the PCT structure, the functional managers are freed from the daily execution details of a program and can focus on the capability growth of their function. They can now focus on hiring, training, and developing the functional specialists within their organization; maintain skills, best practices, and tools to sustain long-term functional expertise; make resource and work commitments in support of the program; and assign qualified functional project managers to represent their functions on programs.^[75]

As the PCT becomes empowered to make program-level decisions and has control over the program resources, the functional managers can become uncomfortable with the new structure. This should always be viewed as a significant risk to implementation of a core team structure and needs to be resolved immediately by senior management.

The program manager must establish good working relationships with the functional managers supporting his or her program. Program managers need the help of functional managers to resolve cross-functional contentions, help make key trade-off decisions, keep programs adequately staffed with skilled resources, and provide technical review of cross-project work.

The core team concept fully supports the highly integrated nature of programs through the horizontal structure that is the basis of the approach. Only two levels of management separate an individual contributor and the program manager or a core team member and executive management. The horizontal structure of the PCT ensures that responsibility is divided and shared among the functional project team managers and that no function has more influence than another. All work on the program team is jointly planned and executed by the members of the PCT and extended team. Tasks, deliverables, and timelines are highly integrated between the project teams, and the resulting integrated plans and schedules are overseen by the PCT and, ultimately, by the program manager.

Coordination and communication within the PCT occurs both horizontally and vertically. Figure 5.8 demonstrates the triangulation of collaboration and communication that takes place on a core team. Directions, decisions, and cross-team issue brokerage come from the program manager to the project managers; cross-project communication and work coordination occurs between the project managers; and status, decision consultation, and issue escalation come from the project managers to the program manager.

As demonstrated in Figure 5.9, when the third element of the program team, the extended team, is added the more traditional vertical or hierarchical coordination and communication that is typical of a traditional functional project team structure becomes evident.

Figure 5.8. Core team collaboration and communication triangulation.

Decisions, direction, and program pass downs come from the functional project managers to the extended program team members. Work status, issues, and detailed risks come from the extended project team members to the respective functional project managers. The large majority of the cross-project coordination and communication occurs at the core team level, even though some detailed interaction will occur between individual contributors on the project teams.

The horizontal, cross-project structure that the core team approach provides is key to establishing the shared responsibility and understanding needed to achieve program success. In addition to enabling effective cross-discipline and cross-project coordination and communication, the PCT structure also enables the other elements needed for program team success; empowered decision making, cross-discipline problem solving, and team-based risk management.

Figure 5.9. Vertical program coordination and communication.

With each function represented on the PCT by an empowered project manager, the team can make effective decisions based upon multiple points of view. With decision-making power contained within the PCT, decisions can be reached quicker than having to go outside of the team for functional evaluation and/or approval. The same can be said for effective problem solving. Problems can be evaluated and resolved more efficiently and effectively under the PCT structure due to the cross-discipline viewpoints and involvement embedded in the team structure. Under strong leadership from the program manager and the related tools available to them, core teams are effective in breaking through the problem solving and decision-making bottlenecks that occur with other forms of team structure.

As established earlier in this chapter, effective team-based risk management is critical to program success due to the high level of complexity and uncertainty involved. The core team structure establishes the shared vision for the program that is needed to adequately identify, assess, and resolve the key risks that threaten the success of the product, service, or infrastructure under development.

Hopefully, we've made the case that if an organization is utilizing a program management model or planning to implement the model, team structure in the form of a PCT is the keystone to successful execution of the organization's programs. The following section will describe a common evolution that organizations go through to develop an effective program structure. It should be noted beforehand that this type of evolution is not recommended. We recommend that an organization directly implement a PCT structure, even though it may be a large step from the current structure.

The functional team structure is probably the most common team structure utilized today.^[76] In this approach depicted in Figure 5.10, each functional team sequentially works on their element of the program, then hands both the work output and program ownership to the next functional team in line.

For the example shown in Figure 5.10, once the architecture is completed, it is handed off to the hardware functional manager and team, along with ownership of the program. When the hardware design is complete, the design and program ownership is handed off to the software functional manager and team, and so on down the line to final integration and delivery.

This structure has many vertical layers within each of the functions involved in the development effort; therefore, strong functional expertise can be established. However, this structure is not effective for the program management model. First, it lacks the necessary horizontal structure needed for effective coordination and communication between the functional teams. There are too many barriers between the functional teams, which inhibit effective cross-team collaboration.

Figure 5.10. Functional team structure.

There is usually also a lack of shared responsibility and ownership of the product, service, or infrastructure under development. Under the functional structure, team work output and program ownership tends to be "thrown over the wall" when the development effort transitions from one team to another. When problems occur downstream, there many times is a lack of willingness on the part of upstream teams to reengage with the development effort, as they are typically already working on another program.

The silo structure of this approach also tends to be very slow and cumbersome due primarily to ineffective problem solving and decision making. When problems are encountered, the functional team that currently has ownership of the development effort becomes responsible for evaluation and resolution of the problem. Many times there is a lack of cross-discipline information needed to effectively define the right problem and establish the right solution. Instead, a lot of finger-pointing tends to take place, which can bring progress to a complete standstill. In addition, decisions are typically made outside of the program team under the functional structure and become the responsibility of the functional managers. With the large number of decisions necessary for a single development effort, a functional manager can quickly become a bottleneck to progress, especially if he or she is supporting multiple development programs.

The biggest drawback of the functional structure, however, is the lack of a shared vision of success among the functional teams, which is a critical element of the program management model. Each team is focused and rewarded on elements that are specific to that function and are not usually held accountable or rewarded for achievement of the overriding business results. In addition, the technical solution for each function tends to be more important than achievement of the business objectives. It is quite common under the functional structure to see a misalignment between functional goals and business goals.

One of the major weaknesses of the functional structure for a program is the lack of a single person to manage a function's activities and deliverables. This responsibility falls on the shoulders of the functional manager, who is normally supporting multiple programs. The next logical step in the evolution of a program structure is the assignment of project managers for each of the functional teams involved on the program. Thus, the multiple project team structure is established, as illustrated in Figure 5.11 The program now begins to look more like a collection of multiple related projects.

Figure 5.11. Multiple project team structure.

The primary advantages of this structure over the functional team structure is that true project management skills are introduced into the development effort, and the project manager for each function is focused on and responsible for his or her team's performance on a single program. These advantages benefit the functional managers of an organization most and actually do little to benefit the program.

The major drawbacks experienced in the functional team structure are still experienced in the multiple project team structure. The program is vertically structured, with little horizontal collaboration between the project teams. There is a lack of shared responsibility for the product, service, or infrastructure capability under development, with work output typically being sequentially handed from one team to the next. Good cross-discipline problem solving and decision making are not enabled and continue to be inhibitors to progress. Finally, the misalignment between project team success and program success is not resolved by this form of structure.

Organizations normally come to realize that a silo organization, either with or without functional project managers, is not sufficient to manage the highly interdependent and complex nature of their programs. Astute business managers realize that they need someone to facilitate cross-project coordination and communication to gain more efficiency in their development programs. The next step in the evolution of the program team structure is what we call the coordinated project team structure in which a program coordinator is used to oversee cross-project coordination and communication, as demonstrated in Figure 5.12.

Figure 5.12. Coordinated-project team structure.

Under the coordinated-project team structure, the program coordinator becomes responsible for initiating and facilitating the horizontal cross-project interplay that must be established for effective program execution. However, the program coordinator does not possess the organizational clout or requisite skills to effectively lead the functional project managers on the program. Additionally, the program coordinator has not been empowered by senior management for ownership and accountability relative to the results and success of the overall program. This person, therefore, tends to focus more on the tactical elements of program management such as coordinating cross-project schedules, facilitating communication between the project teams, and creating status reports for senior management.

With the coordinated-project team structure, some level of horizontal coordination and communication is established, with the barriers between the project teams softened but not eliminated. Senior management will now begin to sense the beginning of interdependent relationships between the functional project managers. However, without a true program manager leading the program, power and influence still reside within the functional organizations.^[77] Therefore, most of the drawbacks with the functional team and multiproject team structures—such as lack of shared ownership for the product, service, or infrastructure under development, cross-project problem solving and decision making, and the misalignment between project team success and program success—still exist. Meanwhile, the program coordinator is tolerated but barely valued by the functional teams on the program.

The final phase of the program structure evolution occurs when senior management of an organization realizes that the functional silos need to be minimized to effectively execute its program. With that, a new horizontally focused program structure must replace the vertical structure legacy. In addition, an empowered leadership position is put in place to skillfully integrate the work of the functional project teams. Hence, the implementation of the PCT structure within the organization, as illustrated in Figure 5.13.

Under the PCT structure, program ownership belongs to the program manager, who is fully empowered by the senior management team of the enterprise. In this capacity, the program manager drives the cross-project and cross-discipline coordination and collaboration that is necessary to eliminate the barriers brought upon by functional silos and, in the process, establish strong interdependent relationships between the project teams.

Figure 5.13. PCT structure.

The PCT now possesses shared ownership of the product, service, or infrastructure that is under development. The core team structure is highly integrated, meaning there is joint consideration of trade offs, decisions, problem resolution, and risk identification and management.

It's important to reiterate that taking an evolutionary approach to implementing a PCT structure is highly inefficient (see box titled, "The Battle of Powerville," for an example of a failed transition of power). We strongly recommend avoiding this implementation approach. Be brave and take a revolutionary approach but effectively manage the change!