On Project Scheduling – The Troubles with Timing

In recent days, I've been involved in a number of discussions both internal and external to dotProject concerning Project Scheduling. The questions range from “how do I do it” to “how do I handle tasks being put on hold indefinitely and represent them properly on a Gantt chart?” Yes, they completely run the gamut. Today, I'm going to start a dialog about one of them.

What does it take to schedule a task?

At first glance, this is an easy one. You need to know a) how long the task is and b) either it's target start or end date. By knowing either the start or end date and the duration, you can calculate the other date. Or can you? Let's start simple…

We have a task estimated to take 12 hours and should start on Monday. Assuming an eight hour workday (9am-5pm, 1 hour for lunch), it should be done at approximately noon on Tuesday.

Well, we all know that we rarely get a full eight hours of work between meetings, phone calls, email, small talk, debugging, etc. So let's make the conservative assumption that 2 hours/day is spent on these things, leaving us with 6 hours/day of actual real working time. Our new completion time? Close of business on Tuesday. We just lost a half day.

But wait, this is assuming our estimate was accurate. Those of you who are consistently accurate in your estimates, you can skip this part. 😉 What happens if someone consistently underestimates their tasks? If you don't have a handle on how much this estimate is off, you'll run into new problems. For simplicity's sake, let's assume you've implemented a simple metric like the Monte Carlo modeling detailed by Joel Spolsky recently. You now know that this developer's estimates are consistently low by 10%. Our original completion date of noon on Tuesday has just shifted to mid-morning on Wednesday.

But of course, this third completion date is built on three fundamental assumptions we've ignored so far: First, we haven't considered the impact of other projects. Once we begin to consider other projects, the complexity increases quite a bit. Years ago, I worked with an incredibly sharp senior developer who was assigned eight projects. Despite numerous attempts to get priorities on any of them, he was told they were all “equal”. So the next day, he brought in a little timer which he set to one hour. When the timer went off, he switched to the next project and reset it.

The second assumption is holidays. Here in the US, the safe bet is to remove US Federal holidays – essentially the same as Christian holidays – from the planning, but elsewhere it's not quite as simple. Add in another religion or two or teams in other countries and the complexity begins to get daunting without even considering the vacation aspects.

Third, we have always put this on a single person. Depending on how the multiple people must interact, this may be a simple workflow to cross-person dependencies.

Keith, so what's the point?

The point is that this is the fundamental problem we're trying to solve in dotProject. We've already acknowledged some of the points and address the difference between “working hours” and “hours available”. I know we can address the estimation-error aspects as I've been doing it within CaseySoftware already. I believe we can address the holiday aspects once we flesh out some of the work already done within the community. The multi-assignee aspect still needs discussion and understanding. Regardless, I have yet to see a system which can successfully handle all these aspects. If you find one, please let me know: keith [at] caseysoftware.com