Almost every manager I’ve known shakes their fist at project management tools. And while pretty Gantt charts, views of progress reports, and tasks lists appear in presentations, most of it is trickery. That is, all the real work is done by hand on paper or in a spreadsheet, and once figured out, is transcribed to a project tool to product the pretty charts.
What gives?
Project isn’t a drawing tool; it’s supposed to give and track useful information, not get in the way.
Isn’t project management software supposed to let you enter in your task list, assign resources, and produce an optimal schedule?
Well, yes. And, frankly, most people can get past that part. The problems kick in after that point.
Managers ditch project management tools when they start getting unexpected behaviors.
I’ve identified several problems that crop up frequently. Here’s some things to be aware of to help reign in the gremlins that like to scramble your projects.
Loss of Historical Information
If your project tool moves a completed task to a new point in the timeline, then it’s broken. You’ve found a bug. Completing a task anchors it in time.
Mysterious Chronological Task Reordering
When you list tasks, unless you explicitly state otherwise with a direct dependency, the software is allowed to reorder when a task begins. The software you’re using may have a different take on what makes sense.
I often see this problem happen when a time estimate is replaced with a more discrete breakdown of the task. For instance, deleting a 3 day task and replacing it with three 1 day tasks. Because project tools often assume you plan today and do tomorrow, you can sometimes end up with a hole in the schedule you want backfilled and that’s when the trouble starts.
In some cases, the software may decide to move one task from the end of the task list up to the front to fill in the hole; the justification is that it’s better to move one task than shuffle the whole schedule back. This may, or may not, be what you want.
More realistically, if you find tasks being shuffled out of order, the problem has more to do with when a task starts. Some software will force a task to start at a particular date in order to coerce the schedule; the problem is, if you’re unaware it’s done that, and you change some tasks, it might have imposed a schedule requirement upon you that isn’t real. You need to be diligent about such conditions.
Very intelligent schedulers will recognize the difference between a start constraint that you mandated, versus one that it derived.
Around the trouble spots, make sure that the tasks are set to be scheduled as soon as possible, depending on their assigned resources, and not an arbitrary date.
Never Trust Undo
While undo is supposed to put things back the way they were, it can be tricky to get right. Some operations may affect the properties of the tasks on your schedule. When you undo, it might undo what you’ve done, but keep the changes and constraints that it made.
A mature product will implement undo perfectly, but it never hurts to save a historical copy.
Put another way, just because the tasks return to their original positions after an undo, does not mean that new dependencies and criteria were properly cleared from the task properties.
Too Many User Supplied Dependencies
A dependency should only reflect inter-task dependencies, and that means you should use only the minimum required.
If you are using dependencies to force an ordered sequence to tasks that have no relationship, just to get them done in a certain order, you’re doing it wrong.
If you are using dependencies to coerce the software into producing a schedule ordering you want, you’re doing it wrong.
The problem with these two hack-it-til-it-works approaches is that when the schedule changes and you need to re-level it again, some dependencies are real and others are bogus. The software will account for all of them, and that will cause the scheduling algorithms to make bad decisions.