Project Management Plan - Where to Stop Decomposing Work Break Down Structure?

Jan 10
09:02

2011

Dr. Joseline Edward, PhD

Dr. Joseline Edward, PhD

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

Work Break down (WBS) breaks a project into discrete elements. It’s the basis for project planning. This article shows the rule of thumb for determining how far down WBS should be decomposed to define the scope of the project.

mediaimage

Work Break down (WBS) breaks a project into discrete elements. It’s the basis for project planning. The Guide to the PMBOK define WBS as “a deliverable-oriented grouping of project components that organizes and defines the total scope of the project; work not included in the WBS is outside the scope of the project.” WBS helps project managers to perform scope planning,Project Management Plan - Where to Stop Decomposing Work Break Down Structure? Articles cost estimation, risk analysis and schedule analysis and even more. Decomposition is an important technique used in WBS creation. However, excessive decomposition may lead to more work without adding much value to a project.

Let’s look at a scenario. Let’s say your company is using a COT product to bill your customers. I’m sure you know what a COT product means is. It is a commercial off the shelf product which is ready-made and ready to use for a business. For example, MS Office is a COT product from Microsoft Corporation. The COT product which is used in your department is a unique product and very few software developers and testers available in the market place to perform software development.  Besides your company projection says you have more work to do for next three years, and you need more people. Your boss asked you to develop a project plan to train 25 internal resources within 120 days on this COT product software development to meet the project needs. Below shows few key tasks for this project.

1 COT Training Plan                        

1.1 Project Planning                 

1.1.1 Identify the list of development and Testing candidates

1.1.2 Finalize training approach

1.1.3 Develop a detailed training plan

1.1.4 Develop Case Studies for the team

1.1.5 Complete Environment Setup for the team

1.1.6 Develop a process to review the quality of the developers’ deliverables

1.1.7 Develop a process to review the quality of the testers’ deliverables

1.1.8 Conduct Project Kick off Meeting

1.2 Project Execution

1.2.1 Combined training for both developers and Testers

1.2.1.1 Training topic 1

1.2.1.2 Training topic 2

1.2.2 Specific training for developers

1.2.2.1 Training topic 1

1.2.2.2 Training topic 2

1.2.3 Specific training for testers

1.2.3.1 Training topic 1

1.2.3.2 Training topic 2

1.2.4 Case Study execution

1.2.5 Final Exam

I’m sure different companies use different approach. From an analysis perspective, let’s look at the WBS now. Can you identify something common in all these tasks? If not, let me tell you now. The commonalty is that we can assign each task to an individual or a team, and we can accurately measure the cost associated with a task. You can determine cost using a simple formula. Duration of the task multiplied by number of resources multiplied by dollar amount will bring you the cost of a particular task. This is the rule of thumb which I use when decomposing WBS and hopefully most of the managers use a similar approach for decomposition.