- 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 they even enter 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:
- Unreliable or
- Not the best you can do
This is especially true early in the program.
The Unreliable Schedule
The unreliable schedule is the most common situation.
You’ve seen this movie. The program team presents their first cut product development plan. You, feeling the pressure to get a product to market as fast as possible, react with “Can we go faster?” The program team responds with a more aggressive plan. The cycle continues until all the slack and contingencies have been wrung out.
With no room for error, the one thing you know about this plan is that it is unreliable. The most likely outcome is that 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 where all the contingencies for these possibilities have been 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 is one that considers all the things that can go wrong in the program. To come up with this, 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 pretty sure that it’s not the best that the team could have done.
What To Do
Don’t worry. This isn’t a no-win situation. With a few simple moves, you can be assured to get the best out of your development teams.
First, always manage to an aggressive schedule that that’s thin on contingencies. You want something that comes close to the fastest possible outcome. This creates the schedule-tension necessary to get the most out of the team.
Your decision to go aggressive, means that you’re accepting that the schedule, especially in the early going, is unreliable. So don’t make bet-the-company decisions based on it. If you need 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 understand schedule slip causes and take actions to prevent them in the future.
The original schedule is useful 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.