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.
Eric Uyttewaal
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!
Daryl Deffler
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.
Ronald Smith
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).
Kimberly Anne Johnson
I was taught many years ago that the default Start type on a Task should be Start No Earlier (SNE)