Work Breakdown Structure

1558 Words7 Pages
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.…show more content…
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 item named "Define Requirements" that would result in the delivery of a requirements document. Later on in the process, the team might realize that defining requirements should fall under a broader category of concept design for the anti-virus application along with other groups of tasks related to the concept design. The bottom-up approach can be very time consuming but it can be a very effective method to create a work breakdown structure. Some project managers use the bottom-up approach for projects that represent entirely new software systems or approaches to completing a task, or to help create buy-in and synergy with a software development project team. The last
Open Document