TSD Sep 2005 SPM02

Friday, October 24, 2008
DETAILED PLANNING -
Overview & WBS
Nitin V Pujari TSDP-Sep-2005 - Project Management Slide 1

4.1 - Detailed Planning

Overview
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 functions
2. The effective planning principle:
Plans will be effective if they are consistent with
the organization’s policy and strategy framework
3. The living document principle:
Plans must be maintained as living documents or
they quickly lose their value

The General
Management Process
New Plan Plans

Knowledge
Assess Knowledge Do
Information Metrics
Monitor
Detailed Planning Process
• Goals MANAGEMENT CONSENSUS PEOPLE

• Lifecycles APPROVAL
• WBS (Work
• High level
Breakdown
Schedule
Structure)
• Complexity
Model • Estimates of
Size & Cost
• Communication Detailed • Detailed
Model
• Process Model
Planning Schedule
• SOW / Contract • SW
Development
• Requirements Plan
• Expectations
• Risks
• Commitments FACILITIES TRAINING
• Risks
BUSINESS PLANS MANAGEMENT

AND OBJECTIVES INSIGHT & DECISIONS
• Customer • Market
Needs Analysis
or • Commitment
• RFP • Statement of
Understand Work
or
• Draft SOW
the Need • Statement of
Requirements
or • Tests
• Product • Expectations
Ideas FACILITIES TRAINING • Process (hi
RESEARCH JOB AIDS level)
Nitin V Pujari TSDP-Sep-2005 - Project Management
• Risks
Slide 6
Detailed Planning in
Government Contract Context
}
RFP
for Contractor Govern-
Next Selection ment
Phase Contract
Negot-
}
iation Carry Out
Write Cont-
Previous Phase Next ractor
Proposal Phase
time
Note:
- overlap of previous phase with proposal activities
- gap between previous phase and next phase
DETAILED PLANNING USUALLY STARTS DURING PROPOSAL!
(Initial planning should start even before that.)
Objective of Detailed Planning
To describe in detail how the project will satisfy

the requirements of the project
Who?
When?
How?

Risks Associated with

Detailed 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. Innuendo

Part 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 Opinion
• Lack of Visibility
• etc. Truth
Guess
Bias

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
Planning Replanning Replanning
Plan feedback Updated feedback

Plan for next
actions replan
Nitin V Pujari TSDP-Sep-2005 - Project Management actions Slide 13
The Big Picture

for Software Estimating
Where Is WBS How Big Size How Much

the is the Effort is
Software? Software? Required?
Effort
No: rethink
assumptions
or renegotiate How Much
Time is
Required?
Yes Is This How Much
Done Realistic? Will it Schedule
Cost Cost?

The Big Picture

for Cost Estimating
Where Is WBS How Big Size How Much

the is the Effort is
Software? Required?
Software?
Effort
No: rethink
assumptions
How Much
or renegotiate
Time is
Required?
Yes Is This How Much
Done Realistic? Will it Schedule
Cost Cost?

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
Cost
Estimate
(proposal &/
project start)
Source
Documents
Cost
(SOW, WBS
Tracking
Requirements,
(during
contract,
execution)
test criteria,
etc,)
Historical
Records
(at end
of project)
An example of a WBS
Shown as a Tree
Software for
SIS
Build Write Manage

Build SIS Write
Test Installation Software
Software Documentation
Suite Software Development
User Create a Information

Query Populate
Interface Database Kiosk

An example of a WBS
Shown 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
DO X
• Activity DO Y
STORAGE
DO Z
DO Q
• Work Package
• Cost Content Summary
• WBS Dictionary
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 a

Work 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.2 Performance Goal: 3 months
Inputs: requirements specification for file system
Output: file system design description
Reviews: preliminary design review, detailed
design review, plus intermediate peer reviews
Exit Criteria: file system design addresses all
requirements and meets design standards
Detailed 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 schedule
Inputs: requirements specs for file system
Output: file system code
Reviews: 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
Analog Computer Software
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.
Compiler Editor etc.
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 WBS

Page 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 WBS

Page 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

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TSD Sep 2005 SPM02

Загружено:

Авторское право:

Доступные форматы

Friday, October 24, 2008

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

4.1 - Detailed Planning

4.2 - The Work Breakdown Structure

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

Three Principles of Planning (1)

1. The precedence principle:

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

New Plan Plans

Detailed Planning Process

• Goals MANAGEMENT CONSENSUS PEOPLE

BUSINESS PLANS MANAGEMENT

Objective of Detailed Planning

To describe in detail how the project will satisfy

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

Risks Associated with

• Incomplete or incorrect estimates due to lack

Facts vs. Innuendo

• Fact 1: Electric Company raises electric rates

“Electric Rates Rise by $120 million”

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

Facts vs. Innuendo

• Fact 1: Electric Company lowers electric rates

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

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

Ways to get Wrong Conclusions

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

• Review assumptions with all affected parties

Plan feedback Updated feedback

The Big Picture

Where Is WBS How Big Size How Much

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

The Big Picture

Where Is WBS How Big Size How Much

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

The Work Breakdown Structure (WBS)

Definition: A work breakdown structure is a

Why Use a WBS?

The WBS is the tool you use to document all

Top Level Role of WBS

Build Write Manage

User Create a Information

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

1.0 Software for SIS

Example of an Additional Level of Detail in a WBS

1.0 Software for SIS

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

• With object oriented and relational databases,

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

Why Do a Work Breakdown Structure? Purposes:

- To organize the work to be done

Some Uses of a WBS

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

Additional WBS Terminology

• Cost Content Summary

Definition: an activity is a specific task to be

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

The Work Package

Definition: the work package is a bottom-level

This represents a task or group of tasks whose

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

Typical Work Package Properties

• Associated with a concrete event or