All over the world, promising projects quickly morph into unmanageable creatures, exceeding budgets and eating up time. In response, the collective finger of blame points to everyone’s favorite excuse: bad planning.
If poor planning is responsible for failure, then it would stand to reason that good planning should be the savior. So many of us believe that “a failure to plan is a plan to fail,” and we grow confident that successful planning leads to successful project delivery.
Most planning is based on a “controls” model that makes it possible to estimate costs and identify the details needed to complete the project. But the granular level of detail that works nicely for accounting or a supply chain or in other contexts is not so good for project managers during execution. Secondly, many plans assume that everything will go according to plan, and that there will be no variation. “Planning for success” is what one manager called it.
The Illusion of Control
Peter Drucker said, “…the word ‘controls’ is not the plural of the word ‘control’”. He’s right. Making a detailed plan doesn’t give real control; it gives the illusion of control. What provides control is having an understanding of the interdependencies of the work and having the flexibility to respond when the real world presents the team with the unexpected.
Planning for control is what we’ve been doing for the last fifty years: driving down to the details, identifying the tasks to accomplish and the resources that will complete them, time phasing them, etc. These complex and comprehensive plans are based on a premise of control: “comparing actual results with desired results and deciding whether to revise objectives or methods of execution.”
This is most people’s idea of control. They watch what happens, compare the events to what was expected, then change things to bring reality into line with their expectations. If too many things fail to match their picture of reality, even if that picture is only in their heads, they must add more detail to the plan. In this way, they can watch all the details (we have software!) and make adjustments when things go
These details are probably important to someone, and they should be. However, when managers have all that detail, it imposes additional complexity and volume on the task of managing delivery. All the minutiae, the various connections and the sheer volume of items involved in projects—and by extension, portfolios—exceed any single manager’s span of control.
Tailored Plans
What’s needed are plans that are built for execution; plans that can be executed. To reduce the complexity and enable action, our plan(s) must be tailored to our span of control. Those plans will then be used to respond to risks, and will drive behavior during execution.
Here are 5 things you can do to boil down the plan to action:
Match the level of detail in the plan to the direct accountability of the person managing it. That means that a typical project execution plan will be no more than 500 elements. That doesn’t mean that your project only has that many elements, you may need sub-projects that are managed by subordinates.
The project plan represents what will be done, not what should be done. Your plan for execution is not a wish list. Hope is a poor strategy for success. What goes in the plan is what you will actually do, not necessarily the standard operating procedure.
Every planned task describes a physical deliverable. Think about your plan in terms of a relay race. What get’s handed off is a baton. Don’t put the steps to make the baton in your plan, that’s what comments are for.
Each task is owned by a person. You won’t have accountability for results unless a person’s name is on the task. Departments or suppliers are not accountable, but people can be.
Finish to Start dependencies only. Again, like the relay racer, defining finish to start task dependencies forces you to clearly define when something is done. This prevents over-processing, a wasteful and time consuming activity.
Planning is only meant to do one thing; enable good execution. It’s a map for your team, not a box to be checked. For getting to your destination fast, the best maps are not the most detailed, but the most directed to your goal. Your project plan should do the same.
