The Work Breakdown Structure (WBS) is one of those tools that we love and hate within the world of project management. Love it because it drives good scope definition … hate it on the other hand as they are difficult to do. A work breakdown structure (WBS) is one of the key project deliverable that organises the team’s work into manageable sections and if often regarded as a decomposition of the work to be executed by the project team. One of the things that often comes up when doing a work breakdown structure is the definition of work. Ask somebody what they mean by work and wait for the answer, you will be surprised as each person will have a different definition of work which makes understanding the end point to be difficult.
The WBS will no doubt change multiple times during its development as the work scope details get further and further defined and the time scale for accomplishing the work scopes become better and better defined. When the tasks begin to take shape, the boundaries set for the definition of work / tasks will determine the WBS depth. The WBS will continue to evolve until the day of contract negotiation, and the technical content of the negotiated contract “freezes” the work itself. Every hour spent defining and redefining the WBS will pay double dividends when the project gets underway. The more compact one can make the WBS through correct interpretation of the work scope baseline, the easier the WBS will be to live with throughout the life of the contract.
The visual to understand here is a simple table format that follows in the line of decomposition. Here are 13 Tips / Steps in developing a Contract Work Breakdown Structure: –
- Tip 1: – There can be one and only one (1) WBS for any contract. This may vary for a project depending on size and scope.
- Tip 2: – The project should own the WBS, not the customer or organisation.
- Tip 3: – The WBS is a negotiated item during scope definition of any project.
- Tip 4: – Level three of the WBS is the normal reporting level of external information.
- Tip 5: – The reporting level for information is negotiated at the time of using the WBS format. Once negotiated, each reporting element should be clearly marked on the WBS diagram.
- Tip 6: – Once created the WBS will exist for the life of the project.
- Tip 7: – A solid process for WBS change should be negotiated. Only a formal project change will effect a change in the WBS.
- Tip 8: – When the customer directs the WBS change, the project manager makes the changes to the WBS documents (i.e., WBS diagram, WBS Index, WBS Dictionary, WBS list, etc.).
- Tip 9: – The WBS is a deliverable Project Plan item.
- Tip 10: – The WBS is not a “people” organisation chart; it is a work scope chart.
- Tip 11: – While the WBS elements at the Task Plan level contain financial data, the WBS is not the “official” book of accounting records for the contract. However, the Task Plan data contained within the WBS framework must be reconcilable to books of record.
- Tip 12: – The resource charges into the WBS must go directly into a single Task Plan / Schedule. The resource charges are not split between two or more Task Plan elements.
- Tip 13: – All contract work, in terms of contract line items and contract end items plus other contractual references, is identified against the WBS.
The time spent on defining and negotiating the final WBS is essential to a project, and the customer. Internally, the project will never be able to spend enough time defining, and redefining the boundaries of the work scope; communicating, communicating and re-communicating the boundaries of the work scope; and setting and resetting the time scales for accomplishment of the detail work scopes.