2.requirements management

Project Management

Scope management

Requirements management

P. Fitsilis ([email protected])

Definition

• Scope is the sum of the

– Products

– Services and

– Results

• to be provided as a project

Requirements management

The requirements problem

• The goal of project development is to develop quality products —on time and on budget—that meets customers real needs.

• Project success depends on good requirements management.

• Requirements errors are the most common type of systems development error and the most costly to fix.

• A few key skills can significantly reduce requirements errors and thus improve quality.

What is requirement?

• A requirement is a capability that the system must

deliver.

– A capability needed by the user to solve a problem to

achieve an objective

– A capability that must be met or possessed by a system

or system component to satisfy a contract, standard,

specification, or other formally imposed documentation

– A documented representation of a condition or

capability as in (1) or (2).

What is requirements management?

• Requirements management is a process of

systematically eliciting, organizing, and

documenting requirements for a complex

system.

• Our problem is to understand users‘ problems in

their culture and their language and to build

products that meet their needs.

Why we need to manage

requirements? • How many requirements has a small product?

Why we need to manage

requirements?

Common questions

• Boeing 777 has to satisfy 300,000 requirements

• The questions are: – Which project team members are responsible for the wind speed

requirement (#278), and which ones are allowed to modify it or delete it?

– If requirement #278 is modified, what other requirements will be affected?

– How can we be sure that someone has written the code in a software system to fulfill requirement #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?

The Life of a Requirement

Concept Phase

Business

Requirements

Need, Problem or

Opportunity

Justification

Project Charter

Funding:

Business

Requirements

Solution

Requirements

Describes the characteristics

that meet the business

and stakeholder requirements:

- Functional

- Non-Functional

- Implementation

Stakeholder

Requirements:

Needs of a

stakeholder and

their

interaction with the

system

How WHAT WHY

Requirements Phase

Problems of requirements

management

12

• Stakeholders don’t know what they really want

• Stakeholders express requirements in their own terms

• Different stakeholders may have conflicting requirements

• Organizational and political factors may influence the system requirements

• The requirements change during the analysis process. New stakeholders may emerge and the business environment change

The logical gap customer

End user contactor

Requirements processes

• Enterprise Analysis

• Requirements Planning and Management

• Requirements Elicitation

• Requirements Analysis and Documentation

• Requirements Communication

• Solution Assessment and Validation

Guide to IIB Body of Knowledge, International

Institute of Business Analysis

http://www.theiiba.org/

http://www.theiiba.org/

Requirements processes

Enterprise Analysis

• Creating and maintaining the business architecture

• Conducting feasibility studies

• Identifying new business opportunities

• Scoping and defining new business opportunities

• Preparing the business case for new business opportunities

• Conducting the initial risk assessment for new business opportunities.

17

Enterprise analysis Project

authorisation

• Projects are typically authorized as a result of one or more of the following:

– A market demand

– A business need

– A customer request

– A technological advance

– A legal requirement

– A social need

A market demand (e.g., a car company authorizes a project to build more fuel efficient cars in response to gasoline shortages).

A business need (e.g., a training company authorizes a project to create a new course to increase its revenues).

A customer request (e.g., an electric utility authorizes a project to build a new substation to serve a new industrial park).

A technological advance (e.g., an electronics firm authorizes a new project to develop a video game player after advances in computer memory).

A legal requirement (e.g., a paint manufacturer authorizes a project to establish guidelines for the handling of toxic materials).

A social need (e.g., a nongovernmental organization in a developing country authorizes a project to provide potable water systems, latrines, and sanitation education to low-income communities suffering from high rates of cholera).

18

Project authorisation examples

05 20

CONCEPTION

FEASIBILITY

IMPLEMENTATION

OPERATION

TERMINATION

Define the Project

Design the Project Process

Deliver the Project

05 21

Evaluation of

the Brief

Development

of a range of

options

Definition of

the product or

service

Broad brush

analysis filters

numbers of

options

Project Teams Actions

Simplistic Feasibility studies to

determine range of possibilities

Organisations

mission

Organisations

strategy

Organisations

goals &

objectives

Organisations

need to grow

or survive

Concept of a

new product

or service

Product or

new service

brief

Organisations Actions

Revision

05 22

Evaluation of

the Brief

Development

of a range of

options

Definition of

the product or

service

Broad brush

analysis filters

numbers of

options

Project Teams Actions

Simplistic Feasibility studies

to determine range of

possibilities

Organisations

mission

Organisations

strategy

Organisations

goals &

objectives

Organisations

need to grow

or survive

Concept of a

new product

or service

Product or

new service

brief

Organisations Actions

Revision

Project Authorisation

gateway

05 23

Reminder

• The PM role is to convert or break down the sponsors project brief into a form that everyone understands. OR - From concept into realism.

• Then to allocate resources (teams) to determine if it is possible produce what is needed, if it is feasible and if reality can be achieved within the projects budget costs at the desired level of quality.

Generating Scenarios for Feasibility Evaluation

24

A project scenario is a brief description of a proposal, process or a set of procedures that should meet the identified objectives shown in the brief.

For every objective there are a number of possible strategies: e.g. the objective of eating can be met by the preparation of food, BUT, there are a number ways to do this, each is an option.

Developing scenarios can be a brainstorming activity, then each idea generated undergoes critical examination & modification. Then, selected or reject.

25

Feasibility Analysis

Options can be evaluated and scored by using

STEEP factors.

S =

T =

E =

E =

P =

Social

Technological

Ecological

Economic

Political

26

Feasibility Analysis

1. Technical Feasibility;

2. Financial Feasibility;

3. Risk & Uncertainty Feasibility.

4. Environmental feasibility

The most frequently used evaluates these three

key areas, BUT others might well be used!

27

Process

Project Brief Generate Scenarios

Undertake Feasibility Studies for Each Scenario

Technical Feasibility Study

Financial Feasibility Study

Risk & Uncertainty Feasibility Study

Collate Results

and Select Best

Scenario by

Weighted Analysis

Comprising of:

28

Project Brief

Generate Scenarios

Feasibility Study

Technical Feasibility

Financial Feasibility

Risk & Uncertainty

Feasibility

Feasibility Study Feasibility Study

Technical Feasibility Technical Feasibility

Financial Feasibility Financial Feasibility

Risk & Uncertainty

Feasibility

Risk & Uncertainty

Feasibility

Select Best Option by Weighted Analysis

Project Brief

Generate Scenarios

Feasibility Study


Financial Feasibility

Risk & Uncertainty

Feasibility

Feasibility Study Feasibility Study

Technical Feasibility Technical Feasibility

Financial Feasibility Financial Feasibility

Risk & Uncertainty

Feasibility

Risk & Uncertainty

Feasibility

Select Best Option by Weighted Analysis

29


• A Technical feasibility study can only be based upon current

information concerning the product, material, or services life.

Information availability stages are:

– Fully mature – considerable data is available for evaluation of new

proposal.

– Semi-mature – limited data available to be used in feasibility study.

– New Technology – at prototype stage, limited information available.

30

2. Financial Feasibility

• Questions asked:

– Will the investment of resources in a particular

project be worthwhile, then:

– How worth-while?

• Where there is a range of several alternative

opportunities for investing resources:

– which one gives the best rewards?

31

Two Sets Finance!

• PM team have to consider:

• Development - The cost of the project to produce the product, some options will consume more resources than others, this reflects onto recovery time and product cost.

• Production -The cost to produce the project after hand-over to the sponsor (post-project).

32

3. Risk & Uncertainty Feasibility.

Risk is an inherent and characteristic of all projects, some even claim that Project Management is really Risk Management.

Essentially there are two aspects of project risk control:

Risk

Risk Management Risk Identification &

Analysis

Requirements Planning and

Management • This is necessary to ensure:

– the set of requirements activities undertaken are the most appropriate,

given the unique circumstances of the project,

– the requirements work effort is coordinated with the other work being

done for the project,

– the whole requirements team on a project has a common understanding

of what activities they are undertaking,

– business analysts are able to monitor and react to requirements challenges

and slippage,

– the tools, resources and requirements contributors are available as needed

for the requirements activities,

– and, changes are captured correctly and consistently.

Requirements Gathering

Requirements Analysis and

Documentation • Analyze functional requirements

• Analyze non functional requirements

• Process/flow models – Workflow models

– Flow charts

• Usage models – Storyboards,

– Use cases

• Requirements attributes

• Requirements traceability

Requirements quality

• Lightweight

• Availability <99%

• High quality

• Success ration 0.98

• Range >500 mL

• 100 reliable

Which of the following are valid

requirements ?

Enduring and volatile requirements

40

• Enduring requirements. Stable requirements

derived from the core activity of the customer

organization. E.g. a hospital will always have

doctors, nurses, etc.

• Volatile requirements. Requirements which

change during project or when the product is in

use. In a hospital, requirements derived from

health-care policy

Classification of Volatile

requirements

• Mutable requirements, requirements that change

due to the changing of system’s environment

• Emergent requirements, requirements that

emerge as understanding of the system develops

during the system development.

Statement

of Needs

Functional

Requirements and

Statement of Services

Detailed requirements for the

system’s functionality and constraints

as required as a basis for individual component

development/acquisition

Requirements Explosion

Declaration of

required miracle

Operational View

formulation

Detailed

requirements

10

Requirements

100

Requirements

1000 Requirements

Level of detail

Α.Cockburn, Writing Effective Use Cases

43

Requirements Communication

• Determine the appropriate requirements format

• Create a requirements package

• Conduct requirements presentation

• Conduct a formal requirements review

• Obtain consensus and signoff on the

requirements

Requirements validation

45

• Concerned with demonstrating that the requirements define the system that the customer really wants

• Requirements error costs are high so validation is very important

– Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error

– Change requirement error means change system design and implementation

Requirements checking (types of checks

should be carried out on requirements)

46

• Validity. Does the system provide the functions which best support the customer’s needs?

• Consistency. Are there any requirements conflicts?

• Completeness. Are all functions required by the customer included?

• Realism. Can the requirements be implemented given available budget and technology

• Verifiability. Can the requirements be checked? In order to reduce potential dispute نزاع between customers.

Purpose of review

• The purpose of the review should be clearly stated and may encompass any of the following: – completeness of requirements (all requirements have been

captured)

– removal of superfluous requirements

– clarity of requirements (removal of ambiguity)

– correctness of requirements (the requirement reflects the business need or business rule)

– scope (the requirement fits within the stated scope of the project)

– conformance to project/organisational quality standards

– feasibility of requirements

– prioritization of requirements

Roles in review

Requirements Implementation

• Develop alternate solutions

• Evaluate technology options

• Facilitate the selection of a solution

• Ensure the usability of the solution

• Support the Quality Assurance process

• Support the implementation of the solution

• Communicate the solution impacts

Effective requirements practice

• A clear understanding of the needs of users, customers and stakeholders

• A collaborative relationship between the users, customers and stakeholders

and the technical team

• A strong commitment of the requirements development team members to

project objectives

• Use of a repeatable requirements process that is continuously improved

• A system architecture that supports the users, customers and stakeholders

current and planned needs

• The ability to accommodate changes in requirements as they are

progressively elaborated

• System development cost savings, accurate schedules, customer satisfaction

A small Example

The Project Brief

• Your only child is turning three on Saturday and

is having a big party.

• Caters are arranged but we need a clown to

entertain the guests.

• It has been suggested you have contacts in this

area.

• Arrange a clown.

A clown must wear a bright red and white

checked costume with big yellow buttons, a

pointed hat with a rainbow coloured pompom.

His shoes must be large with curly green ends

and he needs a red nose, big red glasses and

brown belt with a large gold buckle and if he can

talk he must tell jokes otherwise he must be able

to juggle balls or hoops.

The Clown Requirement



pointed hat with a rainbow coloured pompom.

His shoes must be large with curly green ends

and he needs a red nose, big red TRICKY

glasses and brown belt with a large gold buckle

and if he can talk he must tell jokes otherwise he

must be able to juggle balls or hoops.

The Clown Requirement

Verification



pointed hat with a rainbow colored pompom. His

shoes must be large with curly green ends and

he needs a red nose, big red OPTICAL glasses

and brown belt with a large gold buckle and if he

can talk he must tell jokes otherwise he must be

able to juggle balls or hoops.

Pants and

Jacket

Noses

Belts

Shoes

Hats

Bookings Transport Training

Business

Rules

pompom

REQUIREMENT DOWNSTREAM DELIVERABLES





he needs a red nose, big red TRICKY glasses




Pants and

Jacket

Noses

Belts

Shoes

Hats


Business

Rules

pompom

TRACEABILITY

CHANGE IN LEGISLATION

Green ACT

All Clowns must have GREEN Noses





he needs a GREEN nose, big red TRICKY

glasses and brown belt with a large gold buckle

and if he can talk he must tell jokes otherwise he

must be able to juggle balls or hoops.

Pants and

Jacket

Noses

Belts

Shoes

Hats


Business

Rules

pompom

TRACEABILITY

A Clown

A clown must:

Wear a bright red and white checked costume:

The clown costume must have big yellow buttons.

The clown must wear a hat:

The clowns hat must be pointy;

The end of the clowns hat must have a rainbow colored pompom.

The clowns must have shoes:

The clowns shoes must be large;

The end of the clowns shoes must be green;

The end of the clowns shoes must be curly.

The clown must have a red nose.

The clown must have big red TRICKY glasses.

The clown must have a brown belt:

The clowns belt must have a large gold buckle.

If a clown can talk the clown must tell jokes.

If a clown cannot talk the clown must be able to juggle balls or hoops.

A Clown

A clown must:

Wear a bright red and white checked costume.



The clowns hat must be pointy.






The clown must have a red nose.


The clown must have a brown belt;


If a clown can talk the clown must tell jokes

If a clown cannot talk the clown must be able o juggle balls or hoops

Pants and

Jacket

Noses

Belts

Shoes

Hats


Business

Rules

pompom

TRACEABILITY

A Clown

A clown must:










The clown must have a GREEN nose.






Pants and

Jacket

Noses

Belts

Shoes

Hats


Business

Rules

pompom

TRACEABILITY





he needs a red nose, big red TRICKY glasses




Pants and

Jacket

Noses

Belts

Shoes

Hats


Business

Rules

pompom

ORPHAN REQUIREMENT

A Clown

A clown must:










The clown must have a GREEN nose.






Pants and

Jacket

Noses

Belts

Shoes

Hats


Business

Rules

pompom

TRACEABILITY

Automatic

Traceability in

DOORS

66

Requirements Prioritization

The need

• When having tens, hundreds or even thousands of

requirements alternatives, decision-making becomes

much more difficult

• One of the keys to making the right decision is to

prioritize between different alternatives. It is often not

obvious which choice is better, because several aspects

must be taken into consideration

Requirements Prioritization

• Ensures the functionality with the most value is

implemented when timelines become short

• Helps to manage competing demands

• Helps PM to manage time, cost and resources and move

lower-priority requirements to later phases, releases

TIP: “Avoid ‘decibel prioritization’, in which the loudest

voice heard get top priority, and ‘threat prioritization’, in

which stakeholders holding the most political power

always get what they demand.”

69

Approaches to Prioritization

• Ask questions: – Is there some other way to satisfy the need that this requirement

addresses?

– What would happen if this requirement isn’t implemented right away?

– How would the deferral of the requirement affect the user community?

• Use Priority Scales – High – Must be in the first release

– Medium – The business needs the functionality however can wait if necessary – can be implemented in the next release

– Low – The user can live without the functionality and it can be implemented in later releases

70

Prioritization – Value, Cost, Risk You can use a prioritization matrix.

Relative Weights: 1 1 1 1

Feature or Function (don't mix

them use either feature or

function or use case)

Relative

Benefit

Relative

Penalty

Total

Value

Value

%

Relative

Cost

Cost

%

Relati

ve

Risk

Risk

% Priority

<List each feature, requirement, or use

case to be prioritized 1 2 3 15.8 50 37.0 1 14.3 0.308

in these cells, one item per cell. Copy and

insert additional 3 1 4 21.1 22 16.3 3 42.9 0.356

rows as needed; the formulas will adjust

automatically.> 4 1 5 26.3 7 5.2 2 28.6 0.780

6 1 7 36.8 56 41.5 1 14.3 0.661

Totals 14 5 19 100.0 135 100.0 7 100.0 2.104

Source: http://www.processimpact.com/goodies.shtml

http://www.processimpact.com/goodies.shtml

71

Prioritization on Basis of Value • Have the business estimate the benefits that each requirement provides

them (e.g. rate 1-9)

• Working with the business and I.T. estimate the penalty if the requirement

isn’t included. Assess based on quality issues, legal, compliance, function

loss that would affect productivity, harder to add capability later, other

issues such as marketing, corporate communications

• Ask the business/I.T. to weight the requirements

• Ask, is the cost a factor?

• Calculate using spreadsheet

Value%

(cost% * cost weight) + (risk % * risk weight) Priority =

Or other techniques

• Group voting

• 100 dollar method

– What you can buy with 100 dollar

– One should only perform the prioritization once on the same set of

requirements, since the stakeholders might bias their evaluation the

second time around if they do not get one of their favorite requirements

as a top priority

• Top-Ten Requirements

– In this approach, the stakeholders pick their top-ten requirements (from a

larger set) without assigning an internal order between the requirements

73

Or You Could Use …

Change management

Change management

• Any stakeholder of <project> can submit the following types of issues to the change control system:

– requests for requirements changes (additions, deletions, modifications, deferrals) in software currently under development

– reports of problems in current production

– requests for enhancements in current production systems

– requests for new development projects

Change

management

process

Submitted

Evaluated Rejected

Approved

Change Made

Verified

Closed

Verifier has confirmed the change

Modifier has installed modified work products

verification failed

Modifier has made the change and requested verification

no verification required; Modifier has installed modified work products

CCB decided to make the change

CCB decided not to make the change

Evaluator performed impact analysis

Originator submitted an issue

Canceled

change was canceled;

back out of modifications





• The CCB decided to implement the request and allocated it to a specific future product release. The CCB Chair assigns Modifier. Approved

• The Originator or someone else decided to cancel an approved change. Canceled

• The Modifier has completed implementing the requested change. Change Made

• The change made has been verified (if required), the modified work products have been installed, and the request is now completed. Closed

• The Evaluator has performed an impact analysis of the request. Evaluated

• The CCB decided not to implement the requested change. Rejected

• The Originator has submitted a new issue to the change control system. Submitted

• The Verifier has confirmed that the modifications in affected work products were made correctly. Verified

Change status severities

• Minor – Cosmetic problem, usability improvement, customer can live with

the problem (default)

• Major – Problem adversely affects product functioning, but a workaround

is available; customer will be annoyed; serious usability impairment;

• Critical – Product does not function at all; the wrong results are generated;

• Emergency – Anything that requires a change to be made immediately,

bypassing the change control process temporarily

Project charter

Project Charter

• Agreement between the organization providing

the product or service, and the customer

organization requesting and receiving the

project deliverable.

• Tool to obtain commitment from all affected

groups and individuals within a specific project.

• Does not change throughout the project life

cycle.

Project Charter Structure

• The project typically consists of four primary

sections:

– Project identification and scope

– Authority and resource need definition

– Project roles and responsibilities

– Project structure and schedule

Project Charter - Example

PROJECT SCOPE

• Project name/title: Membership Recruitment Task Force

• Background/Introduction/Purpose:

In the past two years, membership has decreased 5%. This team is being called together to develop a strategy to increase member retention and to add 100 new members in the next two years.

• Scope Statement (Expected results/desired outcomes):

The membership committee will develop a strategy and action plan to increase member retention and add at least 100 new members by June 2005.

Project Charter – Example Contd.

AUTHORITY AND RESOURCES

• Who has the authority to make decisions and allocate funds?

The committee has the authority to spend up to $5,000 for this project. The committee is empowered to do what it takes to get the task done.

• What personnel resources are needed?

A consultant who is a specialist on membership retention and recruitment

One pro-active member from each of the regional chapters (8 people)

A marketing specialist from our membership (1 person)

Team leader (1 person)

• What is the budget?

Consultant ($2500), Marketing materials ($1500), Meetings ($1000)

• What is the time needed?

Six months

Project Charter – Example Contd.

ROLES AND RESPONSIBILITIES

• Research and select a consultant to work with committee (Tom, Mary and Bill—by Jan 1st)

• Develop membership calling campaign in each region (8 regional committee persons responsible) Membership phone campaign in June

• Develop marketing material (Tom—by April 1st)

• Mail out marketing materials to all present and past members in May

PROJECT SCHEDULE

• January 15th – Consultant retained

• February 10th Survey completed for approval

• March 1st – Survey mailed out

• April 1st – Marketing material completed

• May 1st – Mail out marketing materials

• June – Conduct phone campaign

Summary – Project Charter

Work break down structure

87

WBS Definition

•A deliverable-oriented grouping of project elements that

organizes and defines the total scope of the project work.

•Work not in the WBS is not in scope of the project.

•Each descending level represents an increasingly

detailed description of the project elements.

•Often used to develop or confirm a common

understanding of project scope.

88

Where the WBS Fits

Initiate

Plan

Execute

Control

Close Strategic

Tactical

Physical

Approaches to Developing WBSs

89

• Using guidelines: some organizations, like the DOD, provide guidelines for

preparing WBSs

• The analogy approach: review WBSs of similar projects and tailor to your

project

• The top-down approach: start with the largest items of the project and break

them down

• The bottom-up approach: start with the specific tasks and roll them up

• Mind-mapping approach: mind mapping is a technique that uses branches

radiating out from a core idea to structure thoughts and ideas

Making Brownies 1. Prepreparation 1.1 Read recipe

1.2 Check ingredients at home

1.3 Make shopping list

1.4 Go on shopping trip 2. Preparation

2.1 Gather tools

2.2 Gather ingredients

2.3 Mix ingredients

2.3.1 Melt butter and chocolate

in microwave

2.3.2 Mix other ingredients in

bowl

WBS Examples

2.4 Grease pan

2.5 Preheat oven

2.6 Pour batter in pan 3. Baking Process

3.1 Bake in oven

3.2 Test with toothpick

3.3 Remove from oven

3.4 Turn off oven 4. Cleanup Process

4.1 Wash dishes

4.2 Cool brownies





2.1 Gather tools


2.3 Mix ingredients


in microwave


bowl

WBS Examples

2.4 Grease pan

2.5 Preheat oven


3.1 Bake in oven




4.1 Wash dishes

4.2 Cool brownies





2.1 Gather tools


2.3 Mix ingredients


in microwave


bowl

WBS Examples

2.4 Grease pan

2.5 Preheat oven


3.1 Bake in oven




4.1 Wash dishes

4.2 Cool brownies

How I should break down the

project? • Geographically separated areas for product or

activities

• Major chronological time periods

• By structural, process, system, or device components

• By “intermediate” deliverables required in the production of the “end” deliverables

• By separate areas of responsibility, departments, or functional areas

Benefits of the WBS

91

WBS

Estimates

Schedule

Project Plan

Risk and Contingency

Plans

Progress Reports

Activity List

Risk Control

Project Control Change

Control

Communication Control

92

Common Approaches

Brainstorming all work

to be done and then

grouping into a

hierarchy.

Bottom Up

Using a general-to-

specific structure to

progressively detail the

work.

Top Down

Bottom up

WBS Development

NO

Yes

1. Create the “to-do”

list of work.

2. Organize the

“to-dos”.

3. Review and Adjust

with group.

4. Correct

and

Complete?

WBS Complete

16

Top Down WBS

Development

1. Choose your

model.

2. Verify highest level

Deliverables/Phases.

4. Review, Verify and

or modify the

next subsequent level.

3.

Can adequate

ests. be made at

this level?

WBS Complete Yes

No

5. Confirm lowest

level.

25

Top Down 1. Choose your model

• Review various:

life cycle models,

similar project’s WBS, or

life cycle templates.

• Choose a model closest to

your specific project.

26

2. Verify highest level phases/deliverables Top Down

Start at the top of a model

- Deliverables

• Verify deliverables represent the major

phases of your project,

• Verify purpose/need of each major deliverable or phase,

• Determine if a previous project completed

a major deliverable, e.g. Feasibility.

• Choose to: eliminate or modify deliverable after review of

previous completed work

28

Note* This step’s question means

- different levels of

decomposition are appropriate

for each

of the major deliverables/phases.

• Can it be completed within a

2 – 3 week period?

• Adequate may change over

the course of the project.

• Estimating a major work

package that will be produced

6 – 12 months out may not be

possible.

Top Down

“Yes” Decisions Guidelines

3. Can adequate estimates

be made at this level?

29

Top Down 4. Review, verify and or modify the

next subsequent level.

• Verify, from the model, the next

subsequent level’s, more specific work detail.

• Choose the appropriate work elements.

elements should be described in tangible, verifiable results in

order to facilitate the

project progress.

• Repeat step 3 for each work element that you

have chosen necessary for the project.

30

5. Confirm lowest level

Can the item be scheduled? Budgeted? Assigned

to a specific organizational unit (e.g., department,

team, or person)?

If no, combine items, add to,

delete, redefine.

If no, revise or expand the

descriptions

If no, the item must be modified,split,

redefined.

Top Down

Are the lower-level items both necessary

and sufficient?

Does the work item

description provide

a scope?

31

100

Top Down

• Requires more up front discussion.

• Terminology & structure

can get in the way.

• Decreases participation.

• Slower to start.

Lesson Learned

Bottom Up

• Easy to start.

• No terminology issues.

• Higher participation.

• What do we do with this?

What’s Next?

101

– Briefly describe each item

– Reference by number

– List associated activities

– List milestones

– List other information needed

to facilitate work

Further decomposition into a WBS Dictionary

WBS Summary

• Defines the hierarchy of deliverables

• Supports the definition of all work required to implement

deliverables

• Graphical representation of project scope

• Framework for all deliverables

• Framework for schedule and cost calculations

• Facilitates assignment of resources

• Facilitates reporting

• Provides a framework for project evaluation

Example

Annotated example

WBS representation

An exercise

• Create a WBS for creating “brownies”

Brownies WBS

Example WBS/phase

DETAILED WBS EXAMPLE

CUSTOM SYSTEM DEVELOPMENT

Develop

4.0

Online

Processes

4.1

Integration

Testing

4.5

System

Interfaces

4.3

User & Tech

Documentation

4.6

Screen

Development

4.1.1

Program

Development

4.1.2

Batch

Processes

4.2

Conversion

Programs

4.4

4.1.1.1.

Dev elop & Test

Screen A

4.1.1.2.

Dev elop & Test

Screen B

4.1.1.3.

Dev elop & Test

Screen C

4.1.2.1.

Dev elop & Test

Program A

4.1.2.2.

Dev elop & Test

Program B

4.1.2.3.

Dev elop & Test

Program C

4.1.2.4.

Dev elop & Test

Program D4.1.1.4.

Dev elop & Test

Screen D

4.3.1.

Dev elop & Test

Interf ace Pgm A

4.3.2

Dev elop & Test

Interf ace Pgm B

4.3.3

Dev elop & Test

Interf ace Pgm C

4.3.4

Dev elop & Test

Interf ace Pgm D

4.4.1.

Dev elop

Conv ersion Plan

4.4.2.

Dev elop & Test

XY Z Conv ersion

Programs

4.5.1.

Plan Test

4.5.2.

Establish Test

Ev ironment

4.5.3.

Implement Test

Tools

4.6.1.

Dev elop User

Manual

4.6.2.

Dev elop

Production

Documentation

4.6.3.

Dev elop Disaster

Recov ery

Documentation4.5.3.

Dev elop Test

Reports

4.5.3.

Execute Test

Other tools

• Scope Matrix – Requirements inventory

• Deliverable Tracking Matrix

../Background/Scope Management - Requirements/deliverables.doc