Earlier this year I worked with a client to develop an initial Microsoft Project schedule for a cross-functional multi-organizational project. I felt the schedule was adequate – perhaps lacking detail in a few areas, but sufficient for this stage of the project.

The project underwent a day-long phase-gate review, where the technical and project management aspects of the project were evaluated by a panel of subject matter experts. I was unable to attend, but received some unexpected feedback during the day. The chair of the review panel had apparently indicated he thought the schedule might be too detailed, and that it might not provide value to the project.

A little surprised, I was able to arrange to sit next to the panel chair at the evening dinner, where the topic of the schedule naturally came up in conversation. Apparently, the chair had been responsible for the development and maintenance of a schedule on a similar project, and had ended up spending a huge number of hours on the schedule over the course of the project, for little perceived value.

Of course we chatted about why the schedule had consumed so much of his time, and I was able to identify that he had made three common but near-fatal mistakes on his project:

1. He had developed the schedule on his own. Since he was a technically competent individual, the schedule had represented a plausible plan to get the work done, but it had not been the team’s plan. The schedule had therefore required frequent updates to reflect the way the team had wanted to address the project.
2. Since he had not worked with the team to develop the plan/schedule, the team effectively had no agreed-upon approach for getting the project done, and so a lot of on-the-fly planning had occurred. This had created a lot of schedule “churn”, as tasks were added and removed from the schedule every week.
3. He had entered the dates for tasks manually, instead of creating a precedence network that would have calculated most of the dates for him. Consequently, every time the schedule changed, he had had to manually recalculate a large number of dates. This had obviously been time consuming and inefficient.

Fortunately I was able to show that the schedule for the current project had been built using a precedence network, based on information provided by the project team members. I therefore expected the schedule to be refined and updated each week, but I did not expect the update effort to be overly time consuming. Can you say the same about your project? I hope so.

Key Consulting provides project management consulting and Microsoft Project schedule training courses .  If you need help creating a viable, maintainable, schedule, feel free to call us at 1-866-PM-ASSIST, or visit www.consulting.ky