Scheduling a project can become a comedy of errors if you don't remember to plug in all the necessary pieces. In this week's column, Peter Clark takes us to a project kick-off meeting and shows us how to spot several common mistakes people make when creating project schedules.
I have been to dozens of project kick-off meetings, and I see the same mistakes, over and over again. This one meeting I'll use as an example was no different than the rest. Sales was going over the "plan"--a Microsoft Project Gant chart. Immediately, I had some questions.
Milestones are a Must
"What is the contractually mandated approval cycle for all submittals?" I queried.
"The contract doesn't specify any time limits," replied the sales team.
The schedule doesn't show any milestones for submittal approvals. All the work is tied to the creation of the submittal, not to the approval. This is unrealistic--approvals can take anywhere from a day to a year. Put in a task following each contractually required submittal called "customer review," with a duration of one week. Put in a milestone following the task called "customer approval."
We continued to creep through the rest of the schedule. I flipped ahead. There was time indicated for testing, both in-house and by the customer. There wasn't enough time for in-house testing, and too much time allotted for customer testing.
Fix What You Find
"Where's the re-work?" I asked.
"Huh?" the sales team replied looking confused.
"Following testing, you can expect to find defects--that's why they put erasers on pencils. You show the testing, but you show no time close defects discovered during the testing, nor do you show time for re-testing the 'fixed' system."
The sales team, looking perplexed, answered, "Uh, we assumed that you would fix the defects as you found them."
"Bad assumption. We're probably going to find defects right up to the last day. Some of them we can punch-list, but we are going to have to fix some of them. It takes, on average, eight hours to fix a defect, and another four hours to regression test it. We're going to want to do all of our regression testing at the end, following at least one week of just defect remediation."
"But that will add at least two weeks to the schedule!" they cried.
"Probably more like three," I responded matter o' factly, "How much slack do you have in the schedule?"
"The customer really beat us up on schedule. It's really tight, but we think that it's do-able."
I was seized by an overwhelming sense of dread. I brought up the schedule on my laptop and added the "Free Float" column. Almost every task had zero free float.
Zero Free Float is a Dead End Path
"Almost every task is critical!" I exclaimed.
"No, we did a critical path analysis, see the red bars," the sales team retorted, pointing at the computer screen
"When every task has zero free float, Microsoft Project has to pick something as the critical path. Unless there are a substantial number of tasks with free float, critical path analysis is practically meaningless," I explained.
I noticed that the schedule showed us making a key delivery on 12/25. I checked the project calendar, and sure enough none of the company holidays were blacked out.
"I know you think that we will be working on Christmas, but do you think that there will really be anybody there at the customer's facility to receive this?"
Our company had ten paid holidays per year. Because of the lack of float, adding these days in would push the schedule. Not blacking out these days in would mean that we would have to pay overtime, and take the hit to morale and employee retention.
Rounding Up Resources
I sneaked a peak in the Resource Name column. There were no resources identified. Already knowing the