Putting brakes on a rocket



“Faster, Better, Cheaper!” This was one of the first things I heard when I first joined Intel as a new product development program manager over a decade ago. The reality of “faster, better, cheaper” hit me quickly as I took on my first new product development program. I noticed that things moved fast—very fast—at Intel. Information comes at you fast, decision making happens fast, and development cycle times are fast. One program manager described managing a new product development program at Intel as being equivalent to “strapping roller skates to your feet and a rocket to your back.

What drives this high-velocity environment? Simply stated, it is a critical component of achieving sustained market leadership within the semiconductor and computing industry. In order to maintain market leadership within a technology industry, an organization must set the pace of technological innovation. A technological follower will not become a market leader in this business sector. Not only must Intel set the pace of technological innovation, it must help its development partners maintain and deliver at the same pace.

Intel has proven that an effective combination of technological innovation and fast development cycle time can deliver great rewards in the forms of high market segment share, profitability, and technology leadership. However, this combination also creates a high-risk environment within which everyone in a development organization must operate, including the program manager and his or her senior leadership team. This environment is illustrated in Exhibit 1.

New Innovation and Cycle Time Speed versus Risk

Exhibit 1 – New Innovation and Cycle Time Speed versus Risk

As the level of technology innovations introduced on a product increases, and as the development cycle time velocity increases, so does the level of risk associated with a new product development program. In order for an organization to reap the rewards offered by this model, it must be willing to consistently take the risks necessary and be able to consistently succeed in meeting customer and market expectations; these require a risk-taking culture.

This paper offers a look at the primary systems, processes, and tools available to the Intel program manager to consistently succeed in leading a new product development team in a high-velocity, high-risk environment.

Development Cycle Time Speed

Utilizing a Program-based Development Model

Because technological leadership is dependent upon an ecosystem of innovation partners, success is dependent upon both internal technological development and external technological development. The complexity of this distributed co-development model must be managed effectively by ensuring that all technology innovations are happening concurrently, that they are synchronized in time with respect to new product introduction, and that the outcomes of all technological development come together (integrate) into a holistic solution at the product level.

Intel utilizes a program-based development model in which multiple projects are managed concurrently as a new product development program. The program management model provides Intel with several key advantages (Milosevic, 2007):

It establishes continual alignment of the execution output to the business goals for which the development effort is initiated.

It is flexible in nature in that it does not matter where development resources are located, but that the work output of the distributed workforce is effectively integrated into a holistic solution in the end.

It provides a common cadence for which the work of the team is synchronized over the development life cycle.

It emphasizes cross-organization collaboration and de-emphasizes functional silos. Management at the program level focuses on delivery of the interdependencies between the projects involved instead of focusing solely on the output associated with any one of the organizational functions.

The key to successful development under a program-based model is to use a top-down approach, which begins with a conceptual design of the final product or service being developed. To demonstrate the top-down approach, a simplified example of the development of a personal computer product is illustrated in Exhibit 2.

A Program-based Approach to Product Development

Exhibit 2 – A Program-based Approach to Product Development

The left side of the diagram represents the conceptual idea of what the final solution will be—the personal computer. From the concept of the final “system,” the projects within the program can be defined by the various elements to be developed. In this simple case, the projects consist of enclosure development, circuit board development, software development, product manufacturing, and testing. Each project is led by a project manager, and the work of each project team is focused and tactical: to plan, develop, and deliver its respective element of the solution to the other members of the program team.

To ensure that the work of each project team is occurring in a coordinated and collaborative manner, and that the work is synchronized over time, the projects are managed within a single program and led by a program manager. The role of the program manager is to ensure that the project elements are developed synchronously and integrated into a holistic solution, and that the distributed team remains focused on the achievement of the business results for which the product development effort was initiated.

Continuous Integration of Project Outputs

Within a program-based development model, both the program manager and the respective project managers are responsible for the success of the program and product or service under development, but they operate in different dimensions.

This concept, as illustrated in Exhibit 3, is a core differentiator of the program management development model. Shown in the exhibit is a simple example of the five functional elements that are involved in the personal computer development program discussed previously: circuit board development, enclosure development, software development, manufacturing, and testing.

Cross-project Integration of Deliverables

Exhibit 3 – Cross-project Integration of Deliverables

Both the vertical and horizontal elements involved in the management of a program are clearly evident in the exhibit. First, let us look at the vertical or project element. The project teams, which consist of functional specialists located in various locations across the globe, are responsible for the development and delivery of their respective pieces of the product or service under development. They are held accountable for the plans, schedules, risk mitigation strategies, quality levels, and deliverables as they pertain to their respective projects.

The work of the program manager cuts across the project teams, therefore managing the horizontal dimension of the program. The program manager drives the cross-discipline, cross-project collaboration needed to create an integrated solution. Within a common program life cycle framework, the program manager synchronizes the work of the project teams as they develop their respective pieces of the whole solution. Use of a common framework ensures that the work of the program team is being performed on a common cadence that facilitates the synchronization and integration of work output.

Streamlined Life Cycle for Accelerated Time-to-Market

With time-to-market speed as a critical component of sustained market leadership, an organization must employ a life cycle that enables a rapid pace through the development process. Intel's new product development life cycle is streamlined for speed. As illustrated in Exhibit 4, at the highest level, Intel's life cycle consists of four phases of development and five decision gates. This can be contrasted with many stage-gate development processes being used by companies today where twice as many stages and gates are common. Every time an organization throws a stage and gate in front of its development teams, the slower its development cycle time becomes. Rather than a true stage-gate process, Intel's life cycle model is viewed and used as a synchronization and collaboration framework.


Exhibit 4 – The Intel Product Development Life Cycle

A brief description of each of the decision check-points follows:

Technology, product architecture, and usage options are evaluated at the Concept Approval (CA) step to determine how well various product concepts address known market and end-user needs, how well they align to the current Intel roadmap of products, and if business expectations can be achieved.

At the Development Investment Approval (DIA) step, a single concept is selected and a full business case is developed and presented to the senior leaders of the organization. Upon approval, funding and resources are committed and the product is added to the new product development portfolio.

A full implementation plan is developed during the planning phase of the Product Life Cycle (PLC), with the detailed plan evaluated at the next major decision checkpoint, the Implementation Plan Approval (IPA). Upon approval, resources are committed to the program and full development of the product begins.

As full product development is completed, arguably the most critical decision checkpoint is approached, Ship Readiness Approval (SRA). At this point, the product development team checks to ensure that the product is ready and at quality levels necessary for full production, if the factories and suppliers are ready to begin production, and if distribution channels and customers are ready to receive the product.

At the end of a product's market life, a Product Discontinuance Approval (PDA) meeting is held to formally decide to discontinue production and sales of the product.

Each of the critical decision checkpoints of the Intel PLC is a business approval meeting, where the current state of program execution is reviewed in terms of the underlying business objectives. The checkpoints are communication and collaboration points between the program manager and the business unit manager.

Establishing Targets and Guardrails

With a streamlined development life cycle, there are limited checkpoints available to the senior leadership team to ensure that a high-velocity program remains on target to achieving the intended business goals. This responsibility therefore shifts to the program manager. A high-velocity program can go off course very rapidly due to the high level of risk associated with it, so the program manager must utilize a good guidance system of targets and thresholds to ensure the program remains on course.

The program strike zone is a tool that is utilized to identify the critical business success factors of a program and to set the boundaries within which a program is considered “on target’ (Martinelli, 2004). It is an effective tool for ensuring the program is planned with the correct set of success criteria, and that the program stays within the success criteria boundaries throughout the program's life cycle. As shown in Exhibit 5, elements of the program strike zone include the critical success factors for the program, target and control (threshold) limits, and a high-level status indicator.

Example of a Program Strike Zone

Exhibit 5 – Example of a Program Strike Zone

As long as the program progresses within the strike zone of each critical success factor, the program is considered on target, and the program manager remains empowered to manage the program through its life cycle. However, if the program does not progress within the strike zone of each critical success factor, the program is not considered on target and the executive managers must directly intervene. The executives can either reset the critical success factor target or thresholds, modify the scope of the program to bring it within the current targets, or cancel the program to prevent further investment of resources.

Development Risk

Embracing Risk

Risk tolerance is the level of risk an organization is willing to accept in order to achieve its business objectives (Martinelli, 2010). Every individual and every organization has a different level of risk tolerance, with corporate culture and values being the primary drivers behind acceptable tolerance levels. Exhibit 6 demonstrates risk tolerance as a continuum, from complete risk avoidance on one end to total disregard of the consequences of risk on the other.

The Risk Tolerance Continuum

Exhibit 6 – The Risk Tolerance Continuum

For example, companies in the aerospace and defense industries have a very low tolerance for risk due to customer requirements and product use conditions. Products in these industries must have very low failure rates; therefore, companies developing the products must adopt a low risk tolerance approach. In contrast, in the commercial high-technology industry, risk-taking is necessary to attain and maintain a competitive advantage through the use of rapidly changing technologies. At Intel, managed risk taking is one of the seven core values of the company.

The program manager must understand the cultural risk tolerance of the organization and adjust his or her risk management practices accordingly. Understanding tolerance levels provides excellent guidance for how much risk a program manager can assume and what response actions are accepted as preferred options within the organization. For program managers and business managers at Intel, this means being willing to accept many of the risks associated with a program, while at the same time being hyper-vigilant about uncovering and tracking all potential risk events. This is the art of balancing risk taking and risk management.

Understanding the Dynamics of Risk

As stated earlier, on high-velocity program and projects, success can be attained quickly, but so can execution failure. Therefore, mechanisms must be in place to monitor and potentially discontinue a product development effort that is doomed for failure as quickly as possible due to the dynamics of risk as demonstrated in Exhibit 7.

The Dynamics of New Product Development Risk

Exhibit 7 – The Dynamics of New Product Development Risk

The severity of impact of any potential risk event greatly increases when it occurs later in the development life cycle, which is due to a number of factors, including the amount of rework required and lost business due to product delay. Additionally, a program manager's ability to respond adequately decreases as a team progresses through the life cycle. It then becomes obvious that the earlier a program headed on a path to destruction is cancelled or redirected, the better.

When developing products in a high-risk environment, diligent risk identification is a mandatory practice. It is not uncommon for a new product development team at Intel to identify well over a hundred risk events during the course of the development life cycle. Of course, not all these events have the potential to lead the program to failure even if they do materialize. The challenge then becomes identifying the short list of risk events with the potential to derail the program. This short list, known as the “Top Ten” risk list, is consistently reviewed between the program manager and the senior leadership team in each of the PLC decision checkpoints, as well as each operational program review.

Putting Brakes on a Rocket

Stopping a program in mid-cycle is one of the most difficult undertakings for any program manager and this is due to a number of factors, such as emotional attachment to the success of the program, organizational politics, fear of failure, or an organizational culture that frowns upon the early cancellation of a program. Stopping a high-velocity program presents additional difficulties due to the natural momentum the program builds as it progresses through the development life cycle.

Through years of practice and a number of cancelled programs, I have come to rely on two primary practices to successfully stopping a high-velocity program that has gone off course: The diligent use of the program strike zone, and the frenetic use of risk identification and assessment techniques.

The program strike zone, which was introduced earlier, clearly sets the definition of business success within a set of boundary conditions. These boundary conditions, in effect, become the guardrails that keep a high-velocity program on target and also become the risk-taking boundaries within which a program team can operate.

In practice, the program strike zone is developed in the first stage of the Intel product life cycle and presented as part of the Development Assessment Approval . The targets and boundary conditions then become debated, adjusted if needed, and ratified by the senior leadership team at this point in the program.

While operating in a risk-taking environment such as Intel, risk identification becomes critical. In practice, Intel program teams continually try to look toward the horizon to identify any and all risk factors that may cause their program to fail. As the program team progresses through the development life cycle, all potential risk events are assessed against the targets and boundary conditions identified in the program strike zone.

At any time a risk event, or series of risk events, is assessed as a threat to any one of the success criteria identified in the program strike zone, the situation is presented to the senior leadership team and other business-level stakeholders, total business impact is evaluated, and, if necessary, the program is discontinued or the success targets are adjusted.

Cancellation discussions are one of the most difficult discussions for a program manager. By utilizing business-level success criteria, which have been ratified by the senior leadership team and by presenting risk events in terms of failure to meet the business-level success criteria, the program manager can now engage in a business-focused discussion with his or her senior leaders. By focusing on business value of a program and the risk to attaining that business value, program managers can position themselves to effectively debate the value of cancelling a program, whether high-velocity or not, with the power-brokers in their organization.


Martinelli, R., & Waddell, J. (2004, March–April). The program strike zone: Beyond the bounding box. PMWorld Today.

Martinelli, R. J., Rahschulte, T., & Waddell, J. (2010). Leading global project teams: The new leadership challenge. Oshawa, ON, Canada: Multi-Media Publications.

Milosevic, D. Z., Martinelli, R. J., & Waddell, J. M. (2007). Program management for improved business results. Hoboken, NJ: John Wiley & Sons.

©Copyright 2010 Russ Martinelli
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC



Related Content