Work Breakdown Structure

A work breakdown structure is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project. Since many projects involve many people and many different deliverables, it is important to organize and divide the work into logical sections based on how the work will be performed. The work breakdown structure is a foundation document in software project development management because it provides the basis for planning and managing project schedules, costs, resources, and changes.

There are several approaches a manager can use to develop a work breakdown structure. These approaches include using guidelines, the analogy approach, the top-down approach, the bottom-up approach, and mind mapping.

If guidelines for developing a work breakdown structure exist, it is important to follow them. Some organizations prescribe the form and content for work breakdown structures for particular projects. Many projects for the U.S. Government require contractors to prepare their proposals based on the U.S. Government provided work breakdown structure. These proposals must include cost estimates for each task in the work breakdown structure at a detailed and summary level. The cost for the entire project must be calculated by summing all the costs of all the lower level work breakdown structure tasks. When the U.S. Government personnel evaluate cost proposals, they must compare the contractors costs with their own estimates. A larger variation in costs for a certain work breakdown structure task sometimes indicates confusion as to what work must be accomplished.

Many organizations provide guidelines and templates for developing work breakdown structures as well as examples of work breakdown structures from past projects. Sample work breakdown structures for a wide variety of projects in various industries, including projects for telecommunications, web design, and the service industry, are available on the internet and from management service organizations.

Project managers and their team members should review appropriate information to develop their unique work breakdown structures more efficiently.

The analogy method of work breakdown structure construction involves utilizing another, similar project’s work breakdown structure as a starting point. Some organizations keep a repository of work breakdown structures and other project documentation on file to assist people working on projects. Some project management software packages include sample files to assist their users in creating a work breakdown structure and Gantt charts. Examining samples of other similar projects work breakdown structures allows one to understand the different ways to create a work breakdown structure.

The bottom-up and top-down approaches for creating work breakdown structures are two other methods available. To use the top-down approach, one should begin with the largest items of the project and break them in to subordinate items. This approach involves refining the work to be done into greater and more granular levels of detail. After completing this process, all resources should be assigned at the work package level. The top-down approach is best suited to project managers who have tremendous technical insight and a big-picture perspective.

The bottom-up approach involves the team members identifying as many specific tasks that are specific to the project as possible. Once this is done, the team members then aggregate the specific tasks and organize them into summary activities, or higher levels in the work breakdown structure. As an example, a software development team might be responsible for creating a work breakdown structure to create an anti-virus software application. Instead of looking for guidelines on how to create a work breakdown structure or viewing similar projects work breakdown structures’, they can begin by listing detailed tasks they think they would need to accomplish in order to create the application. After listing the detailed tasks, the software development team would then group the tasks in to categories. They may find that writing all the possible tasks down on notes and them placing them on a wall may help them see all the work required for the project and develop logical groupings for performing the work. For example, a business analyst who is on the software development team may know that they had to define user requirements and content requirement for the anti-virus application. These tasks might be part of the requirements documents they would have to create as one of the project deliverables. A hardware specialist might know the software development team might know they had to define system requirements and server requirements, which would also be a part of the requirements document. As a group, they might decide to put all of these tasks under a higher-level