Why Managers Hate MS-Project

Managers ditch project management tools when they start getting unexpected behaviors. Here’s some things that cause unexpected behaviors and what you can do about them.

Did you hear the Microsoft was making a new Office bundle available? It is designed for specifically for software development planning, including only PowerPoint, Excel, and Project; it’s called MS-Fiction for Managers.



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.

Leveling Issues

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.

Any others spring to mind? Please write me.

3 thoughts on “Why Managers Hate MS-Project”

  1. In full disclosure to my readers, I’d like to point out that responses are heavily filtered based on content; I do this to keep the noise-to-content ratio at a level where I feel a reader gets the most value.

    One of the problems faced with the technical content on this blog is that corporations latch onto a few keywords from an RSS feed and decide that this is a good place for them to put their marketing materials.

    I feel that’s off topic, as this post is about the problems managers have trying to use project management software. Not procuring it.

    One theme seems strong, and while related to cost, it’s actually on the peripheral edge: often expensive packages require you to have expensive plug-ins; so solutions that allow the sharing of data in an affordable manner in out. I think this can be summed up in saying, “Managers that can’t get input from their people, or report status, because the tool is too expensive to put on everyone’s desk is just about as problematic as no tool: failure to communicate becomes an real issue.

    Some companies may prefer a [cheaper] web-based solution, however I, personally, dislike these solutions as they:

    1. Require internet access to access my schedule – some environments don’t have this.
    2. Put my private project in someone else’s hands – violating confidentiality agreements.
    3. Lock me into a subscription based solution – I can’t buy once and be done.
    4. Tie me to a vendor who may raise rates, stop supporting me, hold my data hostage, or not cooperate moving to another product.
    5. Slow me down from native application speed to internet speeds.
  2. Thanks for the post. You helped me solve a problem- I couldn’t get my tasks to link, no matter what constraints I set. The error kept saying it was constraints. It was solved by learning that when a % of the task is complete, it anchors it in time for some reason. So, I removed the amount that was completed, then it linked fine, then readded my % complete. What a bug.

  3. It thinks finish and actual finish are the same, they are not, please show slippages. I need to show in one chart when tasks have started and finished late to plan in glowing red. When this moves a dependent task they need to show slippage in red, make it really obvious that thing are drifting, not on a separate report, not in another view, in the main Gantt, show everyone involved that its failing to the agreed plan and the consequences.

    Project needs to stop trying to think and just do what its told. If a task was due to start on Monday and finish on Wednesday then the little blue bar should be there for Monday to Wednesday. When you update to show it didn’t start until Tuesday then it needs to show Monday as red and the consequent slipped finish to Thursday as red. I want to see performance to plan there on the main plan.

    Am I using it wrong or is it just rubbish?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.