How Project Risk Impacts Project Management in New Product Development (NPD)

Project RiskAn important aspect for driving success in new product development and by extension, long-term firm performance, is to maintain a balanced project portfolio (1). In other words, every organization needs to maintain a mix of different types of projects. From a technology standpoint, this would include for example new products which are extensions of existing technologies, products that exist currently in the market but are new to that firm, and finally more radical, new-to-the-world products. Overlaid on top of the pure technology considerations, other factors come into play. For instance, the nature of the market adds another dimension. Maybe the product will be introduced into a market that is very well understood by the firm. This might be especially true of a product extension. In the case of a product that is based on technology that is new to the firm, but is being supplied by a competitor for instance, the firm may or may not be familiar with those customers. Finally for a radical, new-to-the world product, it is more likely to be sold to a new customer base, or there may be little knowledge on exactly how the product will be used by customers once introduced.

The point is, every project is different. Every project has different risk factors, and the risk will likely change as a function of time from the start of the project to when the product is introduced to the market. As a result, an extremely important organization skill is knowing how project characteristics, and particularly project risk, impacts project management. A company skilled at running projects that are incremental extensions of existing products might find that managing a radical, new-to-the-world project is a new skill set that has not been fully developed.

Let’s first focus on the project technology risk (2). For purposes of this discussion, technology refers to the actual technology of the product itself or the manufacturing process technology, or both. There are three fundamental types of project risk categories. The first, and probably the one that most project managers will be familiar with, are variation along with foreseeable uncertainty. Variation is simply risk associated with normal variation in task size estimates. Whenever someone estimates how long a task will take, that estimate is really a statistical entity, not a single number (3). That leads to some uncertainty in the overall project schedule. The other type of common risk are foreseeable events. These are technical challenges that the team can envision they might face that could impact the schedule. Anything that is not accounted for in normal variation and foreseeable uncertainty is what is termed residual risk. Residual risk could in fact consist of the second and third types of risks described below, but for many projects, especially incremental extensions of existing technologies, variation and foreseeable uncertainty dominate, and residual risk is small. These are by far the easiest projects to manage.

The second class of risk is complexity, which exists in a system where there are a large number of parts that interact in non-simple ways. You can have a large system, but it is not necessarily complex unless all the parts interact. In my experience in the analytical instruments business, we often dealt with complex systems based on the fact that the project included all new embedded and upper level software that interacted with multiple electromechanical sub-systems and where the needs of customers relative to the user interface were not well defined. Project risk is higher when you are dealing with complexity, and in my experience, project schedules are more uncertain.

Question mark made of puzzle piecesThe final risk category is unforeseeable uncertainty, which is typically referred to as “unknown-unknowns”. This category of risk is by far the most difficult to deal with. In some projects, you just “do not know, what you do not know”. It is common to face this type of risk if you are dealing with a technology that may exist, but is new to the firm, or is a new-to-the-world, radical technology.

There are three other comments about these risk categories. First, every project will have some level of unknown-unknowns, and those along with risk due to complexity, will make up residual risk described above. If complexity and/or unknown-unknowns make up the majority of the risk, these are the types of projects that tax even the best project or program manager (just ask the project manager(s) who ran the Boeing Dreamliner project!). The second point is that in many cases highly complex systems in and of themselves will lead to unknown-unknowns. In other words, you have no way of knowing how complex systems will interact and what the problems will be. Finally, a project manager has to understand that the risk factors will change as a function of time. At the beginning of projects with high levels of complexity and unknown-unknowns, the risk will be very high, but as the project progresses, and the fog clears, then normal task variation will start to dominate.

The project manager, therefore, is faced with first understanding at least qualitatively just what kind of risk the project faces at any particular time in the project and then secondly, using the appropriate project management tools based on that. A typical Gantt chart works wonderfully once risk has been beaten down to mostly normal variation, but does not work well for projects where unknown-unknowns dominate. For many products and technologies, this will be a project management skill that develops within the organization over time. It will influence, for instance, the need for senior management to understand project risk and to make sure to match the project with the right project manager: just another reason for senior management to be highly engaged in the NPD process.

Once there is an understanding of the type of project risk you may be facing, how will that impact the specific project management tools? Most project manager’s “toolkit” includes an understanding of how to use Microsoft© Project, and specifically Gantt charts. These traditional project management tools work well for projects where risk is primarily normal variation and the specific tasks required to develop the product are clear.

critical chainBut just how do you go about creating a schedule using a Gantt chart? This relates nicely to the concept of critical chain scheduling (4). In this methodology, task sizes are estimated at a 50% confidence level: half the time the task will take longer and half the time it will take less time. In other words, you drive out the padding and you maintain aggressive deadlines. You compensate by adding a project buffer to the end of the project to protect the critical chain and feeding buffers for tasks that feed the critical chain. For this method to work, however, you have to change your thinking. First, you have to focus the resources to start the tasks when required, especially those on the critical chain, and ensure those resources are not suddenly diverted to other tasks and projects. Second you need to reward early completion of tasks, and not penalize late delivery.

For projects with foreseeable uncertainty the typical technique is to create “risk lists”. The team develops a list of all the anticipated technical problems and how they plan on dealing with that specific risk. It will likely influence how tasks are scheduled so that those issues where there might be the most uncertainty are addressed as early as possible in the project. Project management is really all about managing risk. You start with a certain level of risk at the beginning of the project, and as the project progresses, questions are answered, and risk is reduced. Risk lists are a good technique to help focus the team on foreseeable uncertainty and how the risks will be mitigated.

While the use of Gantt charts, “Critical Chain”, and risk lists work well for projects with normal variation and foreseeable uncertainty, dealing with complexity requires additional techniques. When the team is faced with complex projects, there are four key components of the response. First, the team has to be preoccupied with failure. For instance, as prototypes are built and integrated, the focus should be making the system fail. It is only through system failure that the team can ferret out how the various system components interact and where the weakness might be. Senior management needs to support this effort. If a culture exists that penalizes teams for “good failure”, they will be more likely to unconsciously resist trying to make the system fail so they do not have to deliver “bad news”. Second, there needs to be a reluctance to simplify. For instance, if there are three prototypes being tested, and one provides odd results for a specific test protocol, it may be very easy for the team to disregard this result without fully understanding why it happened. In complex systems, it is not uncommon for these anomalies to resurface late in the project, severely impacting the schedule. Maintaining a high degree of resilience is a third component. The organization needs to understand that when dealing with highly complex systems, schedule uncertainty is a significant factor, especially early in the project. Finally, you need to rely heavily on your most senior technical personnel and defer to their judgment. They will likely be in the best position to most efficiently solve the vexing problems associated with complex systems.

The final risk category is unforeseeable uncertainty, or unknown-unknowns. These are the most difficult to contend with or even recognize that they may be a factor. Just knowing that they are a part of a project will require the intuition of your senior technical staff. If faced with this type of risk, the two fundamental tools are “iterate and learn” and parallel trials. Iterate and learn is essentially a “plan-do-check-act” cycle repeated multiple times until the questions have been answered. Another technique is to conduct parallel trials. Here, several solutions are tried in parallel. Parallel trials can save time, but will increase cost compared to iterate-and-learn. In addition, the two techniques can be used together (5).

The diagram below is an excellent summary of the preceding discussion on risk and risk management techniques. It is incumbent on the project manager and senior management to understand project risk, the time-dependent nature of that risk, and how the proper project management tools need to change based on the nature of the risk.

Risk Management Framework

Some recent research relates project risk to two other project management decisions: process concurrency and the level of team integration (6). The authors investigated these decisions and how they impact project success. Process concurrency is the partial or completely parallel execution of specific tasks and activities during the project execution. For instance, developing new manufacturing processes concurrent with development of the product. Team integration relates to nature of the team itself and is typically exemplified by a core team concept that includes members from all functional groups. The conclusions are summarized in the figure below. Project success is not always about maximum team integration and process concurrency, as typically assumed. For instance, for product extensions with little uncertainty and low complexity, a high degree of process concurrency and a very simple team structure is best. Other combinations point to different decisions as illustrated in the figure below. The point is that the amount of project risk also influences other decisions on how to manage projects.

Process Concurrency and Team Integration

In the preceding discussion on the nature of project risk, and the various project management techniques that can be used based on the risk, we focused on the technology. What about the market? For many projects, the product that will be launched will be targeted to customers who are already very familiar to the firm. Their needs are well understood by the firm, and their needs are not changing quickly. In these projects, the focus will be primarily on the nature of the technological risk and managing the project accordingly. For many industrial B2B products, this is a very common situation.

On the other hand, overlaid on the technological risk factors, a new product may be intended for a new market segment that is not well understood by the firm or to a market segment where the needs are constantly changing. These market risks also influence how projects need to be managed. This will extend beyond the engineering team responsible for the technology development, but also to the role of management, product management, and marketing. While these stakeholders are involved with every project, their role is even more important in projects where there is significant market risk.

A recent article in the Journal of Product Innovation Management looked at this issue (7). The author proposed that market or environmental uncertainty is typically related to ambiguity or volatility. In ambiguous environments, the signals coming from the market are open for interpretation: they are just not clear. In volatile market environments, the signals are clear, but are changing dynamically. Their research focused on the important factors that lead to new product success when dealing with these two different types of market uncertainty.

ambiguousFor projects where market ambiguity dominates, the authors concluded that a company should use a broad base of data and techniques for collecting data. They should utilize customers, noncustomers, the supply chain, and employees from various functional groups extensively at the front end. Ideation and front-end participation should be robust. Senior management who might have firm opinions on how to proceed should be careful not to influence the debate and airing of various ideas during the front-end activities. The concepts discussed previously concerning “iterate-and-learn” and parallel trials might make sense in these types of environments. Maybe for instance, it is best to get a beta product into the hands of a few customers, test the response, and continue to perfect the product concept. Alternatively, multiple types of beta products could be introduced and tested. A recent article about Starbucks illustrates how they use this exact concept in dealing with market ambiguity (8). At the back-end of the process, screening of the various solutions should very aggressive. In other words, at some point you have to pick a concept and go with it. Senior management involvement at this point will need to be decisive. The authors note that in many cases, managing a project as proposed above to deal with market ambiguity may in fact slow down the project, but lead to a higher chance of new product success.

When market volatility dominates, it is better to reduce the amount of front-end participation and the amount of ideation, and have robust senior management involvement early. On the back end of the process, more ideas should be kept in play during screening and there should be broad participation in the process to help make adjustments to the plans quickly. The whole idea is to move rapidly to narrow the solution space, but keep options open for as long as possible to respond to the changing signals from the market.

Of course, you could envision an environment where you might face both market ambiguity and volatility. In those cases, the project manager and team will need to maintain a very flexible attitude and be willing to improvise as they go. In these types of projects, especially when you overlay a high level of technological uncertainty, you are dealing with a new-to-the-world, radical innovation. Team structure will be become very important. Recent research (9) confirms that in those cases, the concept of an autonomous team structure, or new venture unit, may be best. In that team structure, the team is led by a senior manager who has a high degree of organizational stature. The entire team report functionally to this manager, and they are typically co-located and dedicated full time to the project.

In summary, every project has different risk factors associated with both the technology and the market. These risk factors also change with time during the life of the project. All projects start out with relatively higher levels of risk and risk decreases the closer you get to project completion. It is crucial that the project manager and senior management recognize the nature of project risk. The specific risk profile will influence how the project is managed in many ways as addressed in this article.

How has project risk surfaced in your projects and how have you handled it? Is your organization skilled at handling the various scenarios described above? Does senior management recognize how project risk impacts project management? How do you deal with unknown-unknowns? Are there other techniques not suggested in this article that have worked for you?

Notes:

(1) See for instance The Importance of a Balanced Portfolio.

(2) An excellent resource on the topic of risk, and one from which I draw on extensively for this article is: Christoph H. Loch, Arnoud DeMeyer and Michael T. Pich, Managing the Unknown (New York: John Wiley & Sons, 2006)

(3) For more information on the related topic of the “planning fallacy”, see The Impact of the Planning Fallacy on Project Management.

(4) Eliyahu M. Goldratt, Critical Chain. (Great Barrington, MA: The North River Press, 1997)

(5) For a more thorough treatment of this subject, see Loch et al., Chapter 7.

(6) Ahmad, Sohel, Mallick, Debasish N., & Schroeder, Roger G. 2013. New Product Development: Impact of Project Characteristics and Development Practices on Performance. Journal of Product Innovation Management 30(2):331-348.

(7) Carson, Stephen J., Wu, Tao & Moore, William L. 2012. Managing the Trade-off Between Ambiguity and Volatility in New Product Development. Journal of Product Innovation Management 29(6):1061-1081.

(8) Carr, Austin. 2013. Starbuck’s Leap of Faith. Fast Company June:46-48.

(9) Patanakul, Peerasit, Chen, Jiyao & Lynn, Gary S. 2012. Autonomous Teams and New Product Development. Journal of Product Innovation Management 29(5):734-750.

New Product Visions is a consulting company that helps organizations improve the effectiveness of their new product development processes. We specialize in small to mid-sized companies that manufacture highly engineered products. Contact us today about how we might help you!

Specialties: NPD consultants, new product development consulting, developing new products, new product development seminars, small business consulting, new product development expert, product development process, new product development strategies, integrating NPD for mergers & acquisitions, organizing for innovation, management role in NPD, project risk analysis

6 thoughts on “How Project Risk Impacts Project Management in New Product Development (NPD)

  1. Pingback: Understanding Risk in Medical Device New Product Development (NPD) | New Product Visions

  2. Pingback: A 5-Step Approach to Reduce Time-to-Market for Manufacturing Firms | New Product Visions

  3. Pingback: A Five Step Approach to Reduce Time-to-Market for Manufacturing Firms |

  4. Pingback: How Risk Impacts New Product Development | New Product Visions

Leave a Reply

Your email address will not be published. Required fields are marked *