Hi All,
I would like to know how many of you (Project managers & Tech leads) use the WBS (work breakdown structure) for project planning? I hear it's a good thing to do, but then there are many "good things" to do, which don't work out in the end.
Does this really help in project planning? If so, whats the right way to do it. probably some links/articles could help.
Please remember I'm not a project manager, but sometimes I have to do his tasks..
In traditional project management, the WBS is an invaluable tool, if used correctly.
I've always done it in a top-down approach, starting with major chunks of work:
and simply drilled down to more specific levels
until every single element in the work breakdown structure is smaller than the reporting period.
By that I mean, if I have to report progress up the chain once every two weeks, no single element is allowed to be longer than about eight days estimated. If it is, it needs to be broken down further.
This has the following main beneficial effects:
That last point is important in future estimations. For example, if Sam continuously under-estimates user interface jobs by 10%, you know to bump up those estimates in future).
This should be happening IMNSHO otherwise your PM effort is more guess-work/black-magic than engineering.
I can't really provide any links for you, sorry, since this is mostly experience gained painfully from many years of doing that role. I do have access to a lot of links to make it easier, but they're company-internal (we're big enough to have our own methodology).
A WBS is essential - according to Capers Jones: missing/unknown/incomplete requirements, design and plans are the primary reasons for project failure, WBS's help in discovering and clearly defining project scope. I've used various tools from white boards to mind mapping tools. Don't let the tool tie your hands, find one that works OR just use paper.
WBS certainly help your plan your project. They are especially useful for making sure your sponsors and team members are looking at the same project, though maybe just at different levels.
A Work Down Structure is a map for the work you'll be undertaking in your project. A WBS should be used to explain consistently what you are going to achieve, how you are going to achieve it, how long it's going to take and how much it is going to cost.
A WBS doesn't do all of these things by it self, but it's one of the earlier building blocks for planning your project. You would typically create your WBS after you have defined/verified the scope of the project. You'll need the scope detailed since your WBS will be delvolved from your deliverables.
Creating the WBS is a top down process where you take your list of deliverables and then break them down into work packages. If you're creating a new financial system you might have several deliverables of;
1. General Ledger
2. Journal Interface
3. Account Payable module
4. Accounts Recievable module
5. Bank Interface
6. Reporting
The above deliverables would form the top of your WBS.
1.0.0 General Ledger
1.0 Transaction Ledger
2.0 Accounts Maintenance
2.0.0 Journal Interface
1.0 Journal creation
2.0 Journal review
3.0 Journal update
4.0 Journal deletion
3.0.0 Account Payable module
1.0 AP Invoice creation
2.0 AP Invoice review
3.0 AP Invoice update
4.0 AP Invoice deletion
4.0.0 Accounts Recievable module
1.0 AR Invoice creation
2.0 AR Invoice review
3.0 AR Invoice update
4.0 AR Invoice deletion
5.0.0 Bank Interface
1.0 Generic Payment interface
2.0 ANZ Bank interface
3.0 Westpac Bank Interface
4.0 Commonwealth Bank interface
6.0.0 Reporting
1.0 Trial Balance
2.0 Balance Sheet
3.0 Operating Statement
4.0 Invoices Pending
(NB: the numbering system is handy. Eg: you will know that 6.3.2 is the second task for creating the Operating Statement report.)
Then you would keep on breaking them down into work packages that would each take from 4 hours to 5 days to complete. Once you've completed the WBS you can get your team members or experts to estimate how long each work package (task) would take from the bottom up. These estimates would then help you plan an initial schedule and budget that is consistent with you the WBS and the original scope that was agreed upon.
Why do it this way? There are a couple of reasons, the first is ease of communication. Your estimators need low level work packages (ie: 4hrs to 5 days) to estimate accurately on. But your sponsors need high level concrete deliverables to assess your schedule and budget on. By deciding on a WBS early you can achieve both of these.
By using a consistant WBS a sponsor can look at your schedule and budget and relate it back to your original plan. They may decide that 4.0.0 is not worth the effort involved. This is the beuty of a WBS devolved from your deliverables, your sponsors need only look at the first level to get an understanding of what is going on.
If you define your WBS early on, your sponsors, your early team members and other stakeholders can see what they are getting involved in and also possibly spot what is missing from your project. There is a lot missing from the above trite example that would be easy for an expert to spot and patch the holes before you start.
The key points here are;
1. Create your WBS from your deliverables
2. Break the WBS down into work packages between 4 hours to 5 days long
3. Estimate on the work packages
4. Report your schedule against the top level(s) of your WBS
5. Report your budget against the top level(s) of your WBS
Complicated (ie: costly or risky) projects normally need another step. Large projects or ones with high probabilities of risk are typically phased. This simply means group your deliverables into phases as the top level. Each phase should produce something measurable and allow your sponsors to decide to continue or not. This way you avoid a big bang approach. Each phase should be judged complete, lessons learned done etc before going to the next phase. Large software development, building and construction is done in this way, and so are experimental projects where the outcome needs to be carefully monitored since success may not be assured.
The same project above broken into phases;
1.0.0.0 Phase 1
1.0.0 General Ledger
1.0 Transaction Ledger
2.0 Accounts Maintenance
2.0.0 Journal Interface
1.0 Journal creation
2.0 Journal review
3.0.0 Reporting
1.0 Trial Balance
2.0.0.0 Phase 2
1.0.0 Journal Interface
1.0 Journal update
2.0 Journal deletion
2.0.0 Account Payable module
1.0 AP Invoice creation
2.0 AP Invoice review
3.0 AP Invoice update
4.0 AP Invoice deletion
3.0.0 Reporting
1.0 Balance Sheet
2.0 Operating Statement
2.0.0.0 Phase 3
etc etc etc
Your WBS should have a clear link to your deliverables, and you can use phasing for complicated projects. Either way the logic is the same, keep on breaking down your WBS until you have the lowest level work packages that are concrete tasks that can be done in 4 hours to 5 days. You and your team members need to focus on getting the work packages done, however you and your sponsors will focus on monitoring and controlling the top one or two levels of the WBS.
Edit: WBS shouldn't really go all the way down to tasks.. i've posted a clearer example on tasks and WBS.