Wouldn’t it be nice if you were able to consistently create a project schedule that is a realistic timeline for completing a project successfully? Wouldn’t it also be great if you were able to predict the completion of the project as work is finished and before the unforeseen arises? You can! But, this kind of predictability does not come by chance. It requires a bit of effort and attention paid to certain best practices:
Chunking The Work
Most project schedules that are distributed are summary in nature. They show key milestones for project phases and major deliverables. This is perfectly fine for communicating the schedule. However, for these dates to be met, multiple chunks of work (tasks) need to be completed on time.
Every project needs a list of tasks that lead to each milestone’s completion. These tasks need to be detailed enough to identify all the work that has to be accomplished and usually have a duration of a week or less. When tasks are multiple weeks in duration there are probably false assumptions and ambiguities in them that will ultimately reveal themselves as you get into the work. This can cause missed deadlines.
Pure Estimates
By nature most estimates are guesses, susceptible to chance. There is no such thing as exact estimates, but there is such a thing as pure estimates. Pure estimates don’t have any pessimistic padding in them nor do they have any optimistic efficiency. As you can see, this is a very subjective issue. When estimating, you need to be honest with yourself and others to help minimize subjective inaccuracies.
Definitive Dependencies
All tasks have dependencies — for any one task, the previous task has to be completed before it can start. The new task can’t start until the previous task is completed. Usually, when the project is planned these dependencies are definitive. But sometimes, as a project progresses and tasks begin to slip, the dependencies artificially change in an attempt to get the project back on track.
For example, tasks that were scheduled in series (one after the other) when planning the project get altered so they are now scheduled to be completed in parallel (all at the same time). This is not good. Avoid the self-deception of altering the timeline in this way just to produce a better project schedule.
Balanced Resource Loading
A project schedule that has people assigned to work for more than 40 hours a week is a problem. It may work for one or two weeks but after that things will start to slip. When a project schedule is first created it needs to be resource leveled. This is the process that involves assigning or un-assigning people to tasks within a period of time so they are not overloaded with work that they cannot get completed within that period of time. Resource Leveling also involves slipping out and staggering work for an individual so they are not overloaded within a period of time.
After the project starts it needs to be resource leveled over and over. This is because when work on a project begins there is a weekly ebb and flow of some things being completed early and other things being completed late. After a while most of the planned start dates for tasks have shifted a few days/weeks prior to or after their start date. This results in resource over-allocation. If resource leveling is not done after a project starts, there is a good chance future work will not get done on time.
By considering these best practices, you will have the best possible chances of producing and maintaining a project schedule that has hope. And, in the world of projects and lots of uncertainty, hope is what we need most.
For more advice on how to create an effective project schedule, contact a performance improvement company like Systemation. Systemation provides project management professionals with project management training courses to help businesses optimize their performance.