Spread Knowledge

CS615 - Software Project Management - Lecture Handout 36

User Rating:  / 0

Related Content: CS615 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Project Management

Work Breakdown Structure

WBS- Major Steps

Define Project Development Phases

For large systems, the decomposition of the system into smaller components needs to be done early in the planning cycle

The rationale for the decomposition must be known, otherwise, different results derived from different reasons for the system decomposition may occur.

For example, if a phase is defined to accommodate user needs, the phase may cross multiple functional areas of the system. If, on the other hand, a system is divided into phases simply to reduce risk, a functional division might occur where the phases represent completion of entire functional areas of the system.

The way in which the phases are handled, differs with each application. Often, phases are handled as top level WBS elements, with tasks associated with each phase defined.

Define Task Relationships

If a project is broken down into phases, be sure that the WBS reflects this. The WBS structure denotes a hierarchy of task relationship.

Subtask completion eventually rolls up into task completion, which ultimately results in project completion.

There can, however, also be relationships between tasks that are not within the outlined hierarchy.

These relationships need to be noted, and the ultimate structuring of the tasks optimized to favor a minimum of horizontal dependencies and relationships. If the tasks are not organized efficiently, it becomes difficult to schedule and allocate resources to the tasks.

The project scope of work is an iterative process that is generally done by the project team with the use of a Work Breakdown Structure (WBS), allowing the team to capture and then decompose all of the work of the project.

A WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of the project; work not in the WBS is outside the scope of the project.

As with the scope statement, the WBS is often used to develop or confirm a common understanding of project scope. Each descending level represents an increasingly detailed description of the project deliverables.

A WBS is normally presented in chart form, however, the WBS should not be confused with the method of presentation—drawing an unstructured activity list in chart form does not make it a WBS.

Defining Deliverables

Deliverables associated with each task are shown in the WBS and are reflected in the Deliverables portion of the Project Plan. A sample of a Deliverables template is shown next. All deliverables are listed as they are identified.

As the schedule is completed, the due date is filled in, and responsibility for the deliverable is assigned as it is known (typically when the organization chart is defined). The date delivered is a field that is filled in as deliveries are made.

Over the course of the project, a comparison of the due date and the date delivered provides a metric for how well deliverable dates are met by the project team.

While the deliverables list is a compilation of information identified in the WBS and the project schedule, it is useful to maintain a separate list since deliverable completion can be a key metric of project progress. Separate tracking of deliverables can help keep a project on track. It also serves as a useful communication tool with both stakeholders and the project team.

4/1/96 4/1/96 ABC
Design Specification 8/1/96   XYZ
Test Plan 8/1/96   DEF
Implementation Plan 11/1/96  
Source Code 12/1/96  
Test Report 1/30/97  

Creating a Work Breakdown Structure

A project can be compared to a large system. A large system consists of multiple, independent subsystems that achieve a common goal. Similarly, a project consists of small, independent tasks.

Each task can be subdivided into sub tasks. Fro example, in a general software project, a task is to perform project analysis. You may also consider studying the organizational objectives and preparing a project proposal to present to the client.

Therefore, in a project analysis task, there are three subtasks. A subtask is also known as a work package. A work package is a unit-level entity in a project system.

You can create a WBS by following the three steps listed below. These are general steps, and they can vary in relation to an individual or an organization.

  1. Brainstorm to arrive at board tasks for a project
  2. Refine the board tasks
  3. Categorize tasks into logical task headers

Brainstorming to Arrive at Broad Tasks

The first step in creating a WBS is to organize a meeting of all senior managers, system analysts, and prospective developers. The objective of the meeting is to brainstorm and come up with a set of broad tasks that need to be performed in a project. During the brainstorming session, you can make a note of all possible tasks.

Subsequently, the feasibility of each task is assessed. In addition, any conflict of common tasks can be eliminated. To enable you to perform this activity better, you can arrange tasks as and when they are brainstormed.

For example, XYZ Inc. conducts a brainstorming session to divide the tasks into multiple subtasks that are performed during the analysis phase of a project.

During the session the project managers and the analysts come up with tasks on the basis of prior project experience. These include tasks such as determining the scope of a project, drafting the software specifications, and securing resources for the project.

Some additional tasks are also determined based on client requirements. Preparing the initial project budget and estimating the approximate project timeline are examples of such tasks. In addition, personnel responsible to complete each task are also determined.

The subtasks are subsequently arranged in the order in which they are executed.

Figure 6 depicts the subtasks in the analysis phase. Note that after a questionnaire is prepared, you can either arrange to meet the client or document the feedback collected by the questionnaire. It is clear from the figure that preparation of the
SRS document can begin only after the preceding three tasks are complete.

WBS Activity

Figure 6: WBS Activity

Dividing a main task into multiple subtasks also enables you to estimate the duration and the effort required for individual tasks.

Subsequently, at the end of the phase, you can evaluate the actual effort and duration. This helps you compare the estimated values with the actual values and prepare a schedule for the subsequent phases.

The duration of each task affects the total duration of a phase. This, in turn, affects the schedule of the subsequent phases. You can make similar deductions while comparing the estimated costs with the actual costs of a task.

Refining Broad Tasks

In the second step of creating a WBS, you refine the list of tasks that was compiled during brainstorming.

Refining the tasks may include adding more tasks or combining the existing ones.
During this step, you may also change the arrangement of tasks.

A change in the arrangement of tasks can occur on the basis of two theories of WBS.

  • Deliverable-based theory
  • Project life-cycle-based theory

You use the deliverable-based theory when the deliverables of a project are more important than its phases. This normally happens when the deliverables are decided before the project begins.

However, if the phases of a project are completely defined, you use the project life-cycle-based theory. You can use the project life-cycle-based theory to arrange the tasks in a project.

Categorizing Tasks into Logical Headers

Finally, after defining tasks and arranging them, you categorize each task into a logical task header.

For example, preparing test plans and test cases and drawing up the test plans can be categorized as Testing.

This activity provides another chance to ensure that you have not missed any task during brainstorming.

In addition, you can also consult an expert such as a senior manager to review and validate the tasks identified.

WBS Implementation

Implementation Strategy

When you set up a project WBS, think about how you will be using it later in the project. Consider how you will organize the WBS, schedule format, manager assignments, and charge numbers, in your early project planning. It will be
helpful if you can map the charge numbers, managers, and task groups to each other. This will help you track costs and progress for each manager.

If your project schedule will on MS-Project, you may want to insert "text" columns into your schedule (Gantt View) for project charge numbers and manager names.

Some project management environments have definite conventions for grouping items in a WBS. The best method is to have a WBS that works for your particular project environment. The WBS should be designed with consideration for its
eventual uses.

Your WBS design should try to achieve certain goals:

  • Be compatible with how the work will be done and how costs and schedules will be managed,
  • Give visibility to important or risky work efforts,
  • Allow mapping of requirements, plans, testing, and deliverables,
  • Foster clear ownership by managers and task leaders,
  • Provide data for performance measurement and historical databases, and
  • Make sense to the workers and accountants

There are usually many ways to design a WBS for a particular project, and there are sometimes as many views as people in the process.

Experience teaches that everyone takes a slightly different slice of the apple, so make sure WBS arguments seeking metaphysical certainty are quickly brought to closure.


  • PM must map activities to chosen lifecycle as each lifecycle has different sets of activities.
  • Integral process activities occur for all Planning, configuration and testing.
  • Operations and maintenance phases are not normally in plan (considered post-project)
  • Some models are “straightened” for WBS:
    • Spiral and other iterative models
    • Linear sequence several times
  • Deliverables of tasks vary by methodology

Guidelines for decomposition of work tasks

General Guidelines

  • A WBS should be easy to understand. Some companies have corporate standards for these schemes. Some top-level items, like Project Mgmt. are in WBS for each project. Others vary by project
  • What often hurts most is what’s missing. Break down until you can generate accurate time & cost estimates. Ensure each element corresponds to a deliverable.
  • How detailed should it be?
    • Not as detailed as the final MS-Project plan
    • Each level should have no more than 7 items
    • It can evolve over time
  • What tool should you use?
    • Excel, Word, Project
    • Org chart diagramming tool (Visio, etc)
    • Specialized commercial apps
  • Re-use a “template” if you have one. Although each project is unique, WBS can often be “reused” since most projects will resemble another project to some extent.

Ex: Most projects within a given organization will have the same or similar project life cycles, and will thus have the same or similar deliverables required from each phase.

  • Many application areas or performing organizations have standard or semistandard WBS s that can be used as templates.

Ex: Financial Management System etc

  • Identify major elements of the project. In general, the major elements will be project deliverables and project management.
  • Decide if adequate cost and duration estimates can be developed at this level of detail for each deliverable.
  • Identify constituent components of the deliverable. Constituent components should be described in terms of tangible, verifiable results to facilitate performance measurement.
  • Verify the correctness of the decomposition: are the low-level items both necessary and sufficient for completion of the decomposed item? Is each item clearly and completely defined? Can each item be appropriately scheduled and budgeted?
  • The WBS is not a decomposition of the software produced by the project. It is a decomposition of the project itself, and includes such activities as management, procurement, installation and, of course, software development.
  • Each low level module may be assigned three basic work tasks:
    • module design,
    • coding and
    • unit testing
  • Additional development tasks such as prototyping, testing, and integration are derived from the other development phases.

A typical list of high level WBS tasks

Following table contains a typical list of high level WBS tasks to be included in the formal WBS task list.

  • This is not an exhaustive list of all project development tasks, and not all projects will require all the tasks described.
  • However, this table will be useful as a checklist to assist in locating tasks that may have been overlooked.

Table: High level WBS structure tasks

Software development
Requirements analysis
Prototype development
Prototype specification
Prototype design
Prototype implementation

Top level design
Detailed design

Unit test

Software integration
Hardware/software integration

Alpha testing
Beta testing


Installation / Maintenance
Error correction
Software enhancement

Administration and services
Budget administration
Personnel management
Quality assurance
Configuration management

Training / Procurement
Acquisition of development tools
Acquisition of system components (off the shell)
Equipment selection
Vendor selection
Ordering procedure
Inventory control

Technical writing
Project publishing activities
Development documentation
Non-deliverable development documentation
Deliverable development documentation

Maintenance documentation / User documentation

Management and Administration Tasks

  • Non-development activities, such as high level management WBS tasks, are standard, to a large extent, and any variance is determined by either the magnitude of the project, or the introduction of a new management model.
  • An example of a list of management WBS tasks appears in the following Table.
  • This list contains many of the most important management tasks required for most software development projects.
  • Those tasks that are mandatory for all projects are marked as such in the list.

Table: Management and administration tasks

Mandatory Management task
1. Planning
2. Preparation or estimates
3. Risk analysis and risk management
4. Scheduling
  5. Staffing
  6. Budget analysis and administration
7. Personnel management
8. Task assignment
9. Delegation of authority
10. Assignment of development resources
  11. Supervision of development equipment maintenance
  12. Supervision and control of development
  13. Organization of reviews and formal presentations
  14. Establishment of standards and methods
15. Quality assurance and control
16. Configuration management and control
  17. Supervision of subcontractors and vendors
18. Higher management interface and coordination
  19. Customer interface and coordination
20. Reporting
  21. Administration and services

  • Note that budget analysis and administration is not a mandatory management task, simply because not all projects administer their own budget. Some organizations have a financial officer responsible for the administration of project budgets.
  • Customer interface is also not a mandatory management task because not all projects have a customer. In the case of company internal projects, high level management, together with the designated users of the system being
    developed, play the role of customer. It is usually they who specify the initial project requirements, and it is to them that the project manager must come for final approval and for final system acceptance.
  • Break down the work until accurate estimates of cost and resources needed to perform the task are provided.
  • Ensure that clearly defined starting and ending events are defined for the task.
    This may be the production of a deliverable or the occurrence of an event.
  • Verify that the lowest level tasks can be performed within a “reasonable” period of time. Each state organization must define “reasonable.”
  • If the time period to complete a task is too long, an accurate project status in the implementation phase may not be possible.
  • An industry standard rule of thumb is to make work packages that can be completed in timeframes of two weeks.
  • Verify that people assigned to the project are all assigned a WBS task. Have a firm rule: if the task is not on WBS, it is not worked on.
  • The work breakdown structure and any support documentation should be easy to understand.
  • The work should not be subdivided arbitrarily to the lowest possible level.
    Work breakdown structure elements at the lowest control level should typically range from 0.5% to 2.5% of total project budget.
  • Furthermore, you should be aware that the work breakdown structure can be developed to reflect the trust that you have in specific line groups, by leaving them the autonomy over specific areas of work.
  • Finally, always remember that projects are dynamic working environments - so try to maintain flexibility in the work breakdown structure.
  • As a general guideline, no single functional decomposition should be selected just because it was conceived first. The functional decomposition of a software system may be substantially different from the design decomposition of the system. However, a good functional decomposition will have taken into account design as the next development phase, and will often be a good starting point for the division of the system into high level design components.
    The high level design components are then further decomposed into successive lower levels that ultimately produce programming modules. A good modular design produces small, simple, independent modules.