Let Me Break it Down for You: Work Breakdown Structures
Work breakdown structures are extremely useful way to simplify complex tasks that need to be accomplished in a project by their individual components. They can also be combined with scheduling data to generate a Gantt chart (the end result is something similar to the Microsoft Project interface). The United States Department of Energy’s official definition of a work breakdown structure (WBS) is a product-oriented grouping of project elements that organizes and defines the total scope of a project.
One of the most important (and for some reason then-perplexing) lessons I learned in my undergraduate project management class was the fact that when developing a WBS, you cannot breakdown an element into only one sub task. For example, if you have a project that was cooking dinner, and one task was to take the food out of the oven, you can’t have the only subtask be “remove tray from oven”. You would need to break down the task into more than one step, otherwise you’re either reiterating the task itself, or you haven’t fully broken the task down.
I’ve used work breakdown structures extensively in personal programming projects. I personally follow the agile project development paradigm which is very suited to software development that is very features based and can be fluid (I personally would never try to build a bridge using agile project management methods, but then again I’d never try to build a bridge either!). When I develop a WBS, I first define the goals or features that I want in the next iteration of the software. That list generally makes up my root tasks on the WBS. I then subdivide each one into tasks I need to accomplish to have each feature complete. I then take a look at all of the tasks to see if it’s logical to break any down further. Normally I do this if I need to wait on someone else for part of a task, but I can complete another part by myself. If I can complete all of a task in a reasonably short period of time then I’ll just leave it without breaking the task down.
I personally like using Microsoft Project’s implementation of work breakdown structures. It’s very logical and is integrated with a Gantt chart. I also use some software called Trac to develop a WBS type of structure. It breaks down software development into Milestones (also called releases) and lets you add features to teach release. Using agile development, I like to have a two week dev cycle, normally with 1-1.5 weeks on development, and the rest on bug fixes and testing.
“DOE Environmental Management (EM) Glossary of Terms”. United States Department of Energy. 3/3/2010 <http://www.em.doe.gov/pages/PBSGlossary.aspx>.