5

Should the structuring of tasks in a WBS be according to vertical "features" of a product or horizontal "aspects" of a product?

For example, say I'm developing warehouse software with 3 modules:

  • Orders
  • Inventory
  • Shipping

And suppose there are two stages of development:

  • Requirements
  • Development
  • Testing

Would it be appropriate to structure the WBS like this?...

 PROJECT
   Orders module
     Requirements
     Development
     Testing
   Inventory
     Requirements
     Development
     Testing
   etc...

Or this?...

 PROJECT
   Requirements
     Orders module
     Inventory module
     Shipping module
   Development
     Orders module
     Inventory module
     Shipping module
   Testing
     etc...

Or does it not matter much?

Or should I be choosing one way or the other based on some particular aspect of the project, and if so, which aspect?

3 Answers 3

5

Your WBS is not a schedule. It is not a breakdown of the how or when, but rather a break down of what. After you have broken your product down to the size that to which you think you can manage, the leaf level serves as your work package, under which actions are identified and then scheduled. But those actions are not part of your WBS; they are part of your schedule.

8
  • Sorry about the question title, I've fixed it up. I accidentally submitted the title of a previous question I was going to ask. Commented Oct 4, 2011 at 11:56
  • 1
    I agree. Stages of development are not a part of WBS. WBS should describe what has to be done, not how you plan doing it. So answer is "neither". Commented Oct 4, 2011 at 11:58
  • Thanks for your advice, but I'm still a bit confused. Are you saying that the WBS should only be describing parts of the product, and not the actions which will be performed in making the parts? That seems contrary to the purpose of a WBS - to measure work. In the example I gave above, "Testing" is a real activity, that would be done by a resources separate from a developer - the tester. Are you saying I shouldn't be listing items like this? Commented Oct 4, 2011 at 12:31
  • 1
    A work package is WHAT you are building (at its leaf level of decomposition), the action is how you will build it, and the schedule is when you will build it. If you answer those three things separately, you should be able to see the difference. Commented Oct 4, 2011 at 12:41
  • 1
    Remember there are other schools of thought on this topic. Examine those, too, and see what works best for you. This is my approach and it works great for me, but you may see another approach that comes across more intuitive to you, in which case do that. Commented Oct 4, 2011 at 13:06
4

If you break your project into requirements, then development, then testing, you won't get feedback on your requirements until development begins, and won't get feedback on the development until testing begins. Nor will you have the option of shipping one component early and starting to get value from it while developing the others.

If you develop using vertical slices you can get feedback more quickly, while the knowledge of how to correct things is still fresh. The bugs will be cheaper to fix while the developers still remember what it was they were working on.

If you can slice up your vertical slices even more finely, you can get feedback even more quickly. This is one of the practices at the heart of Lean and Agile software development.

0

I want to address the "appropriate structure" part of the question.

Either is fine.

What's important is to ensure that all project deliverables are in the WBS. That is, ensure that you follow the "100% rule": All deliverables are in the WBS (each deliverable is in the WBS somewhere once and only once) and if it's not in the WBS, it's not a deliverable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.