How to Conduct a Product Development Review

Have you ever sat through a two-hour product development review and afterward say, “I don’t know where this product stands. Are we behind schedule or ahead? Are we meeting our customers’ expectations? Are we under budget or over?”

You’re not alone.

New product development reporting is often jam-packed with design concepts, drawings, and test results. This information is helpful background, but it doesn’t provide sufficient insight into the probability of success or when it might happen.

As a capital equipment executive, you live and die by the success of your new product development pipeline. What you’re after is a system of consistent, regular reporting across product development programs that will alert you to issues dealing with:

1. Product launch dates
2. Product performance
3. Product costs
4. Development costs

A consistent, concise, and precise approach to program reviews is required to ensure that you are transparent about the program’s health and any issues.

Program vs. Phase Gate Reviews

Since complex capital equipment products often have very long development cycles, a program can be in a single phase of your phase-gate development process for several months, even years. You cannot maintain control of these programs with phase-gate reviews alone. The time between progress checks is just too long to prevent program entropy. What you need is a regular heartbeat of program reviews.

The phase-gate reviews occur upon phase-gate exits to seek management approval to proceed to the next phase. In these reviews, management reviews all deliverables at that particular phase gate and determines whether the program has met the requirements to exit that particular phase and move on to the next.

On the other hand, program reviews are calendar-based in that they occur at a regular interval independent of phase-gate status. These reviews provide a snapshot of the program’s progress toward its objectives and alert senior management to issues and barriers to success.

Keys to Successful Program Reviews

The regular program review creates the organizational habit of regularly assessing the development program against its objectives. Program reviews serve as the regular update that senior management desires and force the program manager to evaluate the overall program’s condition periodically. For program reviews to be effective, they need to:

• Occur at least monthly to create an organizational habit.
• Follow a consistent format anchored on program performance metrics so that the organization is able to easily evaluate the data being presented and identify changes, issues, and barriers.
• Be regularly attended by senior management to reinforce the seriousness of accurate and complete program reporting and also to drive continuous improvement of the program review process.

Deciding who attends the program review is also essential to the review’s effectiveness. Program reviews should not be an open forum where the whole organization gets a development program update. Doing this would fill the meeting with multiple levels of management and individual contributors, making it impossible for senior management to address sensitive issues or perhaps express dissatisfaction with program management.

To ensure open and frank discussions on tough issues between program and senior management, keep general audience program updates separate from formal program reviews. Program review attendees should include:

• The senior management team members accountable for defining, developing, and delivering new products.
• The program manager plus the few key members of the program’s core team needed to ensure that senior management’s questions will be answered.

What to Include in a Program Review

There are only seven things that a business needs to know about its product development programs to determine whether or not they are on track. They are:

1. Status vs. top product lifecycle (PLC) milestones
2. Status vs. PLC deliverables
3. Status vs. success criteria
4. Status vs. product cost targets
5. Status vs. development cost targets
6. Top issues, risks, and action plan
7. Accomplishments/Goals for last/next month

Design your program reviews in a consistent format around these seven items, and you’ll have a concise and precise status of your program and its key issues.

Status vs. Top PLC Milestones

It seems evident that you need to track program milestones. But the trick is how they get tracked. Executives look at many different programs, so assessing whether a date is on target can be difficult. Your schedule reporting needs to address this. First, the top-level milestones should reflect the critical milestones of your PLC process. Second, track and report three dates for each milestone.

1. Baseline
2. Last report
3. This report

The baseline date is the original commitment set at the program start, and it seldom changes. The second is the date presented in the last review, and the third is the data presented in the current review. By tracking these dates, you always have the answers to these two questions:

1. How have the milestone dates changed since the program was launched?
2. How have the milestone dates changed since the last review?

During a review, it’s essential to poke at the quality of the high-level milestone dates by periodically asking to see the detailed schedule. Also, alarms should go off when near-term milestones keep slipping, but later dates hold firm. When that happens, it’s time to drill down by asking to see a recovery plan. See the figure below for an example template for tracking PLC milestones.

Status vs. PLC Deliverables

A PLC process also describes the cross-functional deliverables for each phase of the process. These deliverables also need to be tracked and reported at a high level. Tracking the cross-functional deliverables reminds the program manager to keep the whole product in view. You’ll find it helpful to create a table of PLC deliverables by phase like the one in the figure below, then color code each cell to indicate the status of each deliverable.

Status vs. Success Criteria

When you first defined the program, you set the new product’s success criteria for performance and cost. You need to include the most important ones in your program reviews. These are usually the ten to fifteen most important buying criteria for the product you’re developing. It is also helpful to break these into two groups for capital equipment products, one for the process performance specifications and a second for the cost of ownership specifications.

Avoid any goals that aren’t specific and measurable. There’s a big difference between defining an objective as “improve throughput” versus “235 units per hour.” The second objective will ensure that management and the program team have a common definition of success.

Create a table that lists the success criteria and target specifications to track progress. Then, create columns for each significant level of testing that your PLC process outlines. See the example shown in the figure below.

As the program progresses, enter the performance achieved into each cell of the table and color code each to indicate overall status. Develop color codes for:

1. Not yet tested
2. Test started—no results yet
3. Test complete—passed
4. Test complete—failed

Status vs. Product Cost Targets

You’ll want to fully understand the cost of goods sold for your new product, the goal for which you should have spelled out at the program launch. The cost of goods sold includes material, labor, warranty, installation, and overhead costs. See the example chart for tracking product cost and gross margin in the figure below.

Note that, during the early stages of a capital equipment development program, it is a challenge to collect reliable data on anything except material costs. That’s not a major issue since the material cost is the most important to understand. It is usually 60–80 percent of the total product cost and a key indicator for warranty costs.

Status vs. Development Cost Targets

Annual development costs for a new capital equipment product can easily top ten million dollars, and that’s why it’s important to track program spending. Develop a chart like the one in the figure below to track periodic program spending versus budget.

Watch for any departures from expected spending rates and demand that your program managers explain why it is different from the budget. Also, don’t assume that underspending is a good sign; it could mean that your program is behind schedule.

Top Issues, Risks, and Action Plan

Have the program manager list the top three to five issues or risks to the program. The risks can be schedule, product cost, product performance, budget, regulatory approval, etc. This step highlights the top issues for management and forces program managers to sort through all of the noise and identify where they should be spending their time.

For each issue or risk, the program manager should indicate:

1. Issue or risk problem statement
2. Action steps
3. Owner(s)
4. Completion date
5. Outlook for success

See the example template in the figure below.

Accomplishments Last/Next Month

This final slide in the program review is the sanity check for whether detailed action planning supports the top-level milestones. Have the program manager list discrete accomplishments and goals for the two-month window surrounding your program review. See the figure below.

You should see last month’s goals checked off as this month’s accomplishments each month. If you don’t, your top-level milestones are likely slipping. Also, make sure that next month’s goals cover what is needed to hit upcoming milestones. For example, if the thirty-day goal states: “Start ordering parts,” and the top-level milestone says: “Ship next week,” there is a significant disconnect.