Building Blocks of Project Work Planning

From the Voices on Project Management Blog
by , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog

RSS

Recent Posts

Fair's Fair

Give Your Project a Home

A Hollywood-Style Move From PM to Scrum Master

To Have and To Hold

Leading With Integrity

Email Notifications off: Turn on

Categories: Project Planning


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?

Read more posts from Marian Haus.

Posted by Marian Haus on: January 27, 2012 10:13 AM | Permalink

Comments

Vicki James, PMP, CBAP
I completely agree with the steps, yet have concerns with premise that it is the PM who has sole responsibility for this role. Just as PMs have struggled for years to have the PM profession taken seriously, now business analysts (BAs) are in the same position.

PMs do have responsibility to facilitate planning, execution, and control of requirements processes. However, they should rely on the expertise of a business analyst to conduct the activities.

A PM acting in the BA role compares to acting in the QA or development roles. There may be some projects where combining of roles makes sense, but this should be the exception rather than the rule. A true collaborative relationship between the PM and BA will yield the best results for achieving business value.

The International Institute of Business Analysis has their own BA Body of Knowledge and certification that is on par with PMI's own. The business practices described agree with this article but the processes and tools to support business analysis, requirements, and solution verification are much more in depth. Please visit www.iiba.org for more information.

I look forward to the day when PMs and BAs work collaboratively in establishing and communicating project best practices.

Vicki James, PMP, CBAP
project-pro.us
@VickiPPS


Daniel Beverly
For me, project planning starts with the "why" rather than the "what". It's not the responsibility of the PM to define a project's reason(s) for being; but business drivers, problem to be solved, benefits to be realised, objectives and outcomes are what should drive the project planning process.

Project planning also requires at least an element of technical exploration: proofs of concepts, vertical slices of architecture, targeted work on non-functionals and other high-risk areas. A risk-based architecture-first approach.

And finally, build-in iterations to elaborate and refine these plans. Even at the very outset, planning is not a one-time activity.

Enjoyed the post. Thanks.

Pankaj Pruthi
I agree with the above steps but shall be concerned about the project scope acceptance. Though a facilitated workshop on project scope is a good way, project manager should make sure formal approval on Project scope should be signed off by all stakeholders along with agreement on ways to effectively measuring deliverable s or milestones as project progresses. The agreement on major milestones as project progresses shall also make it easy for project manager to showcase the work-in-progress against the deadlines set by Project schedule later on in the project life cycle.

Please Login/Register to leave a comment.

ADVERTISEMENTS

Cyberspace: A consensual hallucination experienced daily by billions of legitimate operators, in every nation

- William Gibson

ADVERTISEMENT

Sponsors

>