Schedule Game #9: Schedule == Commitment

 

You and I know that the schedule is an estimate. The project schedule is your best guess about when the project team will reach which milestones, and when the project may complete. But a schedule is not a prediction; it is a guess. So when I meet senior managers who want a project team to commit to a schedule, I ask the next two questions:

  • Do you care what the project team delivers?
  • Do you care how good the product is?

We can’t talk reasonably about schedules unless we also talk about the feature set we plan to deliver in that time, and how good the feature set will be at that time. If the people involved aren’t ready to discuss the schedule, the feature set, and the defect levels, then any discussion of schedule being a commitment is premature.

One technique I like to use when senior managers demand a commitment is to provide them confidence levels. “I have a 90% confidence level in Aug 1 as a release date. I have a 100% confidence level in Oct 1 as a release date.” Explaining what has to happen during that time, between the 90% and 100% confidence dates, helps me explain what a commitment to the schedule means to me.

Another technique I like to use is the date-for-a-date discussion. “I can tell you we’ll be able to release in the last half of the year. I can narrow it down to a quarter at this time (and specify a date), and I can narrow it down to a month here (another date), and then will be able to provide you a final release date.

But the best technique I know is to use iterations (2-4 week long iterations). That way, you can release virtually at any time. You know that the contents of each iteration works. You know you’ve implemented the most important requirements first. And it’s ok if management wants to release — because the product is ready. No one needs a commitment from the developers; you need a commitment from the people who decide on the requirements that they are telling you which requirements are needed when.

If someone demands you commit to a date, consider how you’ll organize the project. Try iterations. Or, date-for-a-date. Or, confidence levels with a date estimate. But don’t just commit to a date. That’s inviting Murphy to hang out on your project. You’ll commit to a date, but something will happen and you won’t meet the date.

Submit a Comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>