WBS BEST PRACTICES

[CHANGING FAIL OVER CLUSTER TO NLB]

Hello:

Wondering whether anyone can show me a good, relevant link that shows the
best practices for creating a WBS (sort of a model template) which would also
define what each of the levels inside the WBS are typically used for.

Will appreciate your early response. Thanks.

Regards,

Victor

 

[Rod Gill]

Personally I never use a WBS, ever. I start with a break down of all the
deliverables then I add Summary tasks and sub-tasks that show how I will
complete those deliverables. The structure is dependant on the deliverables
and how they will be delivered. In my mind, WBS is way too focussed on tasks
when the main focus must always be on business deliverables. As long as
everyone reading your Gantt Chart can see what has to be delivered and how
then the structure is not important. Providing a clear communication of how
the project will be delivered successfully is.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more


"CHANGING FAIL OVER CLUSTER TO NLB"

 

[Brian Kennemer]

Personally I never use a WBS, ever. I start with a break down of all
the deliverables then I add Summary tasks and sub-tasks that show how
I will complete those deliverables. The structure is dependant on the
deliverables and how they will be delivered. In my mind, WBS is way
too focussed on tasks when the main focus must always be on business
deliverables. As long as everyone reading your Gantt Chart can see
what has to be delivered and how then the structure is not important.
Providing a clear communication of how the project will be delivered
successfully is.

But isn't what you are doing really just a work breakdown structure
derived via a bottom-up approach rather than the more commong top-down
approach? To me what you describe is the exact way a bottom-up WBS
should be done with the flip side top-down being done exactly backwards
from your method. Look at the larger deliverable of the project itself
and then break it down into smaller and smaller sub-deliverables until
the deliverable level you get to is small enough to be done by a person
in under about 40 hours.

Also, in my mind any WBS or project schedule for that matter that is
put together in a way that has tasks that do not 'deliver' anything (as
you mention above as your objection to WBS structures) then that
project has HUGE problems because it has tasks that are not delivering
anything. THAT is a big, big problem.

 

[Rod Gill]

Hi Brian,

My focus is solely on what's needed to complete deliverables that in turn
must all be directly relevant to business needs. When I come across people
focussing heavily on WBS I too often find them stuck in details rather than
staying head above the water concentrating on business needs. What I do is
definitely top down, usually iterative (so I don't do a complete wbs in
iteration 1 anyway) and as much as possible all tasks are couched in
terminology and phrases used in the business case and relevant to business
stakeholders. It isn't a big difference reading the description but it
execution and focus it is very different.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more

Personally I never use a WBS, ever. I start with a break down of all
the deliverables then I add Summary tasks and sub-tasks that show how
I will complete those deliverables. The structure is dependant on the
deliverables and how they will be delivered. In my mind, WBS is way
too focussed on tasks when the main focus must always be on business
deliverables. As long as everyone reading your Gantt Chart can see
what has to be delivered and how then the structure is not important.
Providing a clear communication of how the project will be delivered
successfully is.

But isn't what you are doing really just a work breakdown structure
derived via a bottom-up approach rather than the more commong top-down
approach? To me what you describe is the exact way a bottom-up WBS
should be done with the flip side top-down being done exactly backwards
from your method. Look at the larger deliverable of the project itself
and then break it down into smaller and smaller sub-deliverables until
the deliverable level you get to is small enough to be done by a person
in under about 40 hours.

Also, in my mind any WBS or project schedule for that matter that is
put together in a way that has tasks that do not 'deliver' anything (as
you mention above as your objection to WBS structures) then that
project has HUGE problems because it has tasks that are not delivering
anything. THAT is a big, big problem.

--

Brian Kennemer
microsoft consulting services
brian[period]kennemer[the "at" symbol]microsoft[period]com

 

[Brian Kennemer]

Hi Brian,

My focus is solely on what's needed to complete deliverables that in
turn must all be directly relevant to business needs. When I come
across people focussing heavily on WBS I too often find them stuck in
details rather than staying head above the water concentrating on
business needs. What I do is definitely top down, usually iterative
(so I don't do a complete wbs in iteration 1 anyway) and as much as
possible all tasks are couched in terminology and phrases used in the
business case and relevant to business stakeholders. It isn't a big
difference reading the description but it execution and focus it is
very different.

OK. Your comment about starting with the deliverables and then grouping
them into summary tasks sounded a bit like bottom-up but I see what you
mean.

To me this still sounds very much like a proper WBS if you think of the
W as "WORK leading toward the delivery of something." I cannot imagine
a WBS that had elements in it that were not based on a deliverable of
somekind. Im having trouble imagining a task that did not deliver
something or at least get you closer to the delivery of something.

 

[Rod Gill]

WBS focuses on smaller and smaller tasks. I focus on smaller and smaller
deliverables and collaborate with the stakeholders invoiced. It sounds like
a small difference, but the execution can be quite different, especially
when the focus is not just on the deliverable but on what the stakeholder
needs to realise the added required value over the expected life of the
product and minimising the support costs over the same time once the project
ends.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more

Hi Brian,

My focus is solely on what's needed to complete deliverables that in
turn must all be directly relevant to business needs. When I come
across people focussing heavily on WBS I too often find them stuck in
details rather than staying head above the water concentrating on
business needs. What I do is definitely top down, usually iterative
(so I don't do a complete wbs in iteration 1 anyway) and as much as
possible all tasks are couched in terminology and phrases used in the
business case and relevant to business stakeholders. It isn't a big
difference reading the description but it execution and focus it is
very different.

OK. Your comment about starting with the deliverables and then grouping
them into summary tasks sounded a bit like bottom-up but I see what you
mean.

To me this still sounds very much like a proper WBS if you think of the
W as "WORK leading toward the delivery of something." I cannot imagine
a WBS that had elements in it that were not based on a deliverable of
somekind. Im having trouble imagining a task that did not deliver
something or at least get you closer to the delivery of something.

--

Brian Kennemer
microsoft consulting services
brian[period]kennemer[the "at" symbol]microsoft[period]com

 

[Brian Kennemer]

WBS focuses on smaller and smaller tasks. I focus on smaller and
smaller deliverables and collaborate with the stakeholders invoiced.
It sounds like a small difference, but the execution can be quite
different, especially when the focus is not just on the deliverable
but on what the stakeholder needs to realise the added required value
over the expected life of the product and minimising the support
costs over the same time once the project ends.

What I am suggesting is that if people are doing their WBS properly
they are doing the same thing you are doing. Im suggesting that if
there is a difference between the tasks and the deliverables then
something has gone very wrong with the way the project is being thought
about by the PM. If the mindset is right then the two things (tasks and
deliverables) cannot be separated. While the individual tasks in a
project might not by themselves create a deliverable they should
certainly be part of a group of tasks that together create a
deliverable (deliverable represented at the summary task under which
the tasks are grouped).