5 Steps to Plan the Project Planning

By Marian Haus, PMP

on October 28, 2011 1:15 PM | Permalink | Comments (5) | TrackBacks (0)

There is a saying: "Every minute you spend planning will save you 10 minutes in execution." As a
project manager, I've learned that along with communication and execution, planning is one of the
three key ingredients for project success.

Planning is not just a one-off activity completed in the early stages of a project. Planning is a
process (or rather a group of processes), conducted throughout the project. And like every process,
planning itself requires a plan and a setup, which defines the planning scope, details and
deliverables.

So how do we plan the planning? Here is my five-step approach:

1. Decide on the project management methodology, framework or practice you will use on
the project. Depending on the approach, you might require different planning styles, deliverables,
details or rigor.

You might have to go ahead with a detailed planning process if you will use a waterfall approach.
Conversely, you might have to keep the planning thin if you will use an agile approach, such as
scrum. Or, your planning might be predefined and framed if you have to use your organization's
proprietary methodology.

2. Plan project time for planning. In average, at least 10 percent of management time should be
allocated to project planning.

3. Write down a checklist of all project documents you plan or need to deliver. The list will
mostly depend on your project's complexity, organization and methodology. (More on this in my
next post.)

4. Start planning early and continue planning throughout the project.

Some of the planning documents, such as the high-level schedule or scoping documents, might
have to be kept frozen upon sign-off. Other documents, such as the risk management planning or
rollout planning, will typically require updating as the project progresses.

5. Continuously improve your planning.

Improve planning by communicating the planning outcome with your project team and by collecting
their feedback regarding your planning performance. You can use this feedback for continuous
planning improvement.

As the project progresses, keep a log of your planning issues to track gaps you encounter along the
way. This is the "planning lessons-learned" document that you can also use for continuous
improvement.

What do you think? How do you plan for project planning?

7 Essential Project Planning Documents
By Marian Haus, PMP

on November 8, 2011 12:31 PM | Permalink

Solid project planning is a prerequisite for project success. Poor planning, meanwhile, can lead to
missed deadlines, budget overruns, poor quality deliverables, frustrated project teams and even
project failure.

In my previous post, I offered five steps to assist in planning the project-planning phase. One
of those steps involved preparing planning documents.

To foster a successful planning phase, here are seven planning documents I believe most project
managers will find indispensable. This list certainly might vary depending on the project setup,
project size, complexity and organizational planning guidelines.

1. Project management plan -- This is used as a reference index, encompassing all planning and
project documents.

2. High-level project schedule plan -- This document captures high-level project phases and key
milestones. It is the document most project stakeholders will see or want to see.

3. Project team planning -- This document provides a "who-is-doing-what" view of the project. This
document fosters efficient project execution and effective project communication.

4. Scope plan -- The scope plan documents the project requirements, the agreed scope and the
Requirements Traceability Matrix (RTM) summary.

5. Detailed project work plan -- This keeps track of the activities, work packages, resources,
durations, costs, milestones, project's critical path, etc. It will be an essential document and work
guideline for your core project team.

6. Quality assurance planning -- This document tracks the quality standards your project
deliverables will have to align to. These may typically include product testing approach and tools,
quality policies, quality checklists, deviations definitions, quality metrics, product defect severity
grades, acceptance criteria, cost of poor quality, etc.

7. Risk planning -- This document contains the project risks and the related mitigation plans; as
well as the project opportunities and the related exploiting plans. The importance of this document
is one of the most underestimated in project planning. Be prepared to have a contingency plan in
case something goes wrong or to take advantage of opportunities when they arise.

Start with this checklist when you sit down to plan for your next project-planning phase. Depending
on your project's needs, fine tune the checklist and tailor it by adding and removing planning
assets, determining the planning time frame, the underlying details and rigor.

Revisit this planning exercise, learn from it and enhance it, to continuously improve your project
planning skills.

What project planning documents do you find indispensable?

Building Blocks of Project Work Planning
By Marian Haus, PMP

on January 27, 2012 10:13 AM | Permalink

In my previous posts, I laid out the basics, the framework and the key documents for planning a
project end-to-end. Now it's time to dive deeper.

One of the most essential project planning stages is to establish the grounds for the project work.
Planning and defining the project work starts with defining the "what" of the project.

Before you can begin, you must understand the business needs and identify the project
deliverables and its characteristics. You must set the boundaries of the project by establishing what
the project will and will not deliver, and break down the project work into smaller and more
manageable work units.

The building blocks of project work planning have four main steps:

1. Collect the project requirements

2. Facilitate a requirements workshop
3. Define the project scope
4. Break down the work in small work units
Collecting requirements is the process of understanding the customer needs, the business use-
cases or the required product features and functionality that the project will deliver. It's an
elicitation process, a discovery and analysis endeavor, rather than just a gathering effort.

The requirements elicitation process should be facilitated and not done by yourself. Therefore, do
this. Get the appropriate project stakeholders together. Organize focused requirements workshops.
Interview, brainstorm and job shadow to glean information.

Defining the project scope involves prioritizing the collected requirements, and deciding what's in
and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks
and costs.

The scope covers the project deliverables and all project requirements, along with their detailed
descriptions and the related constraints and assumptions. The scope illustrates the entire work that
the project will carry out, as well as the project boundaries.

The part of the work planning that generates action is the Work Breakdown Structure (WBS). The
WBS enhances the project scope understanding by decomposing the project work and deliverables
into smaller and more manageable work units, also called work packages. The WBS defines
granularly the "whats" of the project.

Do you agree with these steps? How many steps do you use for project work planning?
Use a Framework to Plan Project Requirements
By Marian Haus, PMP

on March 14, 2012 11:24 AM | Permalink

Project requirements are rarely collected and made available in a final form to a project team. Instead,
requirements are often collected through an elicitation process, which involves a discovery, analysis,
understanding and validation endeavor.

Usually, a business or requirements analyst carries out the requirements elicitation process. The project
manager is typically responsible for planning and setting up the requirements elicitation and management
framework.

Well-planned and well-managed project requirements are common characteristics of successful projects.

This simplified framework can be a guiding requirements checklist for project managers:

Organizational assets: Identify the available organizational process assets for planning and managing project
requirements. The organization or project management office might already have standards, guidelines and
templates that can or should be used as a starting point.

Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze
and document the project requirements.

Categories: Identify and categorize the requirements types that are to be elicited, such as:

Project requirements: Business requirements, end-user requirements, functional and non-functional

requirements, etc.
Product requirements: Technical requirements, product features, functional requirements, etc.
Indirect requirements: Overhead imposed by organizational or enterprise environment and standards
related to security, regulations, infrastructure and industry, etc.

Channels: Identify the channels through which requirements will come in, such as business-use cases, focus
groups, requirements workshops, surveys, product introspection, reverse engineering or imposed by the
organization.

Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using
a formal requirements language. Identify the way requirements will be tracked -- through requirement tools,
Word documents or spreadsheets.

Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it
make sense? Is the criteria aligned to the project vision and goals?

Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the
must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and
costs, the project phase, etc.

Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the
requirements posing a risk to the project. Develop risk mitigation, response and tracking plans.

Change management: Establish the criteria for detecting scope creep and basic rules for handling
requirements changes for applying the change management process.

How are you planning and managing your project requirements?

Group Creativity Techniques to Collect Requirements
By
Marian Haus, PMP
on July 13, 2012 3:41 PM | Permalink | Comments (0)

In my previous post, I discussed gathering requirements through a facilitated requirements

workshop, conducted as part of the scoping phase.

A few creative group techniques allow a project manager to get the most out of a requirements
workshop. They include mind mapping, brainstorming, affinity diagram, nominal group technique
and Delphi technique. (A Guide to the Project Management Body of Knowledge (PMBOK Guide)
Chapter 5.1.)

The rigor, the number of applied techniques and the sequence in which these techniques are
applied depend on the project's complexity, the workshop audience and the available time for
gathering and prioritizing requirements.

Nevertheless, the following approach can be constructive and fruitful for collecting project
requirements in a facilitated workshop:

1. Start gathering requirements by using the mind mapping technique.

Start with a topic, an issue or an area that you want to collect requirements for and develop ideas
around it. Group the ideas visually, as a mind map, by writing down each idea and drawing how it
relates to the initial topic. Ideally, you let anyone in the workshop create his or her own mind map.

2. Continue the process with a brainstorming session.

Allow anyone in the workshop to generate an unstructured requirements list for each idea captured
on the mind map. To ensure that the brainstorming remains focused on the initial topic, lay basic
ground rules and let anyone freely generate fresh ideas and requirements on the topic.

3. Use the list of unstructured ideas and requirements to build an affinity diagram, where your
ideas are organized into groups based on their natural relationship. Let anyone in the workshop
participate in organizing the items in the most natural group they can.

4. Identify the most important requirements by applying the nominal group technique. Allow
each member or group in the workshop to identify which requirements are the most important for
him or her. Rank each requirement on the affinity diagram with a priority: low, medium, high or from
one to five. To avoid conflicts, facilitate an anonymous priority appraisal and ranking. Finally, tally
the results and identify the most important requirements.

5. Close the process by running several rounds of independent feedback through the Delphi
technique. Let any individual or group revise the list of requirements. Share an anonymous
outcome from each review round and continue with further rounds, keeping in mind the objective to
reach consensus and convergence.

Which of the group techniques are you using for collecting requirements? How do you apply them
on your projects?