Is a Phased Development Process a Project Management Technique?

The new product development process (NPD) can be represented as a “funnel” or alternatively as a “vortex” as illustrated in the figure below. A funnel implies a more orderly process; a vortex better represents the chaotic nature of new product development. At the infographictop of the vortex is the universe of product ideas that a company could potentially work on. The ideas have to be screened and prioritized as every company has resource limitations and cannot possibly, nor should they, develop every idea into a product. Once a decision is made to develop the product, then a common approach is to use a “phased development process” with its series of phases and gates to guide the product development.

But is the “phased development process” a project management technique? I believe many who have implemented phased development processes mistakenly believe it is a project management technique. They are lulled into a sense of security believing now all projects will progress flawlessly.

The problem is that no two projects are ever the same. They have varying degrees of risk. Sometimes that risk is strictly variation. Maybe it is foreseeable uncertainty that can be planned for.  At the other end of the spectrum, there are projects with high levels of complexity and/or unforeseeable uncertainty: the infamous “unknown unknowns”, or “unk unks”.  Projects can be an extension of an existing product, or they might involve new technologies to the business and require the development of new skills. They might be new-to-the-world products that break new ground not only from a technology standpoint, but also in terms of the market itself.  On top of all that, you have the variation in the personalities and skill sets of project leaders and teams.  As a result, what works in managing one project may not work for another project.

A phased development process is a framework for managing a portfolio of projects, but not a project management tool per se. You must tailor your project management technique for each project based on the type of project risk you face.  Projects with normal variation and/or foreseeable uncertainty can be managed with the tools most project managers are familiar with. For projects that have high degrees of complexity and/or unforeseeable uncertainty, you must manage them with different techniques.

A related topic is Scrum, a technique for managing software projects. Many in the software industry believe that Scrum replaces a phased development process. Scrum is a project management technique that can be used for highly complex software projects, or for managing the development of the software component on a project that combines both hardware and software. This is the situation today for many companies who develop highly engineered products such as analytical instruments, medical instruments, and other electro-mechanical systems. Scrum is a project management technique that can sit next to other techniques for managing projects, all within the framework of a phased development process.

What do you think?  How do you relate a phased development process with project management techniques? Do you agree with how I have described a phased development process and how it relates to managing projects? Is there a better way to think about this subject?

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!


2 thoughts on “Is a Phased Development Process a Project Management Technique?

  1. Regarding the SCRUM software process, I view it as a complementary process that integrates into the Phase Gate NPD process, but cannot replace it. When developing software, SCRUM techniques fit most naturally within Phase 3, actually Engineering the product. This is where SCRUM, or other Agile development techniques shine. By definition, for SCRUM to work it requires a Product Backlog of software features as a starting point. The point of Phase 2 is to develop this very backlog. Once you exit Phase 3, theoretically that backlog has been completed. SCRUM can be used in the adjacent Phases because nothing is ever so clearly divided: in Phase 2 as initial product backlog features are developed, to discover more requirements that feed into Phase 3; and in Phase 4 as any remaining product backlog features and last minute design changes are implemented. But when you take a holistic approach it’s evident that SCRUM does not naturally fit with Phases 1(what should I build), Phase 5 (shipping the product), or Phase 6 (maintaining the product).

  2. I see this is an older article, yet nonetheless relevant today as the day it was written. Phase Gate processes are decision making tools that allow the executive team or stakeholders to make informed decisions regarding continued investment on a given project. If a project is taking longer and costing more than initially projected, if it is right on target in both cases, or if it is coming in under budget or schedule (or any combination of the above), the end of a phase is meant to analyze schedule and cost actuals versus projected and make the decision to continue funding and resourcing, to reduce, or to cut the project altogether – making room for other projects in the funnel.

    Typically, as mentioned in the article, companies are resource constrained to do everything in the funnel. Therefore, it is incumbent upon the executive team or stakeholder base to make decisions relative to how to allocate their resources. Typically this would be around the projects supporting products that will provide the most value to the organization. These should be what are in the active portfolio. You want to stop those projects that provide less value and consume the resources.

    As you can see, phase gate management is totally about portfolio management. It is not to be used as a disciplinary bludgeoning tool for poorly performing project teams – which it often is. There are other vehicles better suited to address performance.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.