The Tyranny of Dates

The biggest problem I have with project planning software -- especially Microsoft Project -- is the date fields.

Microsoft Project (and other products) allow you to define a task, giving it a name and other attributes. You can specify precedent and dependent tasks, you can specify a duration, and you can assign people.

Project "helpfully" fills in the start date and end date for the task. For any task, there will be defined start and end dates. In this there is no question, no choice, no alternative.

My problem is that I don't work that way. Here's how I put together a project plan:

First I agree with the team on the objective. Then we list the major tasks -- the ones that we can list. We recognize that we will miss a few, depending on the project.

After agreeing on the tasks, we put them in sequence. We identify the dependencies.

Then we look at the effort for each one, estimating the duration of each task.

Finally with put dates in, which gives us our first draft of the project plan.

Sometimes this process is fast, and a single meeting can suffice. Sometimes this process takes weeks.

But until we get to the last phase, I don't want to see dates. Yet Microsoft Project insists on them. If we don't specify a date, it puts in some arbitrary value like January 1, 1980.

Microsoft Project has the notion of dates, but not null dates. Its as if the project manager configured the team with a 'ADD COLUMN START_DATE NONNULL, END_DATE NONNULL' script.

Worse, Project insists on precise dates. It accepts a specific date (and time, which can be deduced by scheduling some tasks for less than a ful 8-hour day). This is not how we handle our planning.

We need a date field that accepts the value "no date specified". We need a duration field that accepts the value "10 days, with a 20 percent chance of over or under by 2 days".

Using an arbitrary precise date or duration is not good enough. In fact, I consider it dangerous. Why not just plug in the value of 10 days? Because Project renders it as 10 days, and I have no way to indicate that it is a fuzzy value. I also want to look at the best case and worst case for all of the tasks, something that requires regeneration of the project schedule.

But the most dangerous thing about this behavior is that we have to bend to the software. We have to change our process to conform to software designed by someone else, probably someone who does not run projects.

I want software and computers to work for us, not the other way around.