Carl Chatfield: Top 10 Problems, #1: Forget that the schedule is not the project

Carl here. ProjHugger is for Microsoft Office Project newbies, enthusiasts, and zealots. I publish new posts every Monday morning, but you can add comments any time. This week’s ProjHugger post continues the “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain” series, which started like this: #10, #9, #8, #7, #6, #5, #4, #3, and #2.

Problem #1: Forget that the schedule is not the project

You're a project manager who's invested thousands of hours building and maintaining a complex project plan. Sometimes the smartest thing to do is to just throw away the plan.

On a Journey of a Thousand Steps, the First Step is the Most Dangerous

It's a peculiar truth that at the time you're building a plan for an upcoming project, you can say with 100% certainty that over the entire project's duration, right at that up-front planning stage you absolutely, positively have the least accurate information about the project. How can this be so?

Think about it: as soon a planning ends and execution begins, you start learning all kinds of things. You learn more about the nature of the work being performed. You learn more about the real capabilities of your resources. You begin to see that some assumptions you had to make in planning were just plain wrong. As more time passes, you may see some external issues come into greater clarity--issues in the white space beyond your Gantt Chart, if you will.

By now you may be thinking, "Well of course this is how it works. That's why we're so rigorous in our planning: metrics-based estimates; top-down and bottom-up rigor; leave no stone unturned." All well and good. But for complex knowledge work projects, it may do us some good to acknowledge that as a predictive tool schedule planning is by its nature far less than 100% accurate. Is it 90% accurate? 50%? 20%? There likely have been real projects where all these values proved to be true.

Continue reading at projhugger.