The perils of planning

What could be so dangerous about planning, you ask?

Most project managers see planning as the first and most helpful step they can take towards getting their projects off on the right foot.

Yet, in the process of planning, PMs often miss the forest for the trees. Forgetting to re-plan your project, missing the business case, or building a project plan that is too complicated for the effort it is meant to support can doom your plans to failure.

In this blog entry, I’ll talk a bit about each of these risks, and how to avoid them.

The GANTT Chart of Doom
Too often, I come across incredibly complicated project plans, with hundreds of individual tasks and dozens and dozens of interconnected milestones. The resulting “wiring schematic” is impossible to read or interpret by the PM that created it, let alone others who work in different business functions.

Let’s not forget a crucial lesson of the PMBOK: project management is as much about communication as it is anything else. When your project plan becomes huge and unwieldy, you’ve lost a vital communications tool. Your plan has now landed solidly in the project management “silo”, of dubious value to others on your project team.

Furthermore, a plan like this will require more work to keep it up to date in the future (we’ll get to this next). In my experience, an overly complex plan is more likely to be quickly overcome by events, and therefore of little use to anyone as the projects moves ahead.

Don’t get me wrong – there is value in working through the complete set of risks and dependencies – no doubt you’ll realize some you didn’t know existed. And more complicated efforts where the dependencies involve months of lead time and potentially expensive re-work may necessitate this type of planning.

Yet, once you’re done developing your complex plan, it’s important to take a step back and simplify when possible. Ask yourself – is my plan overly complicated for the effort I’m managing? Here are some questions that may help you along –

Am I simply exposing common sense dependencies that the team sees easily, without my help?

It’s important to take into account your team’s capabilities. If you’re building web site similar to a series of previous web sites built for the same customer using the same core team, recognize that there are likely well-understood risks, tasks, and dependencies fully understood by your team. Target your planning for the unique risks and opportunities each project presents.

Have I broken down task responsibilities for resources that are beyond my purview, or in a way that can’t be predicted realistically?

In my experience, if you’re assigning tasks to the person-level beyond a 2 month time range, you’re probably down at a too-low level of detail. Events happening far in the future are less clear than events happening in the near-term – acknowledge that uncertainty. Don’t deceive yourself into thinking you know “the how and who” when you really don’t.

Is a large percentage of the plan dedicated to tasks that lay off the critical path, items that are of low cost, and/or have very low expected variance in either schedule or cost?

It is common sense to focus on the areas that could, with a few small mishaps, put the project vastly over budget or behind schedule. Again, tailor your plan strategically for the maximum impact. This will keep it simple, maintaining it’s usefulness as a communication tool, while keeping your focus on the things that matter.

Hey, Where Did My Plan Go?
Another common mistake amongst new project managers is not realizing that plans must be re-visited frequently as the project unfolds. The fact is, projects never go exactly according to plan, and project managers need to accommodate for that by re-planning often.

The notion that change is unavoidable and therefore must be embraced for project success has practically spawned the newer Agile methodologies all by itself. Note that change can be “good” change – say, your company lands a big new contract that will require a juggling of resources – or a “bad” change – your estimates were optimistic and need to be adjusted. Note that in this latter case, this is not “change” per se, but simply reality happening. Things happen, and project managers must be prepared, with contingency plans if necessary, but at the very least with a revised plan.

As you re-plan, consider the quality of your re-planning data. Now that the project is underway, are you getting high-quality and meaningful data on how things are going? Agile methodologies hold that there is no substitute for real, live, working software. I think it’s worth considering that credo, no matter what industry you work in. Take some time to “manage by walking around” – verify progress reports occasionally and get a feel for how things are unfolding. In doing so, you may discover risks you didn’t know existed, or you may discover your plan needs to be updated, and fast.

Why Are We Here Again?
Finally, as you plan the project, don’t forget the business problem the project is trying to solve. Does it exist? Has it been stated and mutually understood by stakeholders? Do we have an order-of magnitude cost estimate, along with preliminary project approval? Do we understand the “how” of our solution?

It’s easy to forget that according to the PMBOK, planning is not the first phase of a project – project initiation is. Too often, projects get planned in extraordinary detail, only to discover later that the problem is in fact different than the one we thought we were trying to solve. Or maybe our planned approach did not meet our original assumptions – maybe it’s not technically feasible, possibly just too expensive, or takes too long.

It’s important to have the business case in mind not just before planning begins, but throughout the life of the planning process and the rest of the project. As such, your planning efforts may cause the whole project to be re-evaluated. On smaller or more Agile projects, this may be as simple as calling a quick meeting, or on larger projects, a significant process of regulatory-style approval. Either way, the sooner this happens, the better. It’s no fun being 75% through a project, only to realize the business case got missed.

Summary

• Consider applying “necessary and sufficient” principles to your project plan. Build your plan to strategically highlight the areas containing the most schedule or cost risk.
• Planning occurs throughout the whole project lifecycle, not just at the beginning
• Don’t forget the business case – the critical “why” of the project. Just like planning, it must be revisited as often as necessary.
• Finally, remember that the flow of project process is not purely linear – initiation, planning, and execution all happen simultaneously to a degree – informed by the monitoring and control processes you’ve established.