Standardizing Work Breakdown Structures

This forum is for members to share and gain knowledge of Project Management. Got a question about project management? Need help with a problem? Wish to offer tips and advice? Post here.
Post Reply

As PMO managers we have observed many variations of Work Breakdown Structures (WBS). At one extreme, project managers create their WBS at two or three levels with loosely defined function packages such as only a title and an estimate of the number of hours. At the other extreme, project managers develop their WBS with levels taller than the empire state building, WBS Dictionaries which go into practically infinite detail, and work packages of just a couple of hours each. Whilst these extremes might not be required, the WBS should be produced with sufficient detail to serve as a helpful tool in managing the project’s tasks.

A Work Breakdown Structure (WBS) can be a useful tool for organizing a project by breaking it down into more manageable component parts based on the deliverables required to complete the project. It’s the accepted project management document for tying the project scope, cost, and schedule together. There are lots of methods to configure the WBS, but within an organization, it’s crucial to standardize the way it really is formatted across the entire portfolio of projects. Just as with processes, tools, and methodologies, standardizing the WBS format is an essential component of offering repeatability and consistency.

A regular WBS supplies numerous rewards for an organization. Initial, it permits price and schedule reporting in a consistent manner and standard format across its whole portfolio of projects. This ability also allows any level of management to obtain cost and schedule information at whatever level pertains to their wants from the lowest level work packages up to the whole project cost. Yet another benefit of a standard WBS is that since price and schedule reporting are consistent, the organization can develop a database to consolidate this information to be able to determine where variances occur between functional areas and projects over a time period. This may supply critical insight to how improvements might be created to future project expenses and schedules. As the database grows and evolves, it is going to also provide an accurate capability for estimating expenses and schedules associated with future projects along with adjusting work package sizes.

Additionally to the advantages of a standardized WBS, the significance of a WBS Dictionary can’t be overstated. Whilst the WBS defines the project scope, costs, and schedule, the WBS Dictionary lists and defines the actual function that is needed to satisfy each and every WBS element. These work definitions are especially important to maintain expenses segregated and inside the proper element. If work is not defined thoroughly sufficient by way of a WBS Dictionary then there’s a chance that function performed is going to be charged to the wrong WBS elements and accounts. If this occurs then the purpose of the standardized WBS is defeated simply because reporting will be flawed and inaccurate.

Inside each WBS you can find many items which ought to be standardized. First, the leading level of the WBS should be clearly defined as the end-state of the project. It really should also be easily sub-dividable into components which will then be broken down further into deliverable tasks and work packages. This top level should always be pre-defined and follow the Project Management Body of Understanding (PMBOK) processes. The next item of the WBS which ought to be standardized will be the work package size. Work packages are the lowest level elements of the WBS where function can be cost-estimated, scheduled, monitored, and controlled. By standardizing function package sizes – 4 to 40 hours or 8 to 80 hours – the WBS will present uniformity across all of its deliverables. This standard gives a safeguard by ensuring that if the estimated function on a task cannot be completed inside the standard work package time – for instance exceeding 40 hours of function in a four to 40 work package size – then the task should be further subdivided into a a lot more manageable size. Lastly, the WBS Dictionary must be standardized. The dictionary needs to be such that it acts as a mini-statement of work (SOW) and gives enough detail to clarify function required to accomplish the job and appropriate account info to charge the function to.

Whilst a standard WBS offers other rewards to the organization, like the capability to compare earned value performance across its project portfolio, it truly is only effective when it contains all the deliverables connected with the project. The function in every single element of the WBS ought to also be clearly defined within the WBS Dictionary so connected costs and schedules may be accounted for accurately. Once this is accomplished, the WBS is an effective tool for any organization in providing visibility of the scope, price, and schedule of its projects at any level.
Post Reply