Loading...
Quick Links

Top Five MS Project Scheduling Mistakes

I’ve been covering a variety of MS Project (MSP) tips and guidelines in my last few articles. This time, I thought I’d write about the most common errors found in MSP schedules.

When I started using MSP in 1997, I had to learn it on my own without much guidance. During those early days, I know I made quite a few mistakes creating my project schedules. Even after so many years, I still notice similar mistakes in other project managers’ schedules. I think this happens as many of them, as I did, start using MSP without proper guidance.

I have written this article to dissect five top scheduling mistakes. Most of them have to do with the use of dates in MSP. Dates are essential ingredients of a project schedule. Read on.

 

1. Date Based Planning

A basic project schedule contains tasks and dates. Most new project managers begin to create their project schedule by entering dates manually, but this is problematic. Dates should be automatically derived from tasks and task predecessors. If a task date is manually entered, MSP will not be able to automatically calculate and update the project schedule.

Get out of the mindset of starting with dates, as this defeats the whole purpose of using a scheduling tool in the first place, and a tool, like MSP, should make things easier by automating some of the work.

Even though dates are central to a project schedule, scheduling should center around tasks instead. Start by creating a list of tasks. Then, add estimated durations to each task. Lastly, you should add predecessor(s) to each task. This way MSP will be able to automatically calculate the project dates and update them whenever any predecessor is modified. To read more about the disadvantages of date based planning, check out this article.

 

2. Manually Scheduled Tasks

By default, ‘Task Mode’ of a new task is set as ‘Manually Scheduled’ in MSP. This means that MSP does not automatically calculate or update the dates, duration, and other attributes of a task whenever a predecessor attribute is changed.

Some project managers do not know about ‘Task Mode’ and it’s settings, while some do know that the setting can be changed to ‘Auto Scheduled.’ By changing the mode to ‘Auto Scheduled,’ you don’t have to manually analyze the entire schedule every time a task is modified.

Furthermore, MSP automatically will add a date constraint to tasks when you manually enter a date. The date constraints are sometime very difficult to manage in a large project.

Change the default ‘Task Mode’ to ‘Auto Scheduled’ for all new tasks in a project. To do this, navigate to the project options dialogue by clicking File > Options and selecting the ‘New Tasks Created’ as ‘Auto Scheduled’ under ‘Scheduling options.’ Refer to my previous article for some additional details about auto scheduling.

 

3. Skipping the Baseline

A schedule is not a schedule unless it is baselined. Without a proper baseline, you won’t know what your original dates were, and you will not be able to track the project. I have seen some project managers saving a separate copy of their original schedule thinking that it will suffice. They think that a backup of original schedule is enough for tracking a project, but a baseline is much more than a simple backup. It allows you to compare current plan and actuals against the original schedule.

MSP also allows you to save and compare multiple versions of baselines against each other. You cannot do these things by using a simple backup file. In fact, comparing two schedule files manually is next to impossible. Read my detailed article on how to save and use baselines.

 

4. Not Tracking the Project

What is the use of a plan if you do not follow it and track it regularly?

Depending on the size of your project and organizational guidelines, you should track your project schedule regularly. If you track you project weekly, updating MS Project schedule will be easy and it will take only a few minutes. If you wait to look at your project for a month or more, the tracking will require a couple of hours. My previous article on how to track project scheduling using Actual Dates will help you to understand best practices of this.

 

5. Not Having Milestones

Milestones make project tracking easy. A milestone is a point in time, which is used to monitor and control a project schedule. It is usually a zero duration task with no assignments. In MSP, it acts as check point. Having milestones allows you to quickly and visually check if a project schedule is on track or not. Tracking and reporting becomes much harder without appropriate milestones.

You should ensure that there are enough milestones in your schedule and that they are evenly spread throughout the project. To understand more about milestones and project reporting, click here.

 

Conclusion

MS project is intuitive and easy to understand. In fact, I believe it is the easiest scheduling tool out there, however, I also believe usability is MS Project’s biggest strength as well as it biggest weakness. Most people just open it up and immediately start, which creates a lot of problems at a later date. Novice project managers make umpteen scheduling mistakes, which are not immediately understood. Furthermore, MSP has its quirks. Behind the scenes, some of things are not as straightforward as they seem.

Before you start using MSP, seek proper guidance from an expert. Scheduling, baselining, and tacking go hand in hand. Make sure you fully understand each, lest your project goes haywire. And, keep reading MPUG’s articles! Myself, along with other contributors, are continually working to publish content that covers the nitty gritty of this scheduling tool.

In this article, I’ve listed what I think are the top five scheduling mistakes, but there are many more. What has been your experience so far? Which one of the above, in your opinion, is the most common mistake?

I would love to hear your thoughts in the comments below.

 

Share This Post
16 Comments
  1. Good thoughts, Praveen. Thanks for sharing!

    Reply
  2. Praveen, as the author of textbooks by the title of ‘Forecast Scheduling’ and ‘Forecasting Programs’, I could not agree more with 4 out of your 5 blatant mistakes. The one I do not agree with is: “Skipping the Baseline”.
    After years and years of training people to use the baseline feature properly (i.e. not re-baselining your entire schedule every time you get a change request approved), I have given up on that in most situations. My reasons are: Even after training people until everyone is blue in their face, people still WILL NOT do it. This is partially due to the fact that the re-baseline features in MS Project are very poorly designed. Until they improve, I recommend most clients to simply use one Deadline date to see if their project is still on track: Very clean and simple!
    Only the clients that want to do Earned Value or that have extensive KPIs driven off the baseline fields, will still have to undergo my drilling in baselining and re-baselining!

    Reply
  3. Nice article!
    I would add two more items.
    1) Over use of dependency relationships. While ALL tasks need to have a predecessor and successor relationship, some PMs go overboard. For example, Simple waterfall tasks A – B – C – D. What I’ve seen is that PMs will also link A – C and A – D, and B – D.
    Guidance, keep the task relationships simple.
    2) Over engineering task/resource allocations. For example, Bob needs to work on 3 tasks A, B, and C. Each are 40 hours. Rather than simply scheduling A – B – C and identifying when Bob will complete the total 120 hours of work, PMs will try to schedule A, B, and C to run in parallel by manually manipulating Bob’s allocation on each task. A, 30%, B 50%, and C 20% for example.
    Guidance again is keep the schedule simple. Bob has 120 hours of work to complete. From a schedule perspective, he should be done in about 3 weeks. Let Bob decide which task to work outside the scheduling tool.

    Reply
  4. Nice simple list for beginners!

    I would add a few comments about milestones, which is my favorite one on your list. The first thing I look for when some one hands me a project plan, is to filter for the milestones. It is amazing to me the number of times; I see none or just a few. On many occasions, I have seen just one – Project is Completed at the end of the plan. Also, good task names are important. Most summary tasks and work packages should start with a verb and milestones should start with a noun (for example, Website Design is approved). Also, most summary tasks should start with a verb ending with “ing.” (for example, Setting up website).

    Reply
  5. Manually scheduling/constraining task (2) and not tracking the project (4) are common issues I experience. Project managers fall into the trap of using the schedule as a report tool, rather than a working plan, and this is especially true when tasks are extracted from a common MS Project template for organizational reporting I regularly find teams keeping incomplete tasks in the past “to demonstrate they are past due” and failing to reflect current progress.

    Reply
  6. Very good article, especially for novice users.
    A suggestion for #1 Date Based Planning, identifying key dates, especially deadlines and termination dates, as non-dependent may be necessary. I typically create a separate phase for PM-specific tasks to add milestones for reporting, notification, holidays, etc. as a means to track related events and add my comments,especially for the exposure to risk.

    Reply
  7. Very good article to help people to use MS Projects.
    For those of you who does not give up to teach using baselines, I have a suggestion.
    After baselining a new project, a new baseline is in Prince2 terms only needed after a decision of the Project Board to change the 3 points in the “devils” triangle 1) duration of the project, 2) cost of the project and/or 3) the definition of contents and quality of the result of the project . This decision will be made in a meeting where the PM reports that the projectplanning is not within the agreed tolerances of duration and cost anymore.
    Most users do not know that you can create more than 1 baseline.
    I advise you to always baseline twice in MS Project. After approval of a new project you baseline the project in the standard baseline, but also in baseline1. When a major change in the project by a decision of the Project Board, as described above, is approved, you baseline the project by overriding the standard baseline, but also in baseline2. That will make the standard baseline the “current” baseline, baseline1 the original baseline, baseline 2 the second baseline and so on.
    A project with more than 9 major changes will see that the number of available baselines is limited, but IMHO such a project is at that stage after more than 3 major changes already hopeless anyway.

    Reply
  8. I was taught many years ago that the default Start type on a Task should be Start No Earlier (SNE)

    Reply
  9. Should not the original baseline include true deadlines for items such as non-dependant milestones and phase/project end dates?

    Reply
  10. Hi Kimberly, SNE is a constraint, which is automatically added when enters start date manually.

    Reply
  11. Hi Bill, Baselines should include all milestones.

    Reply
  12. Hi Eric, That is an interesting way of tracking PM tasks.

    Reply
  13. Thank Dale.

    Reply
  14. Hi Eric, Interesting thoughts on Baselines. I believe the problem occurs as most people don’t do their needs analysis properly and create rudimentary schedules. Later they realize that something is amiss and then changes come.

    Reply
  15. Hi Daryl, I have also noticed similar things. These things typically happen when project managers can’t keep things simple. One should tell them to KISS. 🙂

    Reply
  16. Very nice article and it is very important to keep these things in mind. one more thing which i believe is very important is WUD Concept which is used by MS Project. The correlation between work, unit and duration is very important while assigning resources to tasks. I have explained in detail about WUD concept in my blog https://infoheed.com/errors-in-ms-project-infoheed/

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

Thanks for submitting your comment!
You must be logged in to comment.