The Truth About Your Product Development Schedule

Print Friendly, PDF & Email

You fixate on product development schedules. The time it takes to get a product to market is a significant indicator of its commercial success. If you get to market faster, you’ll:

  • Save on development costs
  • Get first mover advantage on your competitors
  • Free up your best engineering talent for the next project.

Your program managers know that the schedule slide had better be in the front of the program review deck. Before entering that program review, they’ve practiced their retort to “Can we pull it in?” a hundred times. If they’re reporting a schedule slip, they’re braced for your disapproval and ready to commit to a recovery plan.

All of this tension on the schedule is healthy. Don’t let up. It makes program managers and engineers alike perform better. Without the tension, the pace of play would slow, and your products would take longer to develop.

But the truth is that the schedule you’re looking at in a product development program review is either:

  1. Unreliable or
  2. Not the best you can do

The Unreliable Schedule

An unreliable schedule is the most common situation.

You’ve seen this movie. The program team presents their first cut product development plan. Feeling the pressure to get a product to market as fast as possible, you react with, “Can we go faster?” The program team responds with a more aggressive plan. The cycle continues until the team has wrung out all the slack and contingencies.

With no room for error, the one thing you know about this plan is that it is unreliable. The most likely outcome is that the program will fail to meet the schedule, the product’s target capabilities, or both. Too many unknowns exist at the start of a program. Such as:

  • New designs and/or technologies may not work the first time
  • Market requirements might change
  • A key supplier could let you down
  • Priorities could change
  • The lead engineer might resign
  • Management objectives could change
  • The competition could make an unexpected move

A schedule with all the contingencies eliminated is simply unreliable.

Your first instinct to fix a schedule reliability problem might be to ask for one in which the team has high confidence. But this too has its problems.

Not The Best You Can Do

A high-confidence schedule considers everything that can go wrong in the program. Here the program team will analyze all the contingencies and then assemble a schedule that accounts for them. When you ask for the high-confidence schedule, you’ll get a near worst-case scenario that removes most of the schedule tension from the program. You know what happens. Every bad thing that could happen won’t. Yet the project will expand to fill the time allotted. So even if the project hits this schedule, you can be sure that it’s not the best that the team could have done.

What To Do

Don’t worry. You can get the best out of your development teams with a few simple moves.

First, always seek an aggressive schedule that’s thin on contingencies. You want something that comes close to the fastest possible outcome. An aggressive schedule creates the schedule tension necessary to get the most out of the team.

Your decision to go aggressive means that you accept that the schedule, especially in the early going, is unreliable. So don’t make bet-the-company decisions based on it. If you need to gauge the range of potential outcomes, look to previously completed programs of similar scope.

Use regular program reviews to monitor milestone performance. When something does go wrong, have the team re-plan with the same aggressiveness as the original schedule. Insist that the team understands schedule slip causes and takes actions to prevent them in the future.

The original schedule is helpful as a future planning reference. However, once you’ve accepted a revised plan, don’t keep flogging the team with the original. Doing so says to the team, “You have failed no matter how well you do on the balance of the program.” You’ll demotivate them just as you need them to kick it into high gear.

It’s also unfair. You knew the “everything goes perfect” plan was unlikely to happen.