I have reviewed a lot of schedules, mostly MPPs. Here are the top 5 common errors I’ve found:
#5 Tasks are all around the schedule – a readability issue
The first expectation I’ve from schedules is that it needs to be readable. So take sometime to ensure your tasks are properly indented. Don’t brain-dump your tasks in a sequential order of occurence. A schedule is not a to-do list. It is a client facing artifact. So give it a professional look. If you are worried about finding your way through the maze you’ve created – don’t worry, the gantt chart will point you in the right direction. Okay?
#4 Bloated tasks = Overburdened resources
A bloated task is a task that can be broken down to many more tasks. When a task is not specific enough and represents multiple activities, you end up assigning such tasks to multiple resources thus overburdening them because it is not clear from your schedule “who does what”. As a rule, I always try not to associate more than 1 name to 1 task. If you follow this rule, 9 out of 10 times, your schedule will be more detailed. Try it.
#3 No critical path
Earlier, I compared your schedule to a maze. It’s true. Before you know it, it will look really complicated like a maze and one can easily get lost in it but not you, right? You are the architect. You designed the maze. So, you should know your way out. You should know the critical path leading to the exit sign. Right? But you don’t! So, next time start with listing out the tasks which are critical for success, the time estimates for each, the dependencies between them and build you schedule around it. Don’t get lost in your own maze. It’s embarassing.
#2 No exception handling
Before I talk about this one, note that “exception handling” is not a project scheduling terminology and so I advice you not to use it much in this context. However, we all understand what it means especially when we all (atleast most of us) are from a development background, or so I assume. Anyway, the issue I’ve seen with schedules is that there is a lack of planning. You’ve to be realistic in your planning. Let us take review activies for example – be it testing, artifact reviews, client sign-offs, etc. – you know these are activites that take time. You can’t simply plan for the best case scenario and leave the rest to chance or hope or God. You won’t get away with it. So think real. Think about exceptions, risks, delays, etc. – everything that can cause your plan to go for a sixer… and btw a sixer is a cricket terminology.
#1 What schedule?
Exactly. The top scheduling mistake is that there is no schedule. Instead, I get an activity list which looks like a consolidated to-do list for the team. A schedule needs to have milestones. It needs to reflect your planning and detailed like a blueprint. It should give an insight into your execution strategy. It needs to show that you have resources allocated to tasks who are not over-allocated and are levelled. It should even factor in the holidays and leaves. Without these basic ingredients, it is a good as saying you don’t have a schedule. Please remember that a schedule is your control panel and you must see the value in it. So, go back to basics and create a “schedule”.
Thank you for listening.
Did this post ignite a thought? Join us and mirror your thoughts on the 13apples facebook fan page.
Great post Raj,
I work very hard to write detailed schedules for big projects at CoLab, and these errors will be great to have in mind when the next one comes around. Do you suggest taking time each time each day to use these principles on much smaller scales? (i.e. one day at a time)
Hope you’re doing well!
Sarah
Doing well, Sarah. Thanks for your comment. Glad you liked the post.
To answer your question: I suggest that #5 and #4 be done each time your make a schedule as a basic rule. To some extent #3 as well but learning how to build a schedule around the critical path may take time. So the more you do it, the better you become. #2 and #1 comes only with experience. Just be cognizant of them.
Thanks,
Raj