The Importance of Project Planning – PMBOK Chapter 3

OK, it has been a while since I talked about the PMBOK and I wanted to continue a series of posts on PMI PMBOK areas (started with “What is the PMBOK all about”.  This week we look at one of the critical areas that many PMs shortchange in managing projects – planning

“No battle plan survives contact with the enemy” is a bit of wisdom about the world alternately attributed to Helmuth von Moltke the Elder, Erwin Rommel, Carl von Clausewitz, Colin Powell and Murphy’s Laws of War. Yet, military leaders continue to develop plans for every imaginable contingency. If plans are destined to fail in the real world, why should we as project managers bother with planning?

Plans rarely fail entirely. Rather, details of a plan require changes as factors outside the control of the PM require responses that deviate from the original plan. However, a project plan provides a roadmap of key destinations (milestones) and a timeline to reach those locations, even when detours become necessary.

Of course, the PMBOK addresses project planning in detail beginning in Section 3.4. It suggests that a project plan encompass:

  • Scope
  • Activities
  • Resources
  • Schedule
  • Quality assurance
  • Risk analysis

In the discussion, PMBOK acknowledges that, “as more information is gathered and understood – which is their way of saying contact with the enemy — additional planning may be required.”

Types of Plans
Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

  • Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
  • Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
  • Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan
Here are a few tips to help you make a better project plan:

  • Cover all the bases listed in PMBOK
  • Clearly defines the scope of the project
  • Show dependencies between tasks as part of risk management
  • Comprehend resource loading and realistic levels of effort
  • Reflect awareness of project risks and allow time to understand and mitigate them
  • Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
  • Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
  • Help developers, team leaders and users understand the project and their role in its success
  • Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)

How to create and use predictive project scheduling

I was a bit naïve when I accepted the challenge to manage my first software project. I didn’t quite understand the “wink-wink, nod-nod” I got from the software veterans when I began asking for their input to the project task detail and schedule. Now many years and many projects later, I understand their skepticism. They had too often been victims of schedules that were not worth the paper or time used to develop them. They had seen schedule chicken played by professionals and had worked countless hours of overtime trying to meet unrealistic, unattainable deadlines.

However, I continue to believe whole-heartedly in the value of predictive schedules. To me, a predictive schedule is one that accurately reflects what has happened in the past and is a good predictor of the future.  It gives a believable prediction of the project end date and an accurate level of effort estimate to completion.

What are the necessary pre-conditions for a useful predictive schedule?

Let me tackle the most challenging requirement first—corporate or organizational culture. If your company has a “shoot the messenger” ethic, then predictive scheduling is doomed! Like a military plan, the initial project schedule rarely survives contact with the enemy. Staff changes, requirements creep, and vendors miss shipment deadlines.  Your project schedule must be detailed enough to identify potential problems and dynamic enough that you can reforecast to accommodate the real world. AND, senior managers need to be willing to hear the impact of changes on the project schedule.

For predictive scheduling to be useful, there must be trust on all sides of the equation:

  • As project manager, you do the best you can to create an accurate and meaningful schedule of tasks with an estimated level of effort (LOE).
  • Developers and team members work hard to meet schedule requirements and accurately record their time to each task as well as update estimate to complete (ETC).
  • Management trusts that everyone involved is doing their best and reporting accurately.  They provide support when needed.

What content is required for a useful predictive schedule?

Developing a predictive schedule is a top down and a bottom up process. You must start with the top level vision and goals for the project to set expectations and scope.  Then each deliverable is broken down into tasks that require no more than one or two week’s time to complete (that task may include the effort of several people or it may require less than the full-time effort of one developer). The point is that you need to be able to assess the project’s status weekly.

Now we come to the one of the most powerful features of predictive scheduling—task dependencies. Your schedule must show these dependencies. What must be completed before “Task X” can begin (predecessors) and what tasks depend on the successful completion of Task X (successors). Getting the task dependencies correct is 50% of the requirement for creating a useful predictive schedule.

The other 50% is estimating the effort really required to complete the task successfully. As project manager, you will want the input of others on the project to define tasks, dependencies, and effort. Then, you have to make a judgment on their input. First, you need to make sure that there is enough detail so that the schedule can document the project status and second, you will likely need to adjust the estimated level of effort (LOE).

Why do I believe that the initial effort submitted by developers will need to be adjusted? Developers and other team members often make errors of omission and commission in defining LOE for a task. (Dan Mitchell offers some insight into what may be left out of developer’s estimates on his Software Developer’s Guidebook blog). Some may be too optimistic—assuming all of their time will be dedicated to writing code when in reality the schedule needs to include time spent in meetings, unit testing, and working with temperamental hardware and software. Or, they may assume that the level of productivity is the same for all developers or IT staff, when the truth is that some developers are significantly more productive than others (usually based on experience or skill).

Finally, either through misplaced self preservation instinct or lack of knowledge, developers may over-estimate LOE believing that if the estimate is cut during its migration through senior management reviews, they will still be able to get the work done because they padded their initial estimate.  So you, the PM, must assess the estimates and try to get them to be as accurate as possible!  No one said this was easy.

What benefits does a project manager receive from a real predictive schedule?

  • Ammunition to define and defend resources needed to be successful
  • Knowledge of project status with sufficient time to avert disasters
  • The ability to answer status and planning questions from senior management
  • A final project that predicts cost and schedule throughout the project’s life

One last thought: predictive scheduling tells a PM what he or she needs to know, not what they may want to hear.

Please comment and share your thoughts on predictive schedules.


(If you want more on why you need predictive schedule check out the earlier post at

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site