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.