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”)

Planning Your Organizational Change

Last week, I talked about the inevitability of change and why project and senior managers face challenges in successful change execution. (Don’t Take Organizational Change for Granted – Manage it) I know that you cannot overcome all problems associated with change. However, planning and communication minimize the discomfort.

The first planning step is deciding where you want the organization to be when the change is complete. This creates both the vision and evaluation criteria. On rare occasions, the resulting change vision rests solely with a leader, more often though the vision comes from discussions with people representing several parts of the organization. After the initial discussions, the successful change requires a project leader, a champion and a small group of committed individuals.

The core team tasked with implementing the change needs to spent time creating a “talking points presentation” about what, why, and how. Talking points are sound bites (Yes, just like the politicians use!). They are not paragraphs of text or pages of process – those come later. In creating the key points you want to communicate, address the reasons people resist change – fear, no perceived need, moving people out of their comfort zone – cover those concerns specifically in the talking points. Remember, just as in politics, change is local.

Consider implementing a rolling change rather than a company-wide alteration of process and tools simultaneously. Although the core actions of the change have the same goals for each part of the organization, the impact and implementation details will vary across departments. If you have the luxury of time and resources, consider beginning the change with test cases or single departments and learn how to improve the implementation process as you go along. I have a theory in change management – “Less is more.”  Don’t try to get everyone to make big changes all at once, rather go for small wins and changes in perception and behavior.

During the initial planning, create an implementation schedule and make sure that employees know that their feedback and suggestions will be integrated, as the change becomes inclusive of the entire company. Add training into the schedule. Include a time for evaluation at each increment or stage and factor in some time for reflection.


Customers and clients do not like surprises, even positive ones. Share the talking points and plans with key customers and stakeholders. Tell them how they will experience the change – sell it. Ask for their input and feedback. Keep the communication personal. Schedule face-to-face meetings; include a presentation at a shareholder’s meeting or in the annual report. Have marketing or business development personnel, customer service staff or business analysts talk with key clients as the organization prepares for change.  I just worked with a small health care company and the CEO was excellent at incorporating the clients and stakeholders into the changes he was making internally.  The result for his company was increased respect and business.

Share successes and challenges with all stakeholders. Celebrate success!

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