Receiving project schedules is nothing new to us. We get them all the time. They can be for a project we are dependent on, have a casual interest in, or are a part of our organizational portfolio of projects. We often take them at face value but should we?

Some schedules can be as sound as your best friend’s promises and others fairy tale in nature; but the reality is you’ll never know just from looking at them. You have to dig a little deeper to discover the truth. Throughout the life cycle of a project there are four factors present in all schedules with integrity. The likelihood of the project’s events following the schedule depends on the degree in which these four factors are present.

1. Responsible Chunking of Work: Most schedules that get distributed are summary in nature. They show the key milestones for project phases, external dependencies, and major deliverables. For these dates to be met, multiple tasks need to be completed on time. If a task list that drives theses milestones is not present then there is little evidence that the milestone dates will be met. If, on the other hand, a task list is present then the next area in question is how detailed the tasks are. If the tasks are about a week or less in duration this is a good sign. If they are multiple weeks in duration this is a bad sign and can lead to missed deadlines.
2. 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 do not have any pessimistic padding in them nor do they have any optimistic efficiency. Judgments in this area are very subjective. Probing questions can be used to understand how tasks were estimated and for determining how pure the estimates are.
3. Definitive Precedence Logic: All tasks have dependencies before them and after them. For any one task something has to be completed before it can start and something can’t start until the previous task is completed. This is formally called precedence logic. There are variations of this logic that can require two tasks to start at the same time and in another case two tasks to finish at the same time. Usually, when the project is planned these dependencies are definitive, but sometimes as a project progresses and milestones 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 when planning the project get altered so they are scheduled to be completed in parallel even though they had to be scheduled in series initially. This is a break from reality and signals a high probability that what is represented in the schedule will not happen.
4. Balanced Resource Loading: 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 often leads to individuals who originally only had two tasks to finish in one week now having three or more. Obviously we are limited to 24 hour days thus the likelihood of that person completing all the work that is assigned to them within that week is slim at best. Resources should not be overloaded as to exceed their work availability in any one week. Doing so will lead to work in the future being delayed, diminishing the integrity of the schedule.

Next time someone hands you a schedule don’t be naive and take it at face value; especially if you are really dependent on things being completed as the schedule says they will be. Ask a few questions, peak under the hood a little, and get a much better idea of the schedules level of integrity.