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.

Happy Holidays
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 answer, I asked "Has this schedule been leveled?"

I was greeted by blank stares by some, hostility by others. "Adding resources and leveling is too time consuming and complex! It's too hard to make the dates come out right!" they replied hotly.

I asked, "Well, how many people did you assume were going to work on this?" More blank stares. "Well, what's the budget?"

"Ten thousand man-hours," the estimator replied promptly.

"OK, that's five man-years. This project has a deadline one year from notice to proceed. But I can't get five people working on it right away. It will take at least two or three months to ramp up, and a couple of months to ramp down. That means for seven months, I am going to need to burn about twelve hundred hours per month. That's about seven an a half people per month, at the peak. I only have ten people on my team, and we have other projects."

"Can't you use contractors?" they inquired.

"What's the training budget?" Needless to say, there was no training budget.

Climbing Out of the Hole
At least I established that it was a death march right away. If you find out that you have schedule issues early enough, you may have time to recover. I could re-work the schedule, building in all the things that had been left out, assign dummy resources and level it. That would give me an idea how deep a hole I was in.

Anybody got a ladder?