Hi I am about to set to work on creating a Work breakdown Structure for a small CRM project. I want to focus the WBS on the deliverables (products) and NOT on the phases and activities of delivering the project.
My dilemma is should I Create headings such as "Sales", "Marketing", "Service" and then under each one branch out into the deliverables for that mode (e.g. Reports, plug-ins, processes Customisations etc)
Using this method would mean that I would end up with a node called "Reports" under each heading
or....
Should it be that the items like Reports, Customisations and Plug-ins, processes are at the top level. e.g. This would then show all the reports for all depts under 1 node.
I think I lean towards the first option as that is pretty much the way in which the project was scoped.
Actually maybe I should be referring to this as "Product Breakdown Structure" not a "Work Breakdown Structure" Saving Changes...
Mick GavinPMO Co-Ordinator| NHS PensionsFleetwood, United Kingdom
Iain
You are correct to called it Product based - this is one of the 7 key or fundamental principles of PRINCE2 i.e product based planning. There is an entire section on this in the PRINCE2 manual ro you might want to visit http://www.pbpkb.com/ where you can see some samples.
The trick is to start with a view of what the final delivered product will look like/consist of and then work backwards by decomposing it in to its various constituent parts.
It takes a while to get used to it but its worth it Saving Changes...
Darren KosaPlanning & Controls ContractorHampshire, United Kingdom
Hi Iain,
When creating a WBS I tend to work bottom up, as opposed to a PBS where it's created top down. Listing every single deliverable on a post-it note and then logically grouping them should naturally give you your WBS. Also by undertaking this as a group exercise with your project team you should get buy-in from them at the same time.
As the WBS can be used as a communication tool, so long as it's understandable to the stakeholders and the project team who will use it, I don't really think there are any hard and fast rules as to what the end result should look like.
That said, the only recommendations I'd make are that you employ the old 100% rule, where each subordinate level of the WBS contains 100% of the work scope contained in the parent level, and you also ensure each terminal element is unique, i.e. there isn't any overlap in scope between any of the Work Packages.
Have you also thought about creating a WBS Dictionary to accompany your WBS?
I have ended up created a general PBS for the project, which outlines just the depts affected. Then I have created a PBS for each each dept so i can go into further detail.
This seems to be a good representation of what we plan to deliver and I think is a great tool to explain the project to the customer
thanks for your comments
