PROJECT PLANS: A Plan to Plan, or Execute?

I've reviewed hundreds of project plans in my career. About 20% of them were well thought-out and assembled. The rest range from middling to truly awful. The reasons why a good percentage were truly awful are legion, but the middling ones are salvagable and share an attribute that, when fixed, propels the plan into the top-tier of usable, complete project documentation.

The difference? Excellent project plans are those that project teams can execute projects from. The rest can be simply categorized as "plans centered around more planning," which are generally useless to executing project teams.

The key to indentifying project documents like this is to examine the language and phrases used througout. Good plans concentrate on operations and execution, not strategy. Strategizing should come before, not during or after execution, so the plan must be explicit it how the project will accomplished as opposed to why it will be done.

For example, if continung statements of need are present, such as "...we need a comprehensive claims processing workflow definition..." or "...it is necessary to get the Business Operations Board to decide which network platform to buy," you're not receiving an operational plan or guidence to execute, you're simply getting strategizing or at worst, wishful thinking.

The project plan is the wrong place to do things like this. It must come well before a project ever gets close to the end of the planning process and into execution. If it doesn't, your project is behind the eight-ball before it even gets out of the gate.

If you're having trouble getting the plan into an operational form executable by the project team, it best to start by answering these questions:

1. Do we know what we're supposed to accomplish?
2. If we know the answer to (1), how are we going to accomplish it?

Excellent plans focus almost exclusively on how, and why or what the project addressed should have been answered well before the plan was put together.