What is a Work Breakdown Structure (WBS)?The Work breakdown Structure (WBS) was originally conceived by the US for defence purposes, as many project management practices in use today were. It is described in the US Military Standard (MIL-STD) 881B (25 Mar 93) as follows:
"A Work Breakdown Structure (WBS)is a product-oriented family tree composed of hardware, software, services, data and facilities .... (it) displays and defines the products to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end products."
I know, I know. I read this myself and thought, "huh?".
Okay in user friendly language, in large complicated projects there is always a risk that a project will have the problem of simply being a beginning, a muddle and no distinct end, because it is too hard to comprehend as a whole.
However a Work Breakdown Structure (WBS) gives a project a clear start, middle and end. This is achieved by breaking the project into building blocks, which have a distinct relationship with one another. It particularly something which is a feature of large Six Sigma projects where it is utilised extensively.
These "building blocks" are known as Work Packages and even if you are not implementing an WBS on your project, these have uses in their own right, which I will go into more detail on later.
WBS is also used at the beginning of a project to define Project Scope, organising resources and in estimating costs. The reason for this is because the tasks get grouped into Phases and it is often easier to estimate these in terms of resources and costs rather than having to do so for each task in isolation when it is hard to comprehend the "big picture" delivery.
Project PhasesSo basically one implements WBS to break a large project into a number of smaller tasks, which are usually grouped into Phases. The rationale behind this is that it is much easier to think and track a project made up of tasks. However since research has shown that the average brain can only juggle 7-9 tasks at anyone time, how on earth is a Project Manager supposed to assimilate possibly hundreds or thousands of tasks in a large project, let alone manage them at anyone time?
By breaking a Project into Phases or End Deliverables or Workstreams makes it much easier to manager and deliver.
Work PackagesA key element of an WBS is the creation of Work Packages. These basically are discrete sets of work which lead to a specific deliverable. The job of the Project Manager is to write these up in something like Word and get them costed / resourced.
If you are working with an external technology provider then they will often write these up themselves (hence saving you the work) and these will be used for contractual purposes to ascertain costs, timeframes and quality.
I tend to find that even if not implementing WBS, creating high level work packages to detail deliverables for certain workstreams can pay dividends. This is particularly relevant if you are unsure of the ability of that team to either properly deal with change request management or deliver the project quality plan deliverables on time.
Basically by creating a Work Package it leaves less room for "interpretation" by the team, and even less room for them to manoever should they fail to deliver. After all they can hardly say they didn't know what they were supposed to be delivering when they have signed up to a Work Package!
What Should be Considered when Implementing a WBSThe following should be considered:
Also a key consideration should be whether the project actually warrants implementing a WBS at all. Nowadays Organisations want software development projects delivered to ridiculously fast deadlines. Hence the increased used of such methodologies as Agile SCRUM. As such you need to consider whether you have the time to properly implement a sufficiently robust WBS Structure with all the inherent paperwork and overheads involved.
What is a Work Breakdown Structure (WBS)? - Tip
As you will see in How to Write a Project Plan 3/5 - Work Breakdown Structure (WBS), you can pick and mix which elements should be utilised on your project. Certainly unless you are delivering a very large and complex project, then there is absolutely no need to take the time to implement a WBS. For most projects other than those in the defence or government sectors there is usually no time to implement a WBS.
Certainly in all my years of managing large IT programs and projects for over 30 global blue chip Organisations I have never come across any using WBS, for the simple reason that the overhead is too great to manage and it is simply not agile enough to take into account the numerous changes required to the business requirements documentation or software requirements specification.
Just my view of course!
Sign Up for Our Free
Sign Up for Our Free
Return to top | Home |
Project Management Basics | Project Management Life Cycle | Project Management Documents |
Writing a Project Initiation Document (PID) | Project Management Report | Project Management Plans | Project Risk Management
| Project Management Scope | Project Costs and Budget | Project Resource Management |
Project Communications | Project Software Development | Sitemap | Contact Us |
Original Content Copyright © 2009 My-Project-Management-Expert.com
All other content is in the public domain or is copyright by the credited author.