Where to get general info on Work Breakdown Structure (WBS)?

Question

I work in a software development company. I have this major ticket for which I have to produce a WBS (Work Breakdown Structure). I also have to prepare an estimation for the ticket. The ticket deals with a re-architecture of, well, various processes.

Now in our organization we have a generic template for this WBS. It is something we have to fill inside excel sheet. The fields in the sheet goes like:

#No.
Description
Planned Start Date
Planned End Date
Planned Hours
Actual Start Date
Actual End Date
Actual Hours
.
.
.

Here we'll just use a hierarchical numbering system to jot down the tasks (main tasks are whole numbered - sub tasks are sub-numbered). The thing that I note here is there is an almost start date and end date for all most everything.

I am not so skilled in creating a WBS. So I searched youtube & wikipedia for WBS tutorials/information and came to understand that WBS is a graphical representation. But then I don't get why we do it in excel sheets. Its standard practice in our organization.

Actually I want to know when do we embark on creating a WBS, and what is the best approach to go about it...

Answer 1

Step one: burn your template

Not to be blunt, but if you really want to generate a WBS the first thing I'd do is burn the template you've been given, as it's going to lead you down the wrong path and will result in a product that doesn't do what it's supposed to. The template is conflating a WBS with a schedule; this is bad because they are complementary products meant to convey different information.

Definition of a Work Breakdown Structure (WBS)

A work breakdown structure is a hierarchical decomposition of a project into it's sub-elements. The main rule of the set of elements at any given level of decomposition is that they must completely describe the project (i.e. nothing is left out) and must be mutually exclusive (i.e. the same work is never represented in more than one bucket).

What does a CWBS contain

Given this definition we can derive what information should be in a WBS and what should not. All a WBS should contain is a title for each element that summarizes the effort, an identification number that locates with work within the hierarchy, and about a paragraph of text describing in more detail the WBS element (some people use WBS to mean just the ID and title and use the term WBS dictionary when the description paragraphs are added). Wikipedia has a good example of an ID and title only WBS for a bicycle:

So back to that template

The trap the template is asking you to fall into is to use the WBS as a schedule by asking for dates and effort. A WBS doesn't care when its elements are completed--or how much work it will take to do them; all a WBS is trying to do is to define and decompose the work into small enough chunks to support detailed planning.

So start with your project, think of how the work is logically decomposed, and keep going until you think you've gone far enough. (If you're wrong you'll find out later and can iterate, but without knowing what your project actually is or how your company manages we can't help much more than to say go with your gut.) I think if you think about creating a WBS without worrying about scheduling or hours it will go much easier for you.

If the WBS doesn't have all that schedule stuff in it then what?

The WBS is only a critical first step. Once it's complete you need several other project management products. You need to understand the organization that will be executing the work; often, this is called an organizational breakdown structure, but unless you're standing up a new group just for this project simply understanding your current organization is probably sufficient.

Next I'd create an Integrated Master Plan and Integrated Master Schedule. The plan is a more time- (i.e. event-) based way of looking at the work than the WBS. For example, our WBS example has an element for Frame Set. Frame Set might include the effort for procuring raw materials, bending metal, welding, priming, painting, drilling holes, and packaging for shipping. This all makes sense in one WBS element, but in terms of an IMP or IMS these steps are occurring over wide spans of time. The IMP and IMS take the work described in the WBS and define the logical order in which the discrete steps have to be completed. It is only once this IMS has been defined that it makes sense to start scheduling tasks and assigning resources (e.g. people, shops, etc.) to complete them.

Bottom line

Often the WBS is reflected graphically, but anything that can depict a hierarchy works fine, including word or excel. The reason your company's templates look the way they do is because they're calling their template a WBS, but they are really looking for a schedule--or more specifically an earned-value baseline, but that's another topic entirely.

I suggest you build your WBS first, and then use that to help you build a schedule that accounts for all the work.

Answer 2

Deostroll, a WBS is a tool used to generate a good understanding of the scope of a complex task or a project. It could be a graphical representation, written or both.

As defined in the PMBOK

WBS: The process of subdividing project deliverables and project work into smaller, more manageable components.

There are many ways of going about WBS, some people divide the project in phases, subprojects, deliverables, work packages, etc. Others decide to divide the project by functional areas, like

Project [name]

• PM Stuff
• Training
  • Training manual
  • Communication plan
• Data
• Development
  • Requirements
  • Design Docs
  • etc

My recommendation is for you to find a good way to split the task in components that make sense to you, and that you can talk about those components in logical manner. Don't worry so much about time line or effort levels yet. After you think you have the "full" scope down, you could start estimating using some of the advice in this page or using company policy.

The excel workbook that you company uses seems to be a conglomerate of many things, but that does not mean that is the wrong thing to do. Unless you see some issues with it.

Answer 3

You're getting ahead of yourself. Your template is for a schedule, but you probably don't know what activities you must do, much less when to do them. Read Adam's answer - he's got a lot of good info in it. Sorry to repeat some of what he's got, but it's good lead in to the rest of my answer too.

Just to be clear: the point isn't hierarchy vs graph. As you have already seen, you can turn the graphical representation of a WBS into a more concise tree hierarchy. Rather a WBS helps focus your attention on what you must deliver. It is not a list of tasks. Focusing your attention on the right thing at the right time is sometimes all the separates successful projects from failures. Early in the project is not the time to "just use a hierarchical numbering system to jot down the tasks". More important than the actual list of deliverables or the WBS graph (or hierarchy as you prefer) is the WBS Dictionary - a page of amplifying information that defines in greater detail each deliverable you are responsible for. Things you may choose to include or link to in this detailed description:

1. More information about the scope of this deliverable
2. How the work for this task will be billed
3. Major milestones associated with this deliverable
4. Activities
5. Resources (people, hardware, travel, subject matter experts) required
6. Technical references or other specs

The milestones and the activities can be used as the start of defining more detailed tasks you'll need to do in order to get the deliverable done. At this point, you can pull all of this information from all you WBS descriptions together & start creating a schedule.

Answer 4

This is a bit 'off topic' AND after the WBS comes this next part. "Forewarned is forearmed"

The stuff about the structure above is a good start, Where plans often fail miserably are in two areas: Estimating & Reserves. When people 'estimate' how long and how much money it will take... it isn't pretty. As a planner, you need to do a couple of things. First, you need to 'calibrate' your estimators; see what they guessed and see how they did and put in corrections accordingly. DO NOT change the approved baseline on your own. Second, DEMAND both schedule & money reserves. In some NASA projects, they can both be as large as 25% to 50% of the time and money. (and some still overrun badly). To mitigate the risk, planning based on ACTUAL performance in other projects, projects that have finished successfully, get much closer to reality than most estimates (guesses?). Also, I don't recall a project that didn't use up the reserves. The 'agile' development approaches things a bit differently. Usually, they manage expectations (quickly based on performance) so that the project can chug along and manage expectations, cost, and cash flow.

I have been doing or around planning, planners for over 40 years, not all the time, so I have both done it and observed it.