scottberkun.com


PM-Clinic: Week 5 Summary

Topic: Not on time

The Situation

Dear pm-clinic:

I'm on a team of about 30 people that has, over the last year, set several milestone dates and driven the team hard to meet them. For many of these prior milestones, the team goes all out to hit the date, only to have external forces cause a slip in the overall schedule. Now that we're nearing the end game for the product we are again in the situation where we have to ask the team to work longer hours and put in extra effort to meet our deadlines. How can we build a sense of urgency around the dates when we've failed to stick to deadlines in the past?

- Signed, Not on time (NOT)

First steps

Someone has to examine why the schedule keeps getting hit by "external" factors. It's one thing for a schedule to slip, it's another for slips to happen without someone understanding how it happened, and how it can be avoided next time. Without this, management can't be seen as credible. The team won't have any good reason that this current "push" is going to be worth it.

Examining schedule failures

  • How accurate was the team's initial schedule? Where did estimates fail?
  • What risks of the "external" factors that caused the slip could have been identified in advance? or prevented?
  • How much buffer was built into the schedule? What was it used for?
  • How were dates communicated to the team in the past? Were these dates part of a coherent strategy, or simply offered as magic dates?
  • If schedule failures are ignored and swept under the carpet, it's an act of disrespect to anyone that tried really hard to make that date. This will come back to haunt you. It will be increasingly difficult to get teams to believe in schedules.

Justifying dates / Creating urgency

  • Buffer should be stated in the schedule, not hidden. It's also made clear what the buffer will be used for, and why it's the size that it is. If there's no buffer, the team should be informed of this, and be asked to make decisions accordingly.
    The business or strategy consequences of missing the date should be well explained to the team.
  • Explain the costs to the organization and customers if the date is missed.

Leading teams

Good leaders make it easy to follow them. They provide logic for their decisions and encourage feedback on their decisions. In this vein, approach scheduling as a negotiation "Hey team. We need to do X. I know X is hard, but here's the 5 reasons why we have to do it, and have it finished in Y amount of time. Can we deliver on X and Y?". As opposed to "X must be done. Do it now!". The first invites a discussion and involvement, and gives people the logic needed to believe and commit - the later gives them nothing but an order. On larger orgs the discussion may need to start with leads and trickle down, and may require a series of discussions.

Robin pointed out that people need justification for why they should work hard - especially if it's not the first time they've been asked to go into crunch mode on a project. People become understandably jaded when their
chains have been yanked too many times. It's an act of disrespect to keep yanking the same chain, and to get upset when the response gets worse each time. The failure is management (the chain yanker) and not the team (the
yankee).

Cynically speaking, If you yourself, as a PM don't believe in the schedule, and are in a large org, work to understand which other teams will be the long pole, and manage your team around that deadline. Keep your team safe from the full schedule pressure, but don't drive them crazy on a wild schedule goose chase. To paraphrase Robin, when management creates a big game of schedule chicken, a single PM can't fix that, and management gets what they deserve.

References

  • Tom DeMarco's Peopleware references a study he did where teams worked with different deadlines. The teams that had no deadlines actually finished on time moreso than the others did. Peopleware is a great book on the human aspects of software development, and is worth picking up.
  • Scott heard about an experiment with market based scheduling, where everyone on the team anonymously votes on what they think the completion date will be, and this turns out to be more accurate than other methods. He was unable to find any references though.
  • In relation to market based scheduling, Michelle recommended The Wisdom of Crowds: Why the Many Are Smarter Than the Few.

This week's contributors

Neil Enns, Robin Jeffries, Michelle Peterson, Scott Berkun (editor dude)

All content copyright 2005. Scott Berkun. RSS Feed