jump to navigation

New Product Introduction (NPI) Transitions June 21, 2012

Posted by Tim Rodgers in Project management, Quality, Supply chain.
Tags: , , , , ,

Whether you’re working on a hardware product or a software release, it’s obviously a good idea to build some prototypes and evaluate the cost, performance, and reliability of the design before offering it for sale. Many organizations follow some kind of formal development lifecycle, which is essentially a structured process with well-defined and documented phases, each phase having a set of activities assigned to different functional groups that are supposed to be completed, and exit criteria that are supposed to be met before moving on to the next phase. Senior management is naturally interested in monitoring the progress of the development project, and it’s convenient to use the transition from one phase to another as a time for a checkpoint meeting.

A checkpoint meeting can be a simple project update, but organizations with a formal lifecycle will claim that a checkpoint is actually a phase gate, meaning that the project team must present evidence that they have completed all the required tasks and satisfied all the exit criteria. If those criteria are not met, the project team cannot move on to the next phase.

Unfortunately the reality for most organizations is that except for some scolding from the senior managers there are typically few consequences for failing to satisfy the requirements of a phase gate. Schedule commitments tend to overwhelm process fidelity. The project team may seek a waiver for some of the exit criteria, either promising to complete them at a later date TBD, or insisting that their project is special and therefore exempt from those “rules.” The quality sticklers who believe in blind adherence to the documented process get mad, and everybody gets a little more cynical about processes in general.

Phase reviews are not just a date on the calendar. Phase transitions are supposed to signal a change in the behavior of the design team and the supporting functional groups. In the world of hardware development one of the most important transitions is from qualifying the design to qualifying the factory production processes. It’s generally a bad idea to make design changes while trying to stabilize the manufacturing line and reduce variability. It may go by different names, but there should be a checkpoint where the project team demonstrates that they have verified that the design meets the committed customer and business requirements. There’s a later checkpoint where the team demonstrates that they have verified that they can manufacture that design at the required level of production units, all of which meet the committed customer and business requirements.

There’s a similar phase transition in the world of software development, specifically for teams that don’t follow an agile/scrum model. It’s often called the functionally-complete checkpoint, where all of the code supporting the required functionality of the software has been checked in and verified. This is an important checkpoint for the software quality team because it doesn’t make sense to run the full suite of system tests beforehand.

Two additional recommendations regarding development lifecycles and phase transitions:

1. Keep it simple. Often the descriptions of phase activities and exit criteria are burdened with a lot of detailed requirements that really aren’t critical to the transition. They are all probably important things that need to happen at some point in the project, but if they’re not truly required to be completed before moving to the next phase, just track them like all other project tasks.

2. I believe in the product development lifecycle because I believe that signaling a change in how the team is supposed to behave is more effective than trying to put all the project tasks on a Gannt chart and track their completion. If the phase transitions are not strictly enforced, then the “checkpoint meeting” is just a project update. Don’t fool yourself that it means anything else.




No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: