Decomposing Requirements for Tangible Project Outcomes

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

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Cecilia Wong
Vivek Prakash
Cyndee Miller

Recent Posts

Leadership Tips from Entrepreneur and Sports Legend Earvin “Magic” Johnson

Passion and Rigor Drive PMI’s Project of the Year Award Winner

End a Business Relationship and Keep Your Cred

Fair's Fair

Give Your Project a Home

Email Notifications off: Turn on


Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value. 

Many project managers approach the project in a delivery-oriented fashion. They plan for, work against, and monitor and control the project's work through deliverables. Delivery-oriented project managers make the scope's outcome tangible in order to fulfill the project's goals. 

The first step to incorporating this project planning technique is to understand what a "deliverable" is. "Deliverables" are concrete and discrete artifacts of a project's outcome, such as products, functionalities, features, documents and plans. They can be obtained by "decomposing," or breaking down, the project's requirements in smaller, more manageable components. 

As you decompose requirements, keep in mind that you can structure and manage the project deliverables in various ways. Some of the most common approaches for different types of organizations include:

  • Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
  • Spreading deliverables across knowledge areas. Project teams  organized by areas of expertise (such as operations, legal or  finance) usually use this technique in their projects.  
  • Spreading deliverable across processes. This is typical for process-oriented projects.
  • Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole. 
  • Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
As a side note, in agile projects, where teams are action-oriented, the work decomposition is done slightly different. The focus then is on epics, user stories and on the functionality to be delivered.

To decompose requirements effectively, I recommend following these tips:

  1. Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
  2. Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
  3. Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results. 
  4. Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
  5. Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it. 
Focusing mainly and steadily on the "what" is a pragmatic and efficient planning approach as you set up the project.

How do you decompose requirements?

Learn about the basics of project work planning, including the four main steps of planning.

Posted by Marian Haus on: January 18, 2013 04:48 PM | Permalink

Comments

Joe
"Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value. " - I agree with whole-heartedly with this. I think one of the problems many organizations experience is a focusing on delivering a project and not what it is going to contribute to the organization's purpose or goals, and this lack of consideration impacts resource allocations and leads to mis-prioritization in the project portfolio. Having a review process in place, so that proposed projects are vetted by decision makers for their value, is critical to the health of an organization.

Please Login/Register to leave a comment.

ADVERTISEMENTS

Half this game is ninety percent mental.

- Yogi Berra

ADVERTISEMENT

Sponsors

>