Project Management

The first step in building a schedule: the WBS

The first thing you need to do when building a project schedule is to create a Work Breakdown Structure (WBS).

The first thing you need to do when building a project schedule is to create a Work Breakdown Structure (WBS). Creating a WBS allows you to look at the project at a high level and then break it into smaller pieces until you can get the full picture of the totality of work that needs to be performed. The project manager may be able to create a draft of the WBS as a starting point or the entire team (and clients) can create a WBS in a group exercise.

The general process for creating a WBS is as follows:

  • State the name of the entire work effort. This is the top level of your WBS (generally called level 0.0)
  • Look at the large chunk of work and break it down into smaller pieces that together represent the larger chunk. You might break a large piece of work into two smaller parts, five smaller parts, or whatever number of smaller parts makes sense. Sequencing is not important at this time.
  • After you finish your work breakdown, do a quick estimate of the effort required to complete each individual work component to see if the work effort is larger than the "estimating threshold." This estimating threshold is based on how large you want the final activities to be. It's easier to manage four forty-hour activities than one 160-hour activity. For a typical business project, we recommend that you try to break the work into activities that are no larger than 80 hours of effort, but this number could be higher or lower based on the size of your project.
    You should also look at each chunk of work to determine whether it's simple enough that you understand it. This is important because the work at the lowest levels of the WBS (work that is not broken down any further) will be moved to the schedule. If you have work on the schedule that's vague and not understandable, you won't be able to assign the work to a team member for completion.
  • Look at each of the work components that you have broken down from the higher level and apply the two checks from step 3. If either of the answers is "no" then you would repeat steps 2 and 3.

The process of breaking the work components into their lower level set of activities (steps 2-3 above) should continue until all work components are represented as granularly as necessary, with no activities having estimated effort larger than the estimating threshold and where you understand all of the work. This is when the WBS is complete.

There is a caveat to the work breakdown process above. If your project is very large, it's also likely that you may not know enough to be able to break all of the work down to the level described above. This may still be okay as long as those higher-level chunks of work are far in the future. In this case, you can leave the work at the higher level until you get closer to executing the work. When this higher level work is within three months of executing, you should know enough to be able to break the work down at a more granular level.

9 comments
Mjain21
Mjain21

I just gone through WSB exercise and come across below Question which seems to be wrong as per given answer, could you please explain more on this? Q: The first step in WBS creation is A. Determine cost and duration of each project deliverable B. Identify major deliverables of the project C. Identify components of each deliverable of the project D. Determine the key tasks to be performed Answer:: A Explanation:: Cost estimates and duration estimates are created before and then refined during WBS

raffiyathulbazariya
raffiyathulbazariya

Sir Can u give me the standard WBS for a Building project including basment structutes.

anna
anna

So if you are the project manager and start with a broad outline WBS, does anyone have suggestions for methods of getting feedback from your resources about the estimated efforts necessary? The get together as a group approach doesn't seem that practical, or convenient. Maybe distributing one at a time to everyone involved to get them to claim their tasks? Or sending all the tasks for a specific resource directly to that person for more detail? Any other ideas?

dcalderwood
dcalderwood

Probably good idea to elaborate that the WBS is actually a WBS of deliverables as identified by the stakeholders requirements and expectations and that the work activities/task list for creating the project schedule is created from analyzing each of the WBS (deliverable) work packages. - Dan

Tim Slartibartfast
Tim Slartibartfast

Two observations I would make with this very clear outline, first I applaud the need to bring the team together because, especially for large projects and where the work spills out of a department across business functions, there may be many routes to delivering the final solution. These must be aligned and agreed, otherwise the content and effort you put in can be wasted should a different approach be adopted by part of the business. Also I would have care with the view of not planning into the future. Although it is true that content is often not clear, process can normally be agreed. It is not uncommon that blocks of undetailed activity prove insufficient in duration to accommodate the volume of activity which needs to be put into them when more detailled planning can happen. The imapct of which being an immediate adverse result in both time and cost. I would always advocate detailling the approach in low-level steps, even if a future rewrite is necessary, as my experience is that project sponsors, customers and employers like to be very clear on costs and end-dates.

wizard57m-cnet
wizard57m-cnet

and/or talk with your instructor. This article is over 5 years old.

ebeiyamba2006
ebeiyamba2006

The WBS is definately the flow system of any project.In the sense that,without a proper WBS,it will be impossible to achieve a 100% successful project. The need for the project manager and his team to thoroughly designed the WBS.

wfroese
wfroese

OK, I really don't get this. First it seems that you advise that an estimate at the beginning is necessarily devoid of pertinent information "Also I would have care with the view of not planning into the future...The impact of which being an immediate adverse result in both time and cost." And then you go on to try to detail it for the very purpose that would get us into the biggest problem. "I would always advocate detailing the approach in low-level steps, even if a future rewrite is necessary, as my experience is that project sponsors, customers and employers like to be very clear on costs and end-dates." For trivial projects and with business owners that really know what is possible and what they want, you can get a good result with big up front design. In these cases, a clear view of costs and end-dates may be possible. In some cases, it may be possible to draw a line around some of the parts of the problem and say how long but then show other parts of the issues and label them "here be monsters". Some of those parts can be addresses with a smaller project that tests a new technology or approach. Other times you will need to say that the business needs may be best met with a multiple phase project. If the sponsor is just expecting 1 project they need to know at the outset. If you assess the business owner to be one that is likely to change the direction as their knowledge of the possibilities change or you are working on radically changing the business process, then that is a project that won't hit it bang on in a time bound framework. You are going to have to go back in and address the new knowledge gained by the business owner during the project.

Tim Slartibartfast
Tim Slartibartfast

Apologies for the confusion, I can understand how this reads. The purpose of a WBS is to define the detailled steps in a project, with the aim of eventually delivering a cost and a timescale. My experience is that estimates will often fall short of the actual time and effort. The exceptions come from experience where people have done this a number of times and know from experience or history what actual costs will be. These are not people or groups who are just learning about WBS as they have experience or historic data to support them. So estimates and blocks of time/cost are very often insufficient. My suggetsion was that instead of just blocking-out an area with the come back to it later label, the process can be agreed and should there be unknowns do your best to break down the steps and add contingency rather than just stick in a block as the more detail uncovered the better position the plan will be in. The implication being that even if a re-write is later required (as would be with an assumed block of time), the capacity allowed and the degree of impact that the rewrite has will be less. Finally there are indeed some businesses which recognise you can only be sure about what you know, but my experience is that numbers and schedules published in many organisations (especially those where the culture is continuous operations not project environments) take the first published headlines, whitewash the caveats and don't like hearing the consequences. All I was saying was take the time to investigate the details and even if you don't know the what, define the how and consider the complexities that could be uncovered, especially when embarking on WBS and project planning for the first time.