WBS- Major Steps, WBS Implementation, high level WBS tasks

<< Work Breakdown Structure (WBS)

Schedule: Scheduling Fundamentals >>

Software Project Management (CS615)

LECTURE # 36

7. Work Breakdown Structure

7.8

WBS- Major Steps

e) 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.

f) 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.

273

Software Project Management (CS615)

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.

g) 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.

Product

Due

Date

Author/

Name

Date

Delivered

POC

4/1/96

ABC

Requirement

Specification

8/1/96

XYZ

Design Specification

8/1/96

DEF

Test Plan

...

11/1/96

Implementation Plan

274

Software Project Management (CS615)

...

12/1/96

Source Code

1/30/97

...

Test Report

h) 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.

a) Brainstorm to arrive at board tasks for a project

b) Refine the board tasks

c) Categorize tasks into logical task headers

a) 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.

275

Software Project Management (CS615)

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.

Prepare a Client

questionnaire.

Prepare a Software

Requirements Specification

(SRS) document.

Arrange for

meetings with

li t

Document client

feedback

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.

b) Refining Broad Tasks

276

Software Project Management (CS615)

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.

c) 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.

7.8

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.

277

Software Project Management (CS615)

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.

ii.

Methodology

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

7.9

Guidelines for decomposition of work tasks

278

Software Project Management (CS615)

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 semi-

standard 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

279

Software Project Management (CS615)

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.

ii.

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

Design

Top level design

Detailed design

Implementation

Coding

Unit test

Integration

Software integration

Hardware/software integration

Testing

Alpha testing

Beta testing

280

Software Project Management (CS615)

Acceptance

Installation / Maintenance

Error correction

Software enhancement

Management

Planning

Staffing

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

Documentation

Technical writing

Project publishing activities

Development documentation

Non-deliverable development documentation

Deliverable development documentation

Maintenance documentation / User documentation

iii. 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

281

Software Project Management (CS615)

√

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

282

Software Project Management (CS615)

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.

283

Table of Contents: