Those responsible for managing innovation and the new product development (NPD) process face some universal problems. Statements like “every project seems to be late, never early”, “we always underestimate the project cycle time” and “we constantly pull team members from a project to fix high priority customer requests”, are common. These frustrations are manifestations of process and organizational problems that left unaddressed, continue to hinder a company’s ability to develop new products in a timely manner. The problems do not go away and in fact, over time, the negative impact expands. This article addresses some key reasons, in my experience, for an NPD process to move into a higher state of disorder and how to address the root causes.
Perhaps one of the most significant problems any company experiences executing multiple simultaneous projects is project overload. There are simply too many projects for the resources and tremendous pressure from management to “do more with less”. This typically leads to many project team members assigned to multiple projects and forced to move back and forth between projects and tasks as the next crisis erupts. This is especially true for specific and often scarce skill sets who are dispersed across multiple projects. While this may be necessary in some cases and for some period of time, there is a cost.
Let’s look at a simple example as illustrated in the diagram below, and comes from Goldratt’s well-known book, Critical Chain (1). This illustrates someone who works on three separate tasks. For purposes of our discussion we’ll assume these three tasks are for three different projects and each task takes 10 days. In the top portion of the diagram, the three tasks are done serially. In the bottom portion where multitasking is now required, we assume the employee spends 5 days on Task A, then 5 on Task B, and so on. The result is that every task now takes a total of 20 days to complete vs. 10 days, and both Tasks A and B end later than originally estimated. I would argue it is actually worse. Here we assume that each task only takes the same 10 days when multitasking when in fact I believe the cost of switching back and forth often leads to each task taking longer than 10 days. Now if you multiply this times many other team members who are forced into this mode of working across multiple projects, you can envision the impact on each individual project schedule and results in a significant source of system delay. Sometimes, you just have to go slow in order to go fast.
The above example illustrates the impact of multitasking across existing projects, but another cause for the overload are resources that get diverted to address some other crisis in the business. For instance, maybe the manufacturing organization is dealing with a quality issue on an existing product in production and need assistance from an R&D engineer currently working on a new product. Or maybe a key customer is demanding a new feature or a fix to a software bug. Having been in field sales, I understand how every salesman’s latest lost sale is the most important and the common rejoinder is: “…if only the product had that one feature, well, we would never lose to a competitor!” The problem is that every request for a change to an existing product becomes a crisis, which means key personnel are regularly pulled from a project to work on latest “crisis”. This problem is particularly acute in small to mid-sized firms where employees wear many hats. Again, there is no free lunch. While it may be important to operate this way, there needs to be an understanding of what it will do to project schedules. It has to be factored into planning and expectations otherwise it will only lead to frustration at best or missed opportunities because products are late to market at worst.
So what’s the remedy? First, you have to recognize that from an effectiveness standpoint, no one can really work on any more than about 2 concurrent projects simultaneously. There is ample evidence to support this and is illustrated in the diagram below. There are some exceptions to this rule in my experience. For example, while this holds true for most primary engineering resources (e.g. mechanical, electrical, and software engineers), it may not always be true for other types of resources (e.g. CAD personnel, technicians, etc.) if managed effectively. The individual tasks for these skill sets generally tend to be shorter in duration and the task switching costs lower.
Second, when it comes to deciding what customer requests you are going to address, the business should have some agreed upon decision making process. Typically, I would recommend a gatekeeper who fields all requests, vs. field personnel and customers contacting engineers directly to request a change. I believe this is especially important to implement if the NPD system is currently severely hampered by these kinds of requests. Management will have to be forceful about implementation, at least until the problem is under control. Over time the “rules” might be relaxed slightly depending on circumstances. This might be difficult to put in place if the culture of the organization is fixated on the importance of dropping everything when a customer makes a request. It might be hard to say no, but you may not have a choice.
If you step back and contemplate customer requests objectively, you have to admit that not every request is created equal. There was a very simple, but powerful concept in a recent blog posting by Hutch Carpenter (2) that captures much of what I believe when it comes to assessing customer requests. The diagram below illustrates the concept, and while it seems straight forward, we often fail to make explicit decisions about when we say yes and when we say no, allowing our emotions to dictate the decision. I have been in many situations throughout my career where I have had to say no to a request, and in all cases, if there is a reasonable explanation, most internal and external customer’s will respect the decision.
The interface and relationship between the manufacturing and engineering organizations is an important third issue to address. An especially difficult problem for many small and mid-sized companies that manufacture complex, engineered products, is they may not have a significant manufacturing engineering organization that can function as a “first line of defense” that can assist production personnel with quality or performance issues with existing production. Production personnel may come to R&D for help on a regular basis, causing great disruptions to projects. Maybe this is necessary for business reasons, but there will be an impact on the projects if key personnel are pulled off as it will lead to additional multitasking.
You can approach this in several ways. First, perhaps there should be a gatekeeper in R&D where all manufacturing requests flow, so that at least there is better control over the requests. Second, if there are for example 5 R&D engineers spending 20% of their time supporting manufacturing, is it possible to take one of those 5 “heads” and dedicate them as a manufacturing engineer who can provide that first line of defense? The total number of heads will be the same, but in theory, the effectiveness of those employees will go up. Finally, maybe you approach requests from manufacturing the same way you do customer requests. Maybe some requests are denied. For example, maybe the best thing for the organization as a whole is that manufacturing lives with a yield on a particular process of say 90% vs. the preferred 95%, at least until resources are available. This is where senior management has to be engaged in the process and understand the trade-offs.
A final component of the solution is that you must have some process in place to track and allocate resources. This is part of an effective project portfolio management system and is outside the scope of this article (3). The ability to measure how much time key personnel are spending on various projects, how that will change over time for existing projects and how new projects will be resourced as existing projects are completed are all important. There are many software tools that can used to do this, but if there is no process in place and for small to mid-sized companies, you can easily start with simple tools based on Microsoft® Excel, for example. As you gain experience with the process more sophisticated tools may be appropriate.
In addition to too many projects for the resources available discussed above, another factor that ultimately leads to an overload on the NPD system is how projects are managed, and in particular a failure to recognize the nature of the risk at the outset of each individual project. This invariably results in unreasonable projections for timelines (4). Sometimes this is because there is significant invention associated with the project in addition to the pure engineering development effort, a fact of life in many small and mid-sized firms who cannot separate technology development from product development. I have seen numerous instances of timelines being set for projects which naturally creates expectations within the business, well before the project team recognizes that there is significant unforeseeable uncertainty (commonly referred to as “unk unks”) or high levels of system complexity. Establishing a timeline for this type of project before the uncertainty has been reduced sufficiently sets the team up for failure before the project really gets off the ground. At some point the team will recognize the issue but by then it may be too late and depending on the level of engagement of senior management and the culture, problems may be ignored. All types of organization dysfunction are the result, but the impact on other projects is probably most significant. If an important project gets behind, resources have to stay with the project for longer than projected which then delays other projects.
How do you combat this? Project managers need to understand how to assess the risk on projects and just as or more importantly, the culture needs to support an open and honest discussion about risk. Assessing risk up front can be easier said than done, but competent and experienced project managers who engage senior level engineers in the process and compare a new project to past projects should be able to do this. There are software tools available that can help teams pull apart a project and understand the risk factors (5). The team then has to decide how the risks will be mitigated, if they are related to foreseeable uncertainty, or where there are gaps in knowledge which is a strong indication that there are significant “unk unks” lurking in the shadows. If the risk is high enough, than the organization and senior management has to accept the fact that a project schedule is only an estimate until uncertainty can be reduced, assume that it will take longer than anticipated and consume more resources. This must be factored into the resource allocation process and the portfolio of projects.
A related topic associated with project management and schedule estimates is the concept of the “planning fallacy” (6). Project managers and senior management must recognize how it impacts schedules and resource allocation projections, which again can lead to NPD system overload. Put simply, we all ignore the difficulties we had with projects in the past and believe this project will be different. We believe we have learned from our past mistakes and we will be able to complete this project on schedule. It is rarely true, mostly because every project is different. In my experience, this is why projects typically always run longer than anticipated, and rarely shorter. I had a long running battle with a colleague who could not understand why an equal number of projects would be just as likely to take less time vs. more time than originally estimated. The answer is that if project cycle times were simply chosen at random, then yes, statistically that should be true. The problem is that human nature is at work! The estimates are not random estimates, but are optimistically biased.
Another reason why the NPD process can become sluggish is the concept of “flow” through a system. In a recent book by Donald Reinertsen entitled The Principals of Product Development Flow (7), he relates the revolution in manufacturing associated with the lean manufacturing techniques and “flow manufacturing” to the “flow” of projects through an NPD process. One of the most useful concepts is that of queues, or bottlenecks that are associated with crucial resources. There may be multiple critical skill sets that always seem to be a bottleneck on every project. These employees may have specialized skills or maybe there has been turnover that has led to the problem. Recognizing these choke-points in the process, measuring the queues and working to eliminate these bottlenecks can have a profound impact on the entire portfolio of current projects. It is an area of great leverage because you may not need to spend significant money to impact many projects simultaneously.
A term coined in a whitepaper by Paul O’Connor of the Adept Group is an appropriate way to conclude this article (8). In this whitepaper, the author defines what he calls “portfolio entropy” which is based on the concept of the second law of thermodynamics but applied to a portfolio of active projects. In the author’s words:
“Just like the transmission of disorder from atom to atom, or from molecule to molecule which occurs when no countervailing force is present, we see portfolio entropy drive disorder across the portfolio from resource to resource, and project to project. Allowing new projects to start, shifting resources to put out fires, confronting functional bottlenecks, discovering technical failures, and having key personnel take leave, are just a few of the contributors of portfolio entropy. They all add to the spread of disorder that portfolio managers must address.”
One of the solutions suggested by the author is to be brutally honest about the portfolio and assess periodically whether there are projects that should be delayed or killed outright, as hard as that is for most organizations. He provides an example of a company with 50 ongoing projects and plots cumulative NPV vs. cumulative full time employees. In this example 90% of the gains could be realized with 30% of the resources currently employed. My suspicion is that most companies with multiple active project portfolios who have been in business for at least several years would discover similar results. It takes committed, engaged senior leadership and a robust NPD process to ensure that resources are applied to the best opportunities or reallocated to speed up other projects.
In summary, all the issues discussed that cause the NPD system to seemingly grind to a halt stem from this tendency of the system to move from a state of order to disorder over time. The problems will not fix themselves, and just like the second law of thermodynamics states, the system will continue to move to a higher state of disorder without some countervailing force. Attacking the overuse of multitasking, putting systems in place to deal with customer requests, recognizing that key resources should not be engaged on more than 2 projects simultaneously, understanding project risk and the planning fallacy, addressing resource bottlenecks in the process, and from time to time culling projects from the portfolio are all techniques to help provide that countervailing force necessary to reestablish order.
What other factors do you believe lead to the NPD system becoming highly disordered and seemingly grinding to a halt? Which ones do you feel are most important? Are there other techniques you have used to address the problems?
(1) See page 126: Eliyahu M. Goldratt, Critical Chain. (Great Barrington, MA: The North River Press, 1997)
(2) Decision Flow for Customer Feature Requests. Hutch Carpenter blog.
(3) See this article: Critical Aspect of Project Portfolio Management in NPD Success
(4) See this article: How Project Risk Impacts Project Management in New Product Development (NPD)
(6) See this article: The Impact of the Planning Fallacy on Project Management
(7) Donald G. Reinertsen, The Principals of Product Development Flow. (Redondo Beach, CA: Celeritas Publishing, 2009)
(8) O’Connor, Paul. Overcoming Portfolio Inertia and Portfolio Entropy. Adept Group (www.adept-plm.com)
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, innovation management