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”)
Fear No Project Blog - Focusing on the Management Side of Projects 