TSD-Sep-2005-SPM02

Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 1

Wednesday, April 12, 2023

DETAILED PLANNING -

Overview & WBS



4.1 - Detailed PlanningOverview

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

4.2 - The Work Breakdown Structure

5 - Size Estimates -- Lines of Code / Function Points

6 - Effort, Schedule and Cost Estimating------------------------------------------------------------------------------------------------------------------------------------------------------------------

7 - Scheduling

8 - The Software Development Plan



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 framework3. The living document principle: Plans must be maintained as living documents or

they quickly lose their value



The GeneralManagement Process

Plan

Monitor

DoAssess

PlansNew

Knowledge

MetricsInformation

Knowledge



Detailed Planning Process

DetailedPlanning

•Goals•Lifecycles•High level Schedule•Complexity Model•Communication Model•Process Model•SOW / Contract•Requirements•Expectations•Commitments•Risks

PEOPLEMANAGEMENT APPROVAL

TRAININGFACILITIES

CONSENSUS

•WBS (Work Breakdown Structure)

•Estimates of Size & Cost

•Detailed Schedule

•SW Development Plan

•Risks



Understandthe Need

JOB AIDS

•Market Analysis

•Commitment

•Statement of Work

•Statement of Requirements

•Tests

•Expectations

•Process (hi level)

•Risks

MANAGEMENT INSIGHT & DECISIONS

BUSINESS PLANS AND OBJECTIVES

TRAININGFACILITIES

•Customer Needs

or

•RFP

or

•Draft SOW

or

•Product Ideas

RESEARCH



Detailed Planning inGovernment Contract Context

Carry OutNext

Phase Previous Phase

RFPfor

NextPhase

WriteProposal

ContractorSelection

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

}}



Objective of Detailed Planning

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

Who?

When?

How?



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

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



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

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

• Newspaper Headline:

“Electric Rates Rise by $120 million”



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

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

• Newspaper Headline:

“Electric Rates Cut by 3 cents -- big deal!”



Ways to get Wrong Conclusions

• Lack of Data

• Missing Facts

• Distorted Facts

• Opinions without substantiation

• Biases

• Lack of Visibility

• etc. Truth

Bias

Opinion

Guess



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



The Big Picturefor Software Estimating

Where Isthe

Software?

How MuchTime is

Required?

How Bigis the

Software?

How MuchEffort is

Required?

How MuchWill itCost?

WBS Size

Effort

ScheduleIs This

Realistic?Cost

No: rethinkassumptions

or renegotiate

YesDone



The Big Picturefor Cost Estimating

WBSSize

Effort

ScheduleCost

Yes

Where Isthe

Software?

How MuchTime is

Required?

How Bigis the

Software?

How MuchEffort is

Required?

How MuchWill itCost?

Is ThisRealistic?Done

No: rethinkassumptions

or renegotiate



The Work Breakdown Structure (WBS)

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

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.



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 manner

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.



Top Level Role of WBS

SourceDocuments

(SOW, Requirements,

contract, test criteria,

etc,)HistoricalRecords(at end

of project)

WBS

CostEstimate

(proposal &/project start)

CostTracking(during

execution)



An example of a WBSShown as a Tree

Query PopulateCreate aDatabase

Information Kiosk

UserInterface

ManageSoftware

Development

Build SISSoftware

Build TestSuite

WriteDocumentation

WriteInstallationSoftware

Software forSIS



An example of a WBSShown as Indented Text

1.0 Software for SIS 1.1 Build SIS Software 1.1.1 Build a User Interface 1.1.2 Create a Database 1.1.3 Write Query Processing Scripts 1.1.4 Populate the Database 1.1.5 Interface with Information Kiosk 1.2 Build the Test Suite for SIS 1.2.1 etc. 1.3 Write Documentation 1.4 Write Installation Software 1.5 Manage the Above



Example of an Additional Level of Detail in a WBS

1.0 Software for SIS 1.1 Build SIS Software 1.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 Interface 1.1.2 etc.



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.



Why Do a Work Breakdown Structure? Purposes:

- 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

- To facilitate planning, estimating and scheduling of the project

- To provide a basis for data monitoring and historical data collection

- To identify contractual tasks and deliverables



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

• 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



Additional WBS Terminology

• Activity

• Work Package

• Cost Content Summary

• WBS Dictionary

DO X

DO Y

DO Z

DO Q

STORAGE



The Activity

Definition: an activity is a specific task to be performed.

Activities occur at all levels of the WBS.

Generally, each activity corresponds to some documented work requirement, such as a SOW paragraph

However, some activities are merely implied– Management

– Acquisition of resources

– Details of development process

– . . .



The Work Package

Definition: the work package is a bottom-level or “atomic” activity in the WBS

This represents a task or group of tasks whose costs will be tracked and estimated together

Work Package



Typical Work Package Properties

• Associated with a concrete event or milestone when starting and when complete

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



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



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



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

• 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



Cost Content Summary

Definition: a description of a work package and a rationale for its cost estimate

Example:

Cost Content Summary

Item: 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



WBS Dictionary

Definition: a supplement to the WBS that provides additional detail for each WBS activity

Typical contents for a given activity:– Inputs

– Outputs

– Performance Goals (if any)

– Reviews

– Exit or Completion criteria

– Detailed description (if a work package)

– Sub-activities that make up this activity

Some of the contents are determined by the process to be followed



Example WBS Dictionary for a bottom level WBS activity(i.e., a work package)

Name: Design the File system (for compiler)WBS #: 1.1.3.2Performance Goal: 3 monthsInputs: requirements specification for file systemOutput: file system design descriptionReviews: preliminary design review, detailed design

review, plus intermediate peer reviewsExit 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. .............



Example WBS Dictionary for an intermediate WBS 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)



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

4) Support the comparison of actual performance with target values

5) Motivate people to meet targets



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

• 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



Construction of a WBS(high level view)

1) Develop (or refine) the WBS

2) Trace the WBS to the source documents

3) Perform (or update) cost and schedule estimates

4) Determine if WBS is consistent with cost and schedule data

5) Identify Risks

6) Repeat as necessary– To correct discrepancies

– To refine during replanning



Develop a WBS

1) The Software Hunt -- Go through the SOW, rqmts. document, etc. and make a complete list of all items that impact the cost of doing the software

Document Paragraph Description

SOW 1.3.4 Design Software for Compiler

SOW 2.3.3 Travel for Design Reviews

...

Contract 7.13.2.a Follow ISO Standard 5432f

Rqmts. Doc. 3.4 Use data compression

...

Customer Mtg. on 3/5/95 Code all software in C++



Source Documents

Don’t forget that there are many possible source documents

SOW - usually the best item to start with

Specifications

Concept of Operation documents

Requirements Documents of Many Kinds

Design Documents

Standards (internal and external)

Customer Conversations

Test Criteria or Expectations



Develop a WBS

2) Determine the WBS for the company or the project (system) and how software fits in– Many organizations have a standard WBS architecture

– If your organization does not have a standard, 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.



WBS with Software Embedded 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.



WBS with Software Separate

System

Software Electrical Mechanical Mgt.

Editor etc.Compiler

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



Develop a WBS

3) Determine a logical structure for the software portion (s) of the WBS– many organizations have standard architectures to

facilitate collection of costs across the organization

– different software products (configuration items) may need different WBS structures



Some “Standard” Architectures for a Software WBS

All Software All Software

Products Organizations

Components Products

Process Steps ...

All Software All Software

Process Steps Products

Products Organizations

Components ...



Develop a WBS

4) Populate the chosen WBS structure with tasks that address the work identified in the SOW, etc. (from step 1).

5) (optional) Add a column to the data gathered in step 1 to record the corresponding WBS number, so you can have a WBS - to - source documents trace.

Doc Parag WBS# Description

SOW 1.3.4 1.1.2.2 Design Software for Compiler

SOW 2.3.3 1.7.1 Travel for Design Reviews

...



Develop a WBS

6) (optional) Determine the cost estimating category for each element in the WBS.

Doc Parag WBS# Description Category

SOW 1.3.4 1.1.2.2 Design Software for Compiler S

. . . . . . . . . . . .

SOW 2.3.3 1.7.1 Travel for Design Reviews C

. . .

See Assignment 4 for sample cost categories

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



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

• 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



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.

• The standard WBS acts as a reminder not to forget things like these.



Examples of WBS issues

Issue: customer requires that the design document be written in a specific format that your process does not require

Option 1: include cost of this in basic cost estimate for software development– may make your productivity rate a bit lower

Option 2: include incremental cost of producing this format as a separate WBS item– this shows the customer what it costs

– but be prepared to reduce the cost accordingly if the customer says “OK, use your own format.”




Issue: configuration management is a significant overall cost, but a minor increment to individual component cost estimates

Option 1: include cost of this in basic cost estimate for each software development task– tends to create a lot of very small work packages

Option 2: include CM cost as a separate item at a higher WBS level (for example, at the level where you show project management)– tends to obscure the details of what it costs, and makes

the total look large

– invites arbitrary cuts in CM cost




Issue: customer or program manager requires a WBS format or architecture that does not conform with organizational standard

Option 1: put WBS in a spreadsheet and organize both ways (separate column for each numbering system) – use “sort” command to produce WBS in either format

Option 2: negotiate to see if they will accept your standard format



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 later, after cost estimating is complete)

• etc.

• etc.



Using the WBS Trace Matrix

1) Sort by SOW paragraph and make sure each task is covered in the WBS, etc.

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)



One More Note

If a single SOW paragraph is reflected in several WBS elements (or vice versa), you can make several separate entries in the cross reference matrix.

Doc Parag WBS# Description

SOW 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

[In this example, perhaps SOW 1.3.4 says “design software”]



Risks in Preparing a WBSPage 1 of 2

• Too Much Detail– The more detail, the higher overhead of cost

monitoring and estimating– Some government customers insist on tracking all

detail that you put in the WBS -- do you really want them tracking how many weeks you spent during design reviews?

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

• Work Packages are Vague– Look for concrete starting & ending events with

specific evaluation criteria– Remember that a work package must be discrete,

trackable, and measurable



Risks in Preparing a WBSPage 2 of 2

• Excluding certain tasks– Exclusion implies 0 cost -- rarely true– When in doubt, check with others to make sure

everything is covered -- it is easy to assume someone else covered it

– If you don’t know, ask. Just because you don’t know about a required task or a software component does not mean that it costs nothing.

• Duplication– 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



Risk Mitigation Approaches

• WBS inspection or walkthrough– Look for completeness, consistency, well defined

activities, etc.

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

• Trace to source documents (and, later, to cost estimate)– Check that all requirements are included and all entries

are required

• Remember that the WBS is part of the plan -- include WBS revisions in replanning activities

TSD-Sep-2005-SPM02

Documents

Transcript of TSD-Sep-2005-SPM02