The Art of Project Management: Planning


Carl Manello

“He who exercises no forethought but makes light of his opponents is sure to be captured by them.” Sun Tzu, military strategist

In this fifth installment of the Art of Project Management series, I’ll address the importance of planning. By planning, I’m not referring to the multi-thousand-line project plan detailed in the most sophisticated of project and portfolio management tools (it’s really not at all about the tool, anyway). Continuing the Art of War metaphor, planning refers to the deliberate and well-conceived approach for framing the plan of attack. Without forethought, Sun Tzu warns, one is destined to be consumed by one’s project.

Many would agree that some level of planning is necessary, and that the planning should be correlated to the size of the initiative. That is to say, a global conversion and consolidation to a single ERP system across multiple countries obviously requires a detailed approach. However, even a small initiative (e.g., a new software release that updates the user interface) requires a plan.

Cited in the Art of War, Ch`en Hao, a general in the Sung dynasty in the early 12th century, quotes the Tso Chuan: “If bees and scorpions carry poison, how much more will a hostile state! Even a puny opponent, then, should not be treated with contempt.”

Often times, especially on smaller projects, we tend to ignore the need for project management rigor. Common complaints sound across many of my clients: “It takes too much time; it’s not necessary; we could do this with our eyes closed; project management just slows us down.” But to paraphrase from Sun Tzu again, in cases where one rushes to deliver without considering a plan, one gathers resources in such a hurry that they may not be well prepared to do the work. Is this why, in some cases, that the most simple projects are seen to fail?  He who approaches a project without forethought, and take its success for granted, may be done in by it.

A project approach—or plan—becomes the backbone around which to build a solid and strong delivery effort.

The importance of the plan is in its capacity to document a tactic. The document provides a formal way to align stakeholders, to enable and manage changes over time and to ensure that the line of attack is complete. A plan can be as simple as a task list. It may be as complex as a fully loaded Microsoft Project plan. Or it could be something in between. However, the plan should address several key components:

  • How much time is needed?
  • What types and number of resources are required?
  • What are the success factors and measures to be used?
  • What are the known risks in moving forward?
  • Are there key dependencies that need to be addressed?
  • Are there finances available to fund the effort?

In some cases, this plan can be addressed in a project charter or statement of work. I am a large fan of detailed project charters. The larger the initiative, the more that the detail can be helpful to align stakeholders on what is important. As for the importance of writing it all down… I’ll just leave you to my thoughts from a somewhat more fanciful author than Sun Tzu.

We must fight the urge to just start doing lest we be “captured” by our own projects, and be comfortable understanding that time spent making the plan is right is valuable. As management guru Peter Drucker notes, “Unless commitment is made, there are only promises and hopes … but no plans.” Project planning requires taking risk. One has to be comfortable taking on the unknown, documenting an approach, and opening the plan to critique, modification, or even outright cancellation. However, once a strong plan is committed to, and the key stakeholders are aligned, it is easier to get down to the details of delivering.

About Carl M. Manello
I am Slalom Consulting's Practice Lead for Delivery Effectiveness. I work to support organizations' capability and delivery maturity -- not just IT organizations -- so that their initiatives run more predictably, efficiently and provide the best results.

2 Responses to The Art of Project Management: Planning

  1. Tony Troup says:

    Nice article Carl. Some issues I see at clients is the in the initial ROM (rough order of magnitude) cost/planning exercise in that they don’t know how to do it well and historically “under estimate” for planning. I approach ROM’s from the perspective of the entire project team I would expect to have (BA, QA, PM, Dev, DBA, infrastructure team, etc.) AND address the tail end of the project as well – support – who will own it and transition to support organization(s). Estimating is critical in either an Agile environment or waterfall, so estimating skills would be something I try to continuously improve.


  2. Pingback: Project Plan Introduction « TAB Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: