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

Hosting a Successful Requirements Meeting

Arguably, one of the most important phases of a project — getting everyone on the same page – occurs during the requirements meeting(s). The meeting with staff to develop the project requirements is the culmination of the initial effort to create a project charter, scope, schedule and budget. The work of deciding how to get from nothing to accomplishing project goals happens through the process of the requirements meeting.

Now I am not talking about the “high level requirements” that organizations use to get a project approved (And unfortunately sometimes sent out for bid).  This level of requirements is more for bounding and high level scoping – not useful if you are trying to actually define a set of tasks or detail out the what and how of the project.  High level requirements are great for preparation.

We used to joke – sometimes with more than a smidgen of truth – that the project manager would tell developers to begin coding, while he or she went off to find out the project requirements. However, having been dipped in the sacred waters of the “Guide to the Project Management Body of Knowledge,” we know now that collecting requirements falls under the process of Project Scope Management, as part of developing the Project Management Plan.

Preparing for the Requirements Meeting

Clearly defining the detailed tasks needed to complete modules, add functionality, or build a system begins with the vision of the project’s outcome, tempered by the reality of time and budget. Next, the top-level objectives that drive the requirements are defined through a process that involves all stakeholders – clients, users, senior management, organizational strategist and key project staff.

Assuming that the organization has not already documented the high level requirements, you can use several tools and techniques to gather objectives and top-level requirements. I have found that “scenarios of use” and “use-cases” work best with most stakeholders because they help crystallize vague objectives into understandable activities. Process maps, flow charts and decision trees can be used effectively with developers.

The project manager’s goal in conducting these pre-requirements meetings is to create a coherent list of high-level requirements that will be presented to the development staff to create the detailed project requirements.

Running the Requirements Meeting

First off, let me warn the new project manager that the requirement meeting is rarely a single event. Depending on the size and complexity of the project, multiple meetings should be anticipated. Before the meeting, provide all attendees with the information distilled from the interviews with users, customers and other stakeholders including comments from the scenarios. If your project has a Concept of Operations, that should be added to the pre-meeting review materials.

Break the meeting up logically using either the project work breakdown structure or development modules. Make sure everyone is comfortable, has available linked communications, notepads or sticky notes and a projector, whiteboard or electronic white board to capture ideas and decisions. Then, like Alice in Wonderland, begin at the beginning, continue through to the end, and stop.

Unlike Alice, though, project managers should plan to iterate at least once more through all steps to assess and integrate the impact of later decisions on initial ones. PMBOK suggests applying group process optimization techniques such as facilitation, group decision-making, and breaking up into small groups with timed feedback requirements. The requirement’s meeting is done when everyone understands what the detailed requirement are and how meeting each detailed requirement integrates toward a task and deliverable in the WBS. Developers should have a general idea of how to approach each task and understand the operating environment for both coding and execution. They also know how success will be tested.

Output

The result of the requirement’s meeting is a document, a requirements management plan and a requirement traceability matrix. The requirements document should be dated and versioned, as updates may occur based on change requests or risks realized during execution.  Now you have a baseline of scope for the project!

Conclusion

While no two projects are the same size or complexity, they all have “scope” and requirements as a common element.  You may have to tailor the steps or process to fit your project size, but don’t short change this critical step when doing
a project.  Many a PM has been wounded in battle because they didn’t take the time to get the requirements right!

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

ProjectManagement.com

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

beyondcenter

Pushing the Edges Out ...

projectxpert

Just another WordPress.com site