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?

jonathanconway
  • 605
  • 5
  • 13

3 Answers3

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.

David Espina
  • 37,143
  • 4
  • 34
  • 91
  • Sorry about the question title, I've fixed it up. I accidentally submitted the title of a previous question I was going to ask. – jonathanconway Oct 04 '11 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". – Bartosz Rakowski Oct 04 '11 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? – jonathanconway Oct 04 '11 at 12:31
  • Also I'm not clear what's meant by "actions are not part of your WBS". What is the exact difference between a "work package" and an "action"? They seem to be similar terms. What do I need "actions" for, and why are they part of the "schedule"? And what "schedule" are you referring to? The GANTT chart? Sorry for all the questions, I just find this whole subject confusing. – jonathanconway Oct 04 '11 at 12:33
  • There are several schools of thought on this so you will find someone who opines differently than me. Unless the service is explicitly part of the scope, I would NOT have it as part of my WBS. The most you will see in my WBS are PM-related activities that are largely LOE or apportioned. You do measure your activities, which are in your schedule, but your WBS is not a schedule nor in your schedule. – David Espina Oct 04 '11 at 12:36
  • 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. – David Espina Oct 04 '11 at 12:41
  • Thanks David, I'm beginning to see the major error in my understanding. From what you've said, it looks like I should get rid of 'development', 'testing', etc, and focus on the modules of the system requiring development, and hierarchically order them. – jonathanconway Oct 04 '11 at 12:51
  • 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. – David Espina Oct 04 '11 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.

Lunivore
  • 7,123
  • 1
  • 22
  • 40
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.

Gary Curzi
  • 91
  • 3