Friday, October 24, 2008
DETAILED PLANNING Overview & WBS
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 1
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 2
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 3
Friday, October 24, 2008
The General Management Process
New Knowledge
Assess
Information Nitin V Pujari
Plan
Knowledge
Monitor
TSDP-Sep-2005 - Project Management
Plans
Do
Metrics Slide 4
Friday, October 24, 2008
Detailed Planning Process
• Goals • Lifecycles • High level Schedule • Complexity Model • Communication Model • Process Model • SOW / Contract • Requirements • Expectations • Commitments • Risks Nitin V Pujari
MANAGEMENT CONSENSUS APPROVAL
Detailed Planning
FACILITIES
TRAINING
TSDP-Sep-2005 - Project Management
PEOPLE • WBS (Work Breakdown Structure) • Estimates of Size & Cost • Detailed Schedule • SW Development Plan • Risks Slide 5
Friday, October 24, 2008
• Customer Needs or • RFP or • Draft SOW or • Product Ideas
Nitin V Pujari
BUSINESS PLANS MANAGEMENT AND OBJECTIVES INSIGHT & DECISIONS • Market Analysis • Commitment • Statement of Understand Work • Statement of the Need Requirements • Tests • Expectations FACILITIES TRAINING • Process (hi level) RESEARCH JOB AIDS • Risks TSDP-Sep-2005 - Project Management Slide 6
Friday, October 24, 2008
Detailed Planning in Government Contract Context
RFP for Next Phase
Contractor Selection
Write Previous Phase Proposal
Contract Negotiation
} }
Government
Carry Out Next 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.) Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 7
Contractor
Friday, October 24, 2008
Objective of Detailed Planning
To describe in detail how the project will satisfy the requirements of the project
Who? When? How? Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 8
Friday, October 24, 2008
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.
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 9
Friday, October 24, 2008
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” Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 10
Friday, October 24, 2008
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!” Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 11
Friday, October 24, 2008
Ways to get Wrong Conclusions
• • • • • • •
Lack of Data Missing Facts Distorted Facts Opinions without substantiation Biases Lack of Visibility etc. Truth Bias
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Opinion
Guess
Slide 12
Friday, October 24, 2008
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 Plan
feedback
actions Nitin V Pujari
TSDP-Sep-2005 - Project Management
Replanning Updated Plan actions
feedback for next replan Slide 13
Friday, October 24, 2008
The Big Picture for Software Estimating
Where Is the Software?
WBS
How Big is the Software?
Size
How Much Effort is Required? Effort
No: rethink assumptions or renegotiate Yes Done
Nitin V Pujari
Is This Realistic?
Cost
How Much Will it Cost?
TSDP-Sep-2005 - Project Management
How Much Time is Required? Schedule
Slide 14
Friday, October 24, 2008
The Big Picture for Cost Estimating
Where Is WBS How Big is the the Software? Software?
Size
Effort
No: rethink assumptions or renegotiate Yes Done
Nitin V Pujari
Is This Realistic?
Cost
How Much Effort is Required?
How Much Will it Cost?
TSDP-Sep-2005 - Project Management
How Much Time is Required? Schedule
Slide 15
Friday, October 24, 2008
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. Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 16
Friday, October 24, 2008
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. Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 17
Friday, October 24, 2008
Top Level Role of WBS
Cost Estimate (proposal &/ project start) Source Documents (SOW, Requirements, contract, test criteria, etc,)
Nitin V Pujari
WBS
TSDP-Sep-2005 - Project Management
Cost Tracking (during execution) Historical Records (at end of project)
Slide 18
Friday, October 24, 2008
An example of a WBS Shown as a Tree
Software for SIS
Build SIS Software
Build Test Suite
User Create a Query Interface Database Nitin V Pujari
Write Installation Software
Write Documentation
Populate
Manage Software Development
Information Kiosk
TSDP-Sep-2005 - Project Management
Slide 19
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 20
Friday, October 24, 2008
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.
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 21
Friday, October 24, 2008
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.
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 22
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 23
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 24
Friday, October 24, 2008
Additional WBS Terminology
• Activity
DO X DO Y STORAGE DO Z DO Q
• Work Package
• Cost Content Summary
• WBS Dictionary Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 25
Friday, October 24, 2008
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 ...
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 26
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 27
Friday, October 24, 2008
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.)
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 28
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 29
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 30
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 31
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 32
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 33
Friday, October 24, 2008
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. ............. Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 34
Friday, October 24, 2008
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) Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 35
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 36
Friday, October 24, 2008
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 510 the amount of detail that must be estimated, tracked, etc.) • Trace the WBS to the requirements Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 37
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 38
Friday, October 24, 2008
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++
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 39
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 40
Friday, October 24, 2008
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.
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 41
Friday, October 24, 2008
WBS with Software Embedded in Hardware
Radar Sig. Proc.
Analog
Antenna
Power S.
Cabinet
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. Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 42
Friday, October 24, 2008
WBS with Software Separate
System Software Compiler
Editor
Electrical Mechanical
Mgt.
etc.
This approach may tend to isolate software planning from the rest of the system, resulting in inconsistent interpretations of requirements, etc.
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 43
Friday, October 24, 2008
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 44
Friday, October 24, 2008
Some “Standard” Architectures for a Software WBS
All Software Products Components Process Steps
All Software Organizations Products ...
All Software Process Steps Products Components
All Software Products Organizations ...
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 45
Friday, October 24, 2008
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
... Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 46
Friday, October 24, 2008
Develop a WBS
6) (optional) Determine the cost estimating category for each element in the WBS. 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
Category S 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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 47
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 48
Friday, October 24, 2008
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. Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 49
Friday, October 24, 2008
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.” Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 50
Friday, October 24, 2008
Examples of WBS issues
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 51
Friday, October 24, 2008
Examples of WBS issues
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
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 52
Friday, October 24, 2008
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. Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 53
Friday, October 24, 2008
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)
Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 54
Friday, October 24, 2008
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”] Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 55
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 56
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 57
Friday, October 24, 2008
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 Nitin V Pujari
TSDP-Sep-2005 - Project Management
Slide 58