Bill Brantley

Asking about overplanning is a question I like to use in my project classes. Josh picked up on the part about semantics which is my point. The reason for a project is to create a solution to a problem and not the perfect project plan. I was going to use the Eisenhower quote but Josh beat me to it.

A common mistake I see with beginning project managers is they spend a great deal of time trying to account for all eventualities in their project plan. They act as if once the project plan has been completed, it cannot be changed. I believe some of that is due to what they learned in Earned Value Management where you need a baseline so that you can accurately make the calculations. The project plan is a noun, an object that must be preserved in it’s original form.

This is why I say you cannot overplan a project if you think of planning as a verb. You should constantly plan from the beginning of the project until you end the project. It is not possible to account for all possibilities when you start a project so your initial planning should be focused around fully defining the problem that the project will solve and what the customer considers success when you deliver the project solution.

As you execute the project plan, you will constantly refine your budget, schedule, and tasks while maintaining scope (and even scope can change if you are working on an agile project). You will also have to constantly work your risk management plan especially if you have a long time-horizon. Think of it this way: your ultimate goal is to deliver the solution according the success criteria set by the customer. Your planning is your GPS to that destination but you should feel free to “recalculate” to keep you on course toward that successful solution.

But, if you use project planning as Peter so humorously illustrates, you can easily overplan. In that case, project planning is a game of “Gotcha!” in which the project manager and the customer use the project plan as a weapon. The project manager screams “new change request” and demands more money because what the customer wants now isn’t in the requirements.The customer often supplies vague requirements that make it difficult for the contractor to determine what the success criteria is. In this case, project planning is more of a skirmish than a joint effort to collaboratively arrive a satisfactory project result.