february 2, 2000 cse 7315 - sw project management / chapter 4 - detailed planning overview and wbs...

February 2, 2000

CSE 7315 - SW Project Management / Chapter 4 - Detailed Planning Overview

and WBSCopyright © 1995-2000, Dennis J. Frailey,

All Rights Reserved

Slide # 1

CHAPTER 4

DETAILED PLANNING

Overview & WBSNOTICE: This material is copyrighted and may be copied

or downloaded ONCE ONLY by students who are registered in this course at Southern Methodist University or National Technological University.

February 2, 2000



All Rights Reserved

Slide # 2

4.1 - Detailed PlanningOverview

4.1 - Overview---------------------------------------------------------------------------------------------------

4.2 - The Work Breakdown Structure5 - Size Estimates -- Lines of Code / Function

Points6 - Effort, Schedule and Cost Estimating

---------------------------------------------------------------------------------------------------

7 - Scheduling8 - The Software Development Plan

Text, chapter 6

February 2, 2000



All Rights Reserved

Slide # 3

Detailed Planning in Context

Manage Risks

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Monitor Execution

February 2, 2000



All Rights Reserved

Slide # 4

Three Principles of Planning (1)

1. The precedence principle: Planning logically takes precedence over

all other managerial functions2. The effective planning principle: Plans will be effective if they are

consistent with the organization’s policy and strategy framework

(1) Reifer, Donald, “The Nature of Software Management: A Primer,” Tutorial on Software Management, IEEE Computer Society Press, 1986, p. 43.

February 2, 2000



All Rights Reserved

Slide # 5

Three Principles of Planning(continued)

3. The living document principle: Plans must be maintained as living documents or they quickly lose their value

February 2, 2000



All Rights Reserved

Slide # 6

The GeneralManagement Process

Plan

Monitor

DoAssess

PlansNewKnowledge

MetricsInformation

Knowledge

February 2, 2000



All Rights Reserved

Slide # 7

Detailed Planning Process

DetailedPlanning

•Goals•Lifecycles•High level Schedule

•Complexity Model

•Communication Model

•Process Model

•SOW / Contract

•Requirements

•Expectations•Commitments

•Risks

PEOPLE

MANAGEMENT APPROVAL

TRAININGFACILITIES

CONSENSUS

•WBS (Work Breakdown Structure)

•Estimates of Size & Cost

•Detailed Schedule

•SW Development Plan

•Risks

February 2, 2000



All Rights Reserved

Slide # 8

Detailed Planning inGovernment Contract

Context

Carry OutNext

Phase Previous Phase

RFPfor

NextPhase

WriteProposal

ContractorSelection Contract

Negot-iation

Note: - overlap of previous phase with proposal activities - gap between previous phase and next phaseDETAILED PLANNING USUALLY STARTS DURING PROPOSAL!

(Initial planning should start even before that.)

time

Govern-ment

Cont-ractor

}}

February 2, 2000



All Rights Reserved

Slide # 9

Objective of Detailed Planning

To describe in detail how the project will satisfy the requirements of the

project

Who?When?How?

February 2, 2000



All Rights Reserved

Slide # 10

Risks Associated withDetailed Planning

• Incomplete or incorrect estimates due to lack of sufficient detail or lack of sufficient information– Guesstimates instead of legwork to

get accurate data

February 2, 2000



All Rights Reserved

Slide # 11

Risks Associated withDetailed Planning

• Incomplete flow of system level constraints– Example: failure to accommodate special system

limitations, financial constraints, etc.• Insufficient visibility into other parts of the

system– Hardware– Test Sets– Maintenance and Support Plans– etc.

February 2, 2000



All Rights Reserved

Slide # 12

Facts vs. Innuendo

• Fact 1: Electric Company raises electric rates by $1 per person per month

• Fact 2: There are 10 million people living in the city

• Fact 3: There are 12 months in a year

February 2, 2000



All Rights Reserved

Slide # 13

Newspaper Headline

Electric Rates Rise by $120 million!!!

“Consumer rip-off”, cries local activist.’’’’’’’’’’’’

February 2, 2000



All Rights Reserved

Slide # 14

Facts vs. InnuendoPart II

• Fact 1: Electric Company lowers electric rates by $1 per person per month

• Fact 2: There are 10 million people living in the city

• Fact 3: There are 30 days in an average month

February 2, 2000



All Rights Reserved

Slide # 15

Newspaper HeadlinePart II

Electric Rates Cut by 3 Cents“Big Deal!”, cries local activist.

’’’’’’’’’’’’

February 2, 2000



All Rights Reserved

Slide # 16

Ways to get Wrong Conclusions

• Lack of Data• Missing Facts• Distorted Facts• Opinions without substantiation• Biases• Lack of Visibility• etc. Truth

Bias

Opinion

Guess

February 2, 2000



All Rights Reserved

Slide # 17

Risk Mitigation• Review assumptions with all affected parties• Work the details. Don’t guess if you don’t

have to guess.• Communicate with those working on other

parts of the system• Plan to replan

Replanning

Plan

actions

Planning

actions

feedback

feedback for next replan

UpdatedPlan

Replanning

February 2, 2000



All Rights Reserved

Slide # 18

Detailed Planning - Processes

EstimateSize

EstimateEffort and

Cost

EstimateScheduleEvaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK

February 2, 2000



All Rights Reserved

Slide # 19

Detailed Planning - Questions

How BigIs It?

How MuchWill itCost?

How Long?What Do WeDo When?

Is ThisAcceptable?

What Do WeHave To

Do?WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

What CanWe Change? Not OK

February 2, 2000



All Rights Reserved

Slide # 20

4.2 - The Work Breakdown Structure (WBS)

Definition: A work breakdown structure is a hierarchical list of the work activities required to complete a project.

Parser CodeGenerator

FileSystem

Run TimeSystem

UserInterface

ManageSoftware

Development

Build “C”Compiler

Build TestSuite

WriteDocumentation

WriteInstallationSoftware

Software for“C” Compiler

February 2, 2000



All Rights Reserved

Slide # 21

4.2 - The Work Breakdown Structure (WBS) cont

This includes tasks for: - Software development - Software development management - Support of software development - Any other activities required to meet

customer requirements, such as creating documents, training programs, tool development or acquisition, travel, etc.


FileSystem

Run TimeSystem

UserInterface

ManageSoftware

Development

Build “C”Compiler

Build TestSuite

WriteDocumentation



February 2, 2000



All Rights Reserved

Slide # 22

Why Use a WBS?

• The WBS is the tool you use to document all work that must be done to develop and deliver the software in a satisfactory manne

February 2, 2000



All Rights Reserved

Slide # 23

Why Use a WBS?Although this information is

“redundant” with the various “source” documents (SOW,

requirements document, design document, etc.), it serves to

consolidate information from many sources into one place and into an

organized format.

February 2, 2000



All Rights Reserved

Slide # 24

The WBS Is ...

A “table of contents” for the

project.

February 2, 2000



All Rights Reserved

Slide # 25

Top Level Role of WBS

HistoricalRecords(at end

of project)

CostEstimate

(proposal &/project start)

CostTracking(during

execution)

WBSSource

Documents(SOW,

Requirements,contract,

test criteria, etc,)

February 2, 2000



All Rights Reserved

Slide # 26

An example of a WBSShown as a Tree


FileSystem

Run TimeSystem

UserInterface

ManageSoftware

DevelopmentBuild “C”Compiler

Build TestSuite

WriteDocumentation



February 2, 2000



All Rights Reserved

Slide # 27

An example of a WBSShown as Indented Text

1 Software for “C” Compiler 1.1 Build a “C” Compiler 1.1.1 Build a User Interface 1.1.2 Build a File System 1.1.3 Build a Parser 1.1.4 Build a Code Generator 1.1.5 Build a Run Time System 1.2 Build the Test Suite for the

Compiler 1.2.1 etc.

1.3 Write Documentation 1.4 Write Installation Software

1.5 Manage Software Development

February 2, 2000



All Rights Reserved

Slide # 28

1.n The compiler project1.n.1 - The basic parts of the compiler

1.n.1.1 - the steps of the development process

1.1 Build a “C” Compiler1.1.1 Build a User Interface

1.1.1.1 Analyze Requirements for User I/F 1.1.1.2 Design the User Interface 1.1.1.3 Code the User Interface 1.1.1.4 Test and Integrate the User

Interface1.1.2 etc.

Example of an Additional Level of Detail in a WBS

February 2, 2000



All Rights Reserved

Slide # 29

1.1.n - The steps of the development process 1.1.1.n - the basic parts of the compiler

1.1 Build a “C” Compiler 1.1.1 Analyze Requirements 1.1.1.1 User I/F 1.1.1.2 File System 1.1.1.3 Parser 1.1.1.4 Code Generator 1.1.1.5 Run Time System 1.1.2 Design 1.1.2.1 etc.

Alternative Example

February 2, 2000



All Rights Reserved

Slide # 30

Speculation• With object oriented and relational databases,

perhaps we could come up with a new concept of a work breakdown structure that is not hierarchical

• We could then look at things any way we wanted to, such as:– by process– by software component– by responsibility– etc.

February 2, 2000



All Rights Reserved

Slide # 31

Purposes of a WBS• To organize the work to be done• To illustrate the work to be done• To assure that all necessary work

has been identified• To divide the work into small, well

defined tasks

February 2, 2000



All Rights Reserved

Slide # 32

Why Do a WBS? • To facilitate planning, estimating

and scheduling of the project• To identify contractual tasks and

deliverables• To provide a basis for data

monitoring and historical data collection

February 2, 2000



All Rights Reserved

Slide # 33

Some Uses of a WBS• Cost Estimating

– To make sure that all tasks are estimated

– To make sure that each element of the estimate corresponds to a necessary task

– To “roll up” costs of individual elements to get total costs for sub-elements or for the system as a whole

February 2, 2000



All Rights Reserved

Slide # 34

Some Uses of a WBS cont• Cost Accounting

– Work is assigned and “charged” based on specific WBS elements

– You can then determine the actual cost of each element

• Schedule Performance– You can monitor which tasks are

complete

February 2, 2000



All Rights Reserved

Slide # 35

Additional WBS Terminology• Activity

• Work Package

• Cost Content Summary

• WBS Dictionary

DO X

DO Y

DO Z

DO Q

STORAGE

February 2, 2000



All Rights Reserved

Slide # 36

The Activity• A specific task to be performed.• Occurs at all levels of the WBS.

Activities

DO X

DO Y

DO Z

DO Q

STORAGE

February 2, 2000



All Rights Reserved

Slide # 37

Characteristics of an Activity• Generally, each activity

corresponds to some documented work requirement, such as a SOW paragraph or customer work order.

• Some activities are merely implied– Management, Acquisition of

resources, Details of development process etc.

February 2, 2000



All Rights Reserved

Slide # 38

Work Package

The Work Package• It is a bottom-level or “atomic”

activity in the WBS• Represents a task or group of

tasks whose costs will be tracked and estimated together

February 2, 2000



All Rights Reserved

Slide # 39

Typical Work Package Properties

• Associated with a concrete event or milestone

• Suitable for independent cost estimating and tracking

• Small enough to manage and large enough to be worth tracking separately

• Suitable for allocating part of the budget – people, hours, dollars, computers, etc.

February 2, 2000



All Rights Reserved

Slide # 40

Examples of Work Packages• Design of a software component• Travel to customer for interchange meetings• Management of development for an

individual software product• Quality assurance for the software product• Configuration management for the software

product

February 2, 2000



All Rights Reserved

Slide # 41

Alternative Work Packages for Configuration Management

Tasks• Configuration management for the

software product• Configuration management for a

specific software component• Configuration management for the

design phase of the life cycle

February 2, 2000



All Rights Reserved

Slide # 42

Guidelines for Selecting aWork Package

• Start with the Process – Associate each work package with a

discrete portion of the process [all or part]

• Consider the Design (high level)– Associate each work package with a

discrete portion of the software, such as a configuration item or major component

February 2, 2000



All Rights Reserved

Slide # 43

Guidelines for Selecting aWork Package (continued)

• Consider the Nature of the Work– Associate a work package with a

given type of work or payment– For example, separate travel from

equipment from development labor

February 2, 2000



All Rights Reserved

Slide # 44

Cost Content SummaryItem: Travel for Customer Interchange Meetings

WBS #: 1.5.2.3 Cost: $16,800

Description: Four trips to customer for I/C meetings. Each trip will involve 3 engineers and be 2 days long

Cost Calculation: 4 * 3 * 2 * $700/day = $16,800

Cost Content Summary• A description of a work package

and a rationale for its cost estimate

February 2, 2000



All Rights Reserved

Slide # 45

WBS Dictionary• A supplement to the WBS that provides

additional detail for each WBS activity• Typical contents for a given activity:

– Inputs, Outputs, Performance Goals & Reviews

– Exit or Completion criteria– Sub-activities that make up this activity– Detailed description (if a work package)

• Other contents are derived from the process

February 2, 2000



All Rights Reserved

Slide # 46

Example WBS Dictionary for a work package

Name: Design the File system (for compiler)WBS #: 1.1.3.2 Performance Goal: 3

monthsInputs: Requirements Specification for the file

systemOutput: File system design descriptionReviews: Preliminary design review, detailed

design review and intermediate peer reviews

Exit Criteria: File system design addresses all requirements and meets design

standardsDetailed Description:

Using the Booch method, use object oriented design technique to establish a design for the file system.

February 2, 2000



All Rights Reserved

Slide # 47

Example WBS Dictionary for a higher level activity

Name: Develop File system (for compiler)WBS #:1.1.3 Performance Goal: 8 month

scheduleInputs: Requirements specs for file systemOutput: File system codeReviews:Preliminary design review, detailed design

review, test status review, formal qualification test, internal peer reviews

Exit Criteria: File system passes functional tests based on requirements

Subtasks: Requirements analysis (1.1.3.1); design (1.1.3.2); code (1.1.3.3); integrate (1.1.3.4)

February 2, 2000



All Rights Reserved

Slide # 48

Possible Exam Questions Explain the purposes of a WBS Discuss three possible uses of a WBS, explaining each Define each of the following and explain its use:

–Work Package–Cost Content Summary–WBS Dictionary

February 2, 2000



All Rights Reserved

Slide # 49

Goals of a Good WBS (1)

1) Specify the ingredients of the project clearly and concisely

2) Identify the responsibilities of each task and its place within the whole

3) Identify project performance targets at every level

(1) Maciariello, Joseph A., “Making program management work,” Tutorial on Software Management, IEEE Computer Society Press, 1986, p. 93.

February 2, 2000



All Rights Reserved

Slide # 50

Goals of a Good WBS cont

4) Support the comparison of actual performance with target values

5) Motivate people to meet targets

February 2, 2000



All Rights Reserved

Slide # 51

Observations on the WBS• Different parts of the WBS could have

different levels of detail• Later updates of the WBS could

provide more detail than what is developed initially

February 2, 2000



All Rights Reserved

Slide # 52

Observations on the WBS cont

• Avoid making too many very small work packages– If several of them have nearly

identical descriptions, see if you can combine them.

– Each level in the WBS multiplies by 5-10 the amount of detail that must be estimated, tracked, etc.)

• Trace the WBS to the requirements

February 2, 2000



All Rights Reserved

Slide # 53

Construction of a WBS(high level view)

1) Develop (or refine) the WBS2) Trace the WBS to the source

documents3) Perform (or update) cost and

schedule estimates

February 2, 2000



All Rights Reserved

Slide # 54

Construction of a WBS(high level view) (continued)4) Determine if WBS is consistent

with cost and schedule data5) Identify Risks6) Repeat as necessary

– To correct discrepancies– To refine during replanning

February 2, 2000



All Rights Reserved

Slide # 55

Steps to developing a WBS1. The Software Hunt2. Place software in the context of a

larger WBS

3. Determine the architecture of the software portion(s) of the WBS

4. Populate the chosen WBS structure with tasks from Source Documents

5. Develop WBS to Source Documents trace matrix

6. Determine the Cost Category for each activity

February 2, 2000



All Rights Reserved

Slide # 56

1. The Software HuntGo through the source documents and make a complete list of all items that impact the cost of doing the software

Document Paragraph DescriptionSOW 1.3.4 Design Software for CompilerSOW 2.3.3 Travel for Design Reviews...Contract 7.13.2.a Follow ISO Standard 5432fRqmts. Doc. 3.4 Use data compression ...Customer Meeting on 3/5/95 Code all software in C++

February 2, 2000



All Rights Reserved

Slide # 57

Source DocumentsDon’t forget that there are many possible source

documentsSOW - usually the best item to start withSpecificationsConcept of Operation documentsRequirements Documents of Many KindsDesign DocumentsStandards (internal and external)Customer ConversationsTest Criteria or Expectations

February 2, 2000



All Rights Reserved

Slide # 58

2. Place Software in thecontext of a Larger WBS

• Many organizations have a standard WBS architecture for projects

• If not, then determine what project requirements may be applicable– For example, your project manager

may have a specific approach -- number of levels, where to show certain kinds of costs, etc.

February 2, 2000



All Rights Reserved

Slide # 59

Example: SoftwareEmbedded in Hardware

Radar

Sig. Proc. Antenna Power S. Cabinet

Computer SoftwareAnalog

This approach can result in a large number of software elements in the WBS. A spreadsheet

may be handy for tracking them all.

February 2, 2000



All Rights Reserved

Slide # 60

Example: SoftwareIndependent of Hardware

This approach may tend to isolate software planning from the rest of the system, resulting in inconsistent interpretations of requirements, etc.

System

Software Electrical Mechanical Management

Editor etc.Compiler

February 2, 2000



All Rights Reserved

Slide # 61

3. Determine the Architecture of the Software WBS

• Many organizations have standard WBS architectures to help keep track of costs consistently across the organization

• Different software products (configuration items) may need different WBS structures

continued…

February 2, 2000



All Rights Reserved

Slide # 62

Some “Standard” Architectures

for a Software WBSSoftware

WordProc.

Database

Spreadsheet

UserI/f Editor For-

matter

Rqmts Design Code Test

Software

WordProc.

Database

Spreadsheet

UserI/f Editor For-

matter

Rqmts Design Code Test

February 2, 2000



All Rights Reserved

Slide # 63

Example WBS ArchitecturesAll Software Products

Components Process Steps

All Software Process Steps

Products Components

All Software Organizations

Products . . .

All Software Products

Organizations . . .

February 2, 2000



All Rights Reserved

Slide # 64

4. Populate the WBS• Assign each activity identified in

step 1 to an appropriate place in the work breakdown structure

SOW 1.1.1 Develop C Compiler 1.0 Software for “C” CompilerSPEC 2.0 Develop Compiler 1.1 Build a “C” CompilerSPEC 2.1 User I/F for PC 1.1.1 Build a User InterfacePROC STD 3.4 Requirements Analysis 1.1.1.1 RA for User I/FPROC STD 3.5 Design 1.1.1.2 Design for User

I/F ..... ..... .....SPEC 2.2 File System 1.1.2 Build a File System .... .... ....SPEC 3.0 Test IAW Company Stds 1.2 Build the Test Suite .... .... ....SOW 2.3.4 Provide User Guide 1.3 Write Documentation .... .... ....

February 2, 2000



All Rights Reserved

Slide # 65

Document Parag WBS# DescriptionSOW 1.3.4 1.1.2.2 Design Software for CompilerSOW 2.3.3 1.7.1 Travel for Design ReviewsRequirementsSpecifications 3.1.1 1.1.2.4 Perform Quality Audit

5. Construct a Trace Matrix from the WBS to the Source Documents

• Add a WBS activity number column to the matrix constructed in step 1.

February 2, 2000



All Rights Reserved

Slide # 66

Additional (Optional) Information in WBS Trace

• Who is responsible for estimating cost• Who is responsible for development• What paragraph of the software

development plan addresses this task• What standards are to be applied in

performing this task• What is the final cost estimate for this

WBS item – Often filled in after estimating cost

February 2, 2000



All Rights Reserved

Slide # 67

Using the WBS Trace Matrix1) Sort by source document &

paragraph and make sure each task is covered in the WBS

2) Sort by WBS number and make sure each corresponds to a legitimate activity that must be performed

3) Sort by WBS and requirements document to identify all the requirements that must be met by each activity (helps in cost estimating)

February 2, 2000



All Rights Reserved

Slide # 68

Doc Parag WBS# DescriptionSOW 1.3.4 1.1.2.2 Design Software for Compiler

SOW 1.3.4 1.1.3.2 Design Software for Editor

SOW 2.3.4 1.1.3.2 Use Booch Design Method

SOW 2.3.3 1.7.1 Travel for Design Reviews

Suppose SOW 1.3.4 says "design software"and SOW 2.3.4 says "use Booch design method"

Redundancy OK in the Trace Matrix

February 2, 2000



All Rights Reserved

Slide # 69

Document Parag WBS# Description CategorySOW 1.3.4 1.1.2.2 Design Software

for Compiler S

. . . . . . . . . . . .SOW 2.3.3 1.7.1 Travel for Design

Reviews C. . . Continued...

6. Determine Cost Categories• Determine the cost category for each

element in the matrix (from step 1 or step 5) or the WBS (Step 4)

February 2, 2000



All Rights Reserved

Slide # 70

Possible Cost CategoriesCode Category Aff ects Examples

S Sof twareDevelopment

Cost&Schedule

Sof tware Design, Sof twareCoding, Sof tware Testing

SA AdditionalSof tware

Eff ort

Cost&Schedule

Sof tware Requirements,System Testing

P Sof twareSupport

Cost Sof tware Management, SQA,Confi guration Management

AL AdditionalLabor

Cost Special Audits,Document Generation

AD AdditionalDollars

Cost Travel, Development Tools,Special Equipment,

February 2, 2000



All Rights Reserved

Slide # 71

Develop a WBS - Notes

See Assignment 4 for more information

If cost category step is not done here, it needs to be done later, during the cost estimating process

February 2, 2000



All Rights Reserved

Slide # 72

Notes• There will be some items from step 1 that

are scattered throughout many WBS elements (example: use a particular standard or a particular programming language)– But costs specific to that standard or language

may be separate WBS elements -- such as purchasing a compiler or carrying out a mandated review or producing a document that would not otherwise be needed

February 2, 2000



All Rights Reserved

Slide # 73

Notes(continued)

• There may be some items from step 1 that do not seem to fit the standard WBS form– Examples: warranty costs, special testing,

...– You usually just add another element

somewhere– You may need to be creative

February 2, 2000



All Rights Reserved

Slide # 74

Notes(continued)

• Some items in the organization’s standard WBS may not be explicitly stated in source documents– Examples: training, management, facilities,

development tools• For these you determine whether they are

needed and, if so, work with your customer or system engineer to define them in statement of work or other source documents.

February 2, 2000



All Rights Reserved

Slide # 76

Examples of WBS Issues -Customer Imposed Format

Issue:Customer requires that the design document should be written in a specific format that your process does not require– It will cost you extra money and time

to do this– You will need to learn how to use the

customer’s desired format

February 2, 2000



All Rights Reserved

Slide # 77

ResolutionOption A: Include the incremental cost of producing

this format as a separate WBS item– This shows the customer what it costs– Be prepared to reduce the cost accordingly if

the customer says “OK, use your own format.”Option B: Add the cost into the basic cost of software

development– Will make your productivity rate slightly lower

February 2, 2000



All Rights Reserved

Slide # 78

Examples of WBS Issues - Representing the Cost of

Support TasksIssue: Configuration management is a

significant overall cost, but a minor increment to individual component cost estimates– How do you represent it in the

WBS?

February 2, 2000



All Rights Reserved

Slide # 79

Resolution of Support Cost IssueOption A:

Include a CM task for each software component or product– Tends to create a lot of small work packages

Option B: Include all CM cost as a separate item at

a higher WBS level. – Tends to obscure the details of what it costs,

and makes the total look large and consequently invites arbitrary cuts in CM cost

February 2, 2000



All Rights Reserved

Slide # 80

Examples of WBS Issues - Organizational Standard Not

Being FollowedIssue: Customer or program manager

requires a WBS format or architecture that does not conform with organizational standard– The standard format serves as a

checklist to be sure you are complete

– And you may be called on the carpet for violating that standard

February 2, 2000



All Rights Reserved

Slide # 81

ResolutionOption A:

Use a Spreadsheet program to sort the WBS into either format

Option B: Negotiate to see if they will accept the

standard formatOption C: Retain documentation of “non-

standard” requirement and trace your format to the standard format

February 2, 2000



All Rights Reserved

Slide # 83

Risks - IToo Much Detail• Increases overhead of monitoring

and estimation• Customers or managers might

insist on tracking based on the WBS

• You may have two WBSs to get around this: a “formal” WBS at the high level and a “working” WBS at the detail level

February 2, 2000



All Rights Reserved

Slide # 84

Risks - IIWork Packages are Vague• Look for concrete starting & ending

events with specific evaluation criteria

• A work package should be discrete, trackable, & measurable

February 2, 2000



All Rights Reserved

Slide # 85

Risks - IIIExcluding certain tasks• Make sure everything is covered

– It is easy to assume someone else covered it

• If you don’t know, ask• Exclusion implies 0 cost, which is

rarely true if you must do the task

February 2, 2000



All Rights Reserved

Slide # 86

Risks -IVDuplication of activities

• It is easy to have the same work show up in more than one place, especially on a large project

• Managers must “scrub” the WBS

February 2, 2000



All Rights Reserved

Slide # 87

Risk Mitigation Approaches• WBS inspection or walkthrough

– Look for completeness, consistency, well defined activities, etc.

– Let others see the WBS (you tend to have tunnel vision and may miss something)

• Trace to source documents (and, later, to cost estimate)

• Remember that the WBS is part of the plan– Include WBS revisions in replanning activities