Schedule Game #11: The Schedule Tool is Always Right

 

You’ve probably gathered by now that I’m not enamored of project scheduling tools. And since I most often do rolling wave planning, I don’t normally need a scheduling tool. But, here’s another true story.

I was coaching a PM in an organization where the execs only understood the waterfall lifecycle. They thought iterating was a waste of time. And, they expected to see a Gantt chart the first week of the project, that the PM would manage to the chart, and everything would be fine. (I know, this sounds more like Hope is Our Most Important Strategy. But it’s not.) And, inevitably, if the PM had to report that the project was not on track some helpful senior manager would say something like, “Well, it says on the schedule that you’ll be here. What’s wrong with you, that you’re not on schedule?” The execs didn’t understand projects where people had to think and react to what they’d learned.

The PM explained this to me, and I asked some of the execs why they wanted to see a schedule so they could beat up the PM. (Well, I asked a little more nicely.) The execs were accustomed to reports of already-completed work/sales figures/whatever, that reflected what had happened in the past. I explained that the schedule is a guess about how things will happen in the future.

I wish I could tell you that they believed me and everyone lived happily ever after. Nope, these folks had been successful before (they believed), so they wanted their schedule now. I wanted to tell the PM not to do a schedule, but that wasn’t going to fly.

I suggested a rolling wave schedule, where the first few weeks were detailed, and only major milestones laid out till the end of the schedule. The PM would deliver a new and updated schedule with completed tasks and the next rolling wave and updated milestones every month. That worked. The execs still wanted to see the whole schedule laid out, but the PM explained he would be updating the schedule with real dates, and working hard to meet their desired deadline. This way he could show them what had occurred.

The PM had other alternatives too. One was to do yellow-sticky scheduling, and leave the stickies up on his wall until the project was complete. He could have invited the execs in any time to review it. In a less formal, smaller organization, that might have worked. Another alternative is to provide confidence estimates with a schedule.

The problem with the belief that the scheduling tool is always right is that it assumes the estimated schedule is accurate. The problem is that few schedules are accurate. Many are precise — “We’ll release Wednesday, at 3:32 pm” — but not particularly accurate. That’s because the schedule is an estimate. Making it look pretty doesn’t change the fact that the schedule is an estimate and has some margin of error.

This game isn’t the fault of the scheduling tool — the problem is in the belief system of the people who use the tool. As a PM, you’ll need to determine the most effective techniques for scheduling your project and for explaining that schedule to other people. So it’s fine to use a scheduling tool, if that works for you. Just don’t believe it because it happens to make pretty charts.

3 Comments

  1. I’ve had to deal with people like this in the past. My strategy is to give them a schedule up front (as required), but to inflate the time estimates.
    The inflated time estimates do two things. First, it gives the team time to find problems and fix them. The iteration time is in the padding.
    The second thing a padded schedule does is give your team the chance to finish early and look good. I had one clueless executive who consistently told everyone how good my team was because we always brought projects in early. He never did figure out why. :)

    Reply
  2. Many years back a project management instructor who’d done a lot of milspec work told a story about of how PERT was invented as a technique to distract the auditors on a big military project by giving them pretty charts with boxes and arrows to focus on. This kept them from getting in the way of people who were actually doing work.

    Reply
  3. I once had a project that the PM estimated would take six months. I disagreed, but couldn’t back up any numbers, because the organization was completely new to me. So I asked him for all the parameters (experience with technology, timeframe, number of stakeholders, level of detail in requirements) and the tool popped out 10 months as the estimate. After that, the idea that estimates were really only vague guesses was something they had no problem with.

    Reply

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>