Transcript Document 7240626

TODAY
1.
PERT REVIEW (last part of B: Ch 7)
2. Crashing (B: Ch 8)
3. Time and Cost Estimation
PERT (Program Evaluation and
Review Technique)
Not supported by MS Project 2013
 Gives you probabilities of completion of a
project by a certain time
 Calculates a standard normal random
variate and uses a probability table to find
its probability

PERT INPUTS
A = most optimistic time
 M = most likely time
 B = most pessimistic time

PERT formulas—uses a Beta
Distribution
Task mean = (A + 4*M + B)/6
 Task Std. Dev. = (B-A)/6
 Project mean = sum of all the task means of
tasks on the critical path
 Project std. Dev = sum of all the task
standard deviations of tasks on the critical
path

Activity and Project Frequency Distributions
FIGURE A7.1
7–5
The Beta Distribution

Is a better fit that any other distribution to
the natural randomness of the task duration
– Finite tails
– Skewed—not symmetric
Crashing
1) Enumerate all of the paths in a table
showing duration of each
 2) Pick an activity on the CP (Critical Path)
with the lowest crash cost per day and crash
it to its minimum duration if possible, but
not so far back that the critical path is no
longer critical and not so far back that you
exceed the budget
 3) Show the effects on each path’s duration
in the table

4) Reduce the budget by the amount spent
on the crashing step
 5) Continue with steps two through four
until all of the budget is used up.



NEVER CRASH THE CRITICAL PATH
BEYOND THE POINT WHERE IT IS NO
LONGER CRITICAL (THAT IS, SOME
OTHER PATH HAS BECOME
CRITICAL).
Estimating: A Definition
– Forecasting or approximating the
time and cost of completing project
deliverables.
– Balancing the expectations of
stakeholders and the need for control
while the project is implemented.
Why Estimating Time and Cost Are Important
• To determine how long the project should take
and how much it should cost.
• To support good decisions.
• To schedule work.
• To determine whether the project is worth doing.
• To develop cash flow needs.
• To determine how well the project is progressing.
• To develop time-phased budgets and establish the
project baseline.
EXHIBIT 5.1
5–11
Where does Estimating occur
within PMBOK?
What process group?
 What knowledge areas?
 Can you name some of them?

Answers
The planning process group
 In the Time Management and Cost
Management Knowledge Areas
 Time Management

– Estimate Activity (Task) Resources
– Estimate Activity (Task) Durations

Cost Management
– Estimate Costs
Estimation
What are the inputs to these processes?
 What tools and techniques?
 What are the outputs

INPUTS
1. Activity list
2. Constraints
3. Assumptions
4. Resource
requirements
5. Resource
capabilities
6. Historical
information
TOOLS
1. Expert
judgment
2. Historical data
3. Analogous
estimating
4. Simulation
OUTPUTS
Activity
duration
estimates
1.
2. Basis of estimates
3. Activity list updates
Tools and Techniques
Calibration and Historical Data
 Individual Expert Judgment
 Decomposition and Recomposition
 Estimation by Analogy
 Proxy-based Estimates
 Expert Judgment in Groups
 Software Estimation Tools
 Use of Multiple Approaches

Estimation Methodologies
Most firms have their own methodology
 Standard Procedures
 Once again, what do we estimate?

–
–
–
–
Resources
Time
Cost
Effort
Some Bad Methodologies
Guessing
 Intuition, hunches
 Unstructured expert judgement
 Informal analogies


THESE ARE USED 60% TO 85% OF THE
TIME
WHAT IS MORE IMPORTANT?
What does your firm value more?

An optimistic forecast?
– Lower cost?
– Less time?

NO! A predictable, reliable forecast IS
MORE IMPORTANT!!
– Commitments depend on reliable estimates
– Commitments to customers, investors,
suppliers, the marketplace and other
stakeholders
The Cost estimation Story—
Steve McConnell

You can’t tell exactly what its going to cost
until you know exactly what

IT is.
(Which is why we spent so much time
talking about thorough product
conceptualization and definition)
Estimates depend strongly on
requirements
If you are estimating the cost of a new house,
features are an important issue—fireplace?
Granite countertops? Glass backsplashes?
Ceramic tile tub-surrounds?
 If it’s a 15-digit phone field to support direct,
long-distance international dialing, then will the
client want phone number validation? Cheap
version (USA only) or expensive?

Missing Functional Requirements
Setup/installation program
 Data conversion utility
 Glue code needed to use third-party or
open-source software
 Help system
 Deployment modes
 Interfaces with external systems

Missing Nonfunctional
Requirements
Accuracy
 Interoperability
 Modifiabillity
 Reliability
 Reusability
 Scalability
 Usabiliity

Software Activities Commonly
Missing from Estimates






Ramp-up time for new
team memberes
Mentoring of new tem
members
Cutover/deployment
Dta conversioin
Customization
Requirements
clarification






Supporting the build
Creation of test data
Management of the
beta test program
Participation in
technical reviews
Integration work
Processing change
requests
Software Activities Commonly
Missing from Estimates





Attendance at changecontrol meetings
Coordinating with
subcontractors
Performance tuning
Learning new tools
Administrative work
related to defect
tracking





Answering questions from
quality assurance
Creating user acceptance
tests
Demonstrating acceptance
tests to users
Demonstrating software at
trade shows
Demonstrating prototypes
Non-software Development
Activities Commonly Missing
from Estimates
Holidays
 Sick days
 Training
 Company meetings
 Department meetings
 Installing new versions of tools

In your project plans….

Include the above non-software activities as
contingency
– Add 10% to your project cost and duration
– You will not be showing this on your MS
Project charts
– You will do this external to MS Project
Differentiate Estimates from
Targets and Commitments
“We will have it done in three months”
 “Why three months???”
 “Because that is when the trade show
happens…”

 This
is a target—NOT AN
ESTIMATE
A commitment is NOT an
estimate
“It absolutely has to be done by August 1,
2016!!”
 “WHY?”
 “Because that is when it was promised to
the customer!!”
 THIS IS A COMMITMENT—NOT AN
ESTIMATE

Is it better to overestimate or
under estimate
Effect
Cost
Schedule
Underestimation
<100%
Overestimation
100%
>100%
Target as a Percentage of Nominal Estimate
A Rule of Thumb with regard to
Estimation of Testing
The time to design, document and code a
module =
 equals the time to debug it (TEST IT)


According to Gildersleeve
Estimating Rules (Rakos)





Get group concensus estimates if possible
Never force an estimate on a programmer
Never take an average of different estimates
Granularize down to FOUR or less weeks, roughly
Add 10% for contingency
Always
quote a range when
giving estimates
»Especially for strategic and
budgetary estimates
Rakos’ Conclusions to
Estimating
Our weakest talent
 Estimating is iterative
 Estimating is still an art

Purposes of Estimating
For strategic planning—two to five years
out—rough—for calculation of ROI, IRR,
NPV—portfolio and program management
 For budgetary purposes—two years out—
more detailed, specific, accurate
 For immediate execution of the project—
the most accurate, based on actual
assigned resource hourly rates--Definitive

Review: Project Time
Management Processes

The time management knowledge area involves
the processes required to ensure timely
completion of a project. Processes include:
– Plan schedule management
– Define activities
– Sequence activities
– Estimate Activity resources
– Estimate Activity durations
– Develop Schedule
– Control Schedule
A Task Duration Process when
no history database and no expert
is available




Assign the task to a project player
Ask the player how long it will take him or her to
complete the task (This gives the player ownership
in the planning)
Player provides their best estimate
The player understands that they will be required
to complete the task within their estimate—their
feet will be “held to the fire”
Player Time Estimation: Goldratt
Claims team players add safety to their
estimates
 What is safety??
 Safety is NOT slack
 Safety is the extra time that you add in order
to be completely certain that you will get it
done on time—like taking your estimate
and doubling it!

Estimating Projects

Types of Estimates
– Top-down (macro) estimates: analogy, group
consensus, or mathematical relationships
– Bottom-up (micro) estimates: estimates of
elements
of the work breakdown structure
5–38
Factors Influencing the Quality of
Estimates
Planning Horizon
Other
(Nonproject)
Factors
Organization
Culture
Padding
Estimates
5–39
Project
Duration
Quality of
Estimates
People
Project Structure
and Organization
Top-Down versus Bottom-Up
Estimating

Top-Down (Macro) Estimates
– Are usually derived from someone who uses
experience and/or information to determine the
project duration and total cost.
– Are made by top managers who have little knowledge
of the processes & resources used to complete the
project.

Bottom-Up (Micro) Approach
– Can serve as a check on cost elements in the WBS
by rolling up the work packages and associated cost
5–40accounts to major deliverables
A bottom-up approach using WBS
An expert is asked to estimate how much effort in
weeks is required to complete a WBS consisting
of 10 work packages
 His estimate—22 weeks, considering the project
in its entirety and not the work packages
 A team of non-experts is also asked to estimate,
but they did it on a work package-by-work
package basis
 Their estimate—27 weeks//ACTUAL: 29 weeks

Estimated weeks
to
Actual
complete
Effort
work
package
raw
error
Feature
Work 1
feature 1
1.5
3
-1.5
50%
Work 2
feature 2
4
2.5
1.5
80%
Work 3
feature 3
3
1.5
1.5
100%
Work 4
feature 4
1
2.5
-1.5
60%
Work 5
feature 5
4
4.5
-0.5
11%
Work 6
feature 6
6
4.5
1.5
33%
Work 7
feature 7
2
3
-1
33%
Work 8
feature 8
1
1.5
-0.5
33%
Work 9
feature 9
3
2.5
0.5
20%
Work 10
feature 10
1.5
3.5
-2
57%
TOTALS
27
29
-2
7%
% of error
This is taking advantage of
something you learned in
statistics—the LAW OF LARGE
NUMBERS

Decompose large estimates into small
pieces so that you can take advantage of the
Law of Large Numbers: the errors on the
high side and the errors on the low side
cancel each other out to some degree
Top-Down versus Bottom-Up
Estimating
Conditions for Preferring Top-Down or Bottom-up Time
and Cost Estimates
Condition
Strategic decision making
Top-down
Bottom-up
Macro Estimates
Micro Estimates
X
Cost and time important
X
High uncertainty
X
Internal, small project
X
Fixed-price contract
X
Customer wants details
X
Unstable scope
X
TABLE 5.1
5–44
Estimating Projects: Preferred
Approach

Make rough top-down macro estimates.

Develop the WBS/OBS.

Make micro bottom-up estimates.

Develop schedules and budgets.

Reconcile differences between top-down
and bottom-up estimates
5–45
Time Estimation--programmers
Naïve programmers have a notorious reputation
for underestimating task durations and costs
 Programmer productivities are ‘all over the map’

– Some of you can carve out 100 or more lines of code
in an hour
– The rest of us take 10 hours to create 100 lines of
code
Time Estimation—making time
for creativity: SLACK
Keep in mind that customers may endeavor
to put projects under extraordinary schedule
pressure—more functionality for the same
price.
 A consideration in schedule development is
to take the tasks requiring creativity and
place them on ____?!?

Too little time syndrome
More stress
More mistakes
More schedule pressure
missed deadlines
Needed: A Rule-based Expert
System for adjusting individual
task durations


IF ESTIMATER IS SEASONED
(EXPERIENCED) AND IF THE WORK
PACKAGE REQUIRES CREATIVITY ON THE
PART OF THE ESTIMATOR, THEN LEAVE
ESTIMATE AS IS.
IF ESTIMATER IS NOT SEASONED AND
ESTIMATE APPEARS TO BE OPTIMISTIC,
THEN INCREASE ESTIMATE BY 30%.
ANOTHER AI RULE

IF ESTIMATOR IS SEASONED AND
ESTIMATOR ASSERTS 90% OR ABOVE
CONFIDENCE HE WILL COMPLETE
WORK WITHIN HIS ESTIMATE AND IF
WORK PACKAGE DOES NOT REQUIRE
SIGNIFICANT CREATIVITY, REDUCE
ESTIMATE BY 40% -- 50%
Time Estimation: Three distinct
approaches not involving project
team members

What are the three approaches to time
estimation??
– History database
» Relates to the organizational maturity
– Expert judgment
– Computer model or formula
Project Cost Management Processes
Plan Cost Management
 Estimate Costs: developing an estimate of
the costs and resources needed to complete
a project



Determine Budget: allocating the overall cost
estimate to individual work items to establish a
baseline for measuring performance
Control Costs: controlling changes to the project
budget
Cost Estimating
We need to speak the language and
understand the terminology:
ROI, IRR, NPV, Sunk costs
Tangible and intangible costs
Direct and indirect costs
Learning curve theory
Reserves ($ included in a cost estimate to
mitigate cost risk; also called contingency
reserves)
Cost Estimating
An important output of project cost
management is a cost estimate
 There are several types of cost estimates
and tools and techniques to help create them
 It is also important to develop a cost
management plan that describes how cost
variances will be managed on the project

Top-Down Approaches for
Estimating Project Times and Costs

Consensus methods

Ratio methods

Apportion method

Function point methods for
software and system
projects

Learning curves
5–55
Project Estimate
Times
Costs
Apportion Method of Allocating Project Costs Using
the Work Breakdown Structure
FIGURE 5.1
5–56
Simplified Basic Function Point Count Process
for a Prospective Project or Deliverable
TABLE 5.2
5–57
Example: Function Point Count Method
TABLE 5.3
5–58
Bottom-Up Approaches for
Estimating Project Times and Costs

Template methods

Parametric procedures
applied to specific tasks

Range estimates for
the WBS work packages

Phase estimating: A
hybrid
5–59
Table 6-2. Types of Cost
Estimates--Kerzner
Type of Estimate
When Done
Why Done
Ho
Strategic Rough
Order of Magnitude
(ROM)
WAG
SWAG
Budgetary
Very early in the
project life cycle,
often 3–5 years
before project
completion
Early, 1–2 years out
Provides rough
ballpark of cost for
Strategic selection
decisions
–2
Puts dollars in the
budget plans
–1
Definitive
Later in the project, <
1 year out
Provides details for
purchases, estimate
actual costs
–5
Estimation in General—COST or
TIME
History data base
 Expert judgement
 a Model like CoCoMo—Constructive Cost
Model

– Developed by Barry Boehm
Proposal Pricing Strategies-Kerzner

Type I Acquisition: One of a kind project
with little or no follow-on opportunity
» win the project, perform well and make a profit

Type II Acquisition: New Program with
potential for large follow-on business or
representing a desired surge into a new
market
» win the project, perform well and gain a foothold in
a new market segment, usually at a loss
Cost Estimation Tools and Techniques

4 basic tools and techniques for cost estimates
(Schwalbe—Ch 6):
– Analogous or top-down: use the actual cost of a previous,
similar project as the basis for the new estimate
– Bottom-up: estimate individual work items and sum them
to get a total estimate
– Parametric: use project characteristics in a mathematical
model to estimate costs
– Computerized tools: use spreadsheets, project
management software, or other software to help estimate
costs
Constructive Cost Model
(COCOMO)
Barry Boehm helped develop the COCOMO
models for estimating software development
costs
 Parameters include source lines of code or
function points
 COCOMO II is a computerized model
available on the web
 Boehm suggests that only parametric models
do not suffer from the limits of human
decision-making

Stop here—will not test you on
anything else
Lefkon’s Methodology
Divide the software project into as many individual
steps/tasks/modules as possible.
2. Predict the level of effort required to complete each task and
multiply that prediction by 2.
3. Add up the numbers and multiply by 2.0 again to account for
testing and debugging.
4. Take the total and multiply by 1.25 to account for meetings,
administration, and paperwork.
5. Multiply this level of effort by your company’s “magic number”
for labor costs.
1.
Lefkon’s Methodology
6. Present this to management as a range. Take the
cost as predicted above and present the range as –
10 percent and +25 percent.
7. Stand your ground and remind management that you
did not arbitrarily come up with these numbers and
they cannot be adjusted arbitrarily. You may have to
suggest reducing scope and cost if management
does not agree with your estimate.
8. Revise your project budget as you undertake and
complete the project.
Typical Problems with IT Cost
Estimates




Developing an estimate for a large software project is a
complex task requiring a significant amount of effort.
Remember that estimates are done at various stages of the
project
Many people doing estimates have little experience doing
them. Try to provide training and mentoring.
IT People have a bias toward underestimation. Review
estimates and ask important questions to make sure
estimates are not biased
Management wants a number for a bid, not a real estimate.
Project managers must negotiate with project sponsors to
create realistic cost estimates
Table 6-3. Business Systems Replacement
Project
Cost
Estimate
Overview
Category
Description
Objective
Scope
Assumptions
Install a suite of packaged financial applications
software which will enable more timely
information for management decision-making,
easier access to data by the ultimate end user, and
allow for cost savings through productivity
improvements throughout the company.
The core financial systems will be replaced by
Oracle financial applications. These systems
include:
 General Ledger
 Fixed Assets
 Ops Report [AU: spell out Ops]
 Accounts Payable
 Accounts Receivable
 Project Accounting
 Project Management
Oracle's software provides


Cost/Benefit Analysis
& Internal Rate of Return (IRR)
Minimal customization
No change in procurement systems during
accounts payable implementation
BSR was broken down into a three-year cash
outlay without depreciation. Costs are
represented in thousands. Capital and expenses
are combined in this example.
Table 6-4. Business Systems Replacement
Project Cash Flow Analysis
Costs
Oracle/PM Software
(List Price)
60% Discount
Oracle Credits
Net Cash for Software
Software Maintenance
Hardware & Maintenance
Consulting &Training
Tax & Acquisition
Total Purchased Costs
Information Services &
Technology (IS&T)
Finance/Other Staff
Total Costs
FY95
FY96
FY97
($000)
($000)
($000)
992
8 Year Internal
Rate of Return
Future Annual
Costs/Savings
($000)
0
1492
0
250
270
0
50
570
0
(595)
(397)
0
0
0
205
0
205
500
0
500
90
270
320
150
1330
1850
250
270
0
80
600
1200
(595)
(397)
500
340
540
525
230
2135
3550
200
905
990
4170
580
2380
1770
7455
570
(101)
(160)
(88)
0
(349)
(483)
(1160)
(384)
(25)
(2052)
(584)
(1320)
(472)
(25)
(2401)
(597)
(2320)
(800)
(103)
(3820)
3821
328
5054
(3250)
Savings
Mainframe
Finance/Asset/PM
IS&T Support/Data Entry
Interest
Total Savings
Net Cost (Savings)
500
3 Year
Total
($000)
905
35%
Cost Budgeting
Cost budget involves allocating the project
cost estimate to individual work items and
providing a cost baseline
 For example, in the Business Systems
Replacement project, there was a total
purchased costs estimate for FY97 of
$600,000 and another $1.2 million for
Information Services and Technology
 These amounts were allocated to appropriate
budgets as shown in Table 6-5

Table 6-5. Business Systems Replacement Project
Budget Estimates for FY97 and Explanations
Budget Category
Headcount (FTE)
Compensation
Consultant/Purchased
Services
Estimated Costs
13
$1,008,500
$424,500
Travel
$25,000
Depreciation
$91,000
Rents/Leases
$98,000
Other Supplies
and Expenses
Total Costs
$153,000
$1,800,000
Explanation
Included are 9 programmer/analysts, 2
database analysts, 2 infrastructure
technicians.
Calculated by employee change notices
(ECNs) and assumed a 4% pay increase in
June. Overload support was planned at
$10,000.
Expected consulting needs in support of the
Project Accounting and Cascade
implementation efforts; maintenance
expenses associated with the HewlettPackard (HP) computing platforms;
maintenance expenses associated with the
software purchased in support of the BSR
project.
Incidental travel expenses incurred in
support of the BSR project, most associated
with attendance of user conferences and
off-site training.
Included is the per head share of
workstation depreciation, the Cascade HP
platform depreciation, and the depreciation
expense associated with capitalized
software purchases.
Expenses associated with the Mach1
computing platforms.
Incidental expenses associated with things
such as training, reward and recognition,
long distance phone charges, miscellaneous
office supplies.
Designing the Baseline



One of the most crucial inputs to the pricing
decision
Baseline design should be started early so its cost
estimates can be included in the proposal
Effective pricing should begin a long time before
proposal development
– Gives management an opportunity to terminate a bid
initiative before too many resources get committed to
proposal development, presentations, negotiations, etc..
Pricing Process
This activity schedules the development of
the work breakdown structure and provides
management with two of the three
operational tools necessary for the control
of a system or project
 The third tool is the WBS

The WBS as price estimating tool
Provides the basis for effective and open
communication between functional
management and program/project
management
 After pricing is complete the WBS forms
the basis of a communications tool by
documenting the performance agreed on in
the pricing effort.

Organizational Input
Requirements

After the WBS and activity schedules are
established, an organizational meeting is called.
– The WBS is described in depth
– Responsibilities are clarified
– Costing information is solicited and collected from the
responsible parties

A short time fuse is usually involved in
estimating/pricing which makes it all the more
risky
– RFP’s sometimes require a response within 30 days of
their submittal
Labor Distributions

Functional units supply their input in the form of
man-hours
» See Figure 14-2




Man-hours submitted are often over-estimated
Man-hours are converted to dollars by multiplying
by the labor rates
Rates are only averages
Base rates are then escalated as a % factor, based
on past experience
Labor Distributions--Conflict
Resolution
The reduction of man-hours is often the
source of heated discussions between
project and functional management
 Most common solution rests with the
project or program manager
 This becomes the usual turf-fight
 How would you resolve all such
conflicts???

A Proposal Manager
Integrates the activities of the program and
functional managers
 Insures that a robust proposal gets
submitted to the REQUESTER on time

Overhead Rates




Program/project costs involve both direct labor
and indirect (OVERHEAD) costs
Each team member should understand overhead
rates
If overhead rates are more than 50% of direct
regular time and not chargeable to overtime, then
overtime at 150% regular time may be cheaper
Overhead rates in manufacturing can be 300-450%
Elements of Overhead Rates
(Indirect Costs)








Building maintenance
Building rent
Cafeteria
Clerical
Consulting
Corporate Salaries
Depreciation of equip.
Executive Salaries








Group insurance
Holidays
Moving/storage exp.
Personnel recruitment
Retirement plans
Sick leave
Telephone/Utilities
Vacation
Why are Overhead Rates of Interest to
Project Management???
These rates must be included in any project
cost calculation!!!
 The contractor is going to pay both your
direct and your indirect overhead costs if
yours is the winning bid
 Where do the costs associated with bidding
and proposing go? Does anybody pay for
them or are they just a SUNK cost???

Let’s REVIEW: What are the
Major Cost Components?
Salary structure
 Overhead structure
 Labor hours required
 Cost of materials and support

Cost of Materials??
Required Software
 Diet coke, pizza

Materials Support Costs
Are submitted by month for each month of
the project
 An escalation factor for material costs must
be applied

Pricing out the Work—STEPS
(from Kerzner, p. 738)
Provide a complete definition of the work
requirements
 Establish a logic network with checkpoints
 Develop the work breakdown structure
 Price out the WBS

Pricing out the Work--STEPS,
Cont’d
Review WBS costs with each functional
manager
 Decide on the basic course of action
 Establish reasonable costs for each WBS
element
 Review the base case costs with upper-level
management

Pricing out the Work--STEPS,
Cont’d
Negotiate with functional managers for
qualified personnel
 Develop the linear responsibility chart
 Develop the final detailed and PERT/CPM
schedules
 Establish pricing cost summary reports
 Document the result in a project plan

Smoothing out Department Manhours



Ramp-up at project initiation and Ramp-down at
project completion cause step functions in
manpower requirements, as shown in Figure 14-8
Functional managers attempt to SMOOTH this out
QUESTION?? Does the department have
sufficient resources to fulfill the requirements?
Smoothing out Department Manhours

ANOTHER QUESTION?? Can the
departments ramp-up fast enough?
The Pricing Review Procedure
Based on Kerzner’s work
 Remember only 30 days to get the proposal
out and this is one of 13 steps
 Many contractors require the actual team
members to be identified in the proposal
 What solution comes to mind?

Systems Pricing
The project pricing model (also called the
strategic planning model) acts as a
management information system
 Also provides management with an
invaluable tool for performing perturbation
analysis on the base case costs

Developing the
Supporting/Backup Costs
Some proposals require backup support
 When required backup support must be
included in the pricing
 An issue is the type of contract

Types of contracts
Fixed-price (developer assumes all of the
risk)
 Cost-plus (contractor pays for every hour
invested and thus assumes all the risk)
 An infinite array in between these

The Low-Bidder Dilemma
The price of your contract will definitely
affect the viability of your proposal
 A low price on cost-plus type proposals is
suspect
 A low price on fixed-price contracts may be
perceived as impossible and undoable, or if
accepted will lead to a disaster

The Price on the Proposal is
always relative to:
the competitive prices
 the customer budget
 the bidder’s cost estimate
 IN ANY CASE, LOW PRICING
WITHOUT MARKET INFORMATION IS
MEANINGLESS

If its a new market for the
Developer:
Cost sharing may be an effective strategy
 Bidding below your actual costs is
commonplace
 Contractor’s objectives might include
system life cycle cost or unit production
cost

The Bottom Line on Price

THE LOWEST BIDDER IS NOT
NECESSARILY THE AUTOMATIC WINNER
– Makes project a risky image regarding cost,
performance or schedule


The ability to perform under contract is a definite
consideration
A compliant, technically and managerially sound
proposal based on past experience, with realistic,
well-documented cost figures, is often chosen over
the lowest bidder
Special Problems
• Pricing must include an understanding of cost control-how costs are billed back to the project
• There are three situations:
– Work is priced out at the department average, and all
work performed is charged to the project at the
department average, regardless of who performed the
work
– Work is priced out at the dept.. average, but all work
performed is billed back to the project at the actual
salary of the employees who performed the work
– Work is priced out at the actual salary of those
employees who will perform the work, and the cost is
billed back the same way.
» This is the ideal situation
This is as far as we will go with
these slides—ignore the
remainder
Estimating Pitfalls
• The “buy-in” decision is the most serious pitfall
because it means that the project will be underfunded
• If the customer initially defines the requirements
and you (the developer) further refine them and
the customer doesn’t understand what you’ve
done, whose fault is it?
Estimating High-Risk Projects
• Validity of historical estimates determine the
difference between high-risk and low-risk
projects
• Estimating high-risk projects is commonly done
by means of the rolling wave or moving window
approach
– For a 12-month project the first six months are
estimated to level 5, while the last six months are
estimated to level two only.
– As the project proceeds more and more of the last six
months is estimated to level 5
– See Figure 14-13, Kerzner
Project Risks

RISKS--Factors that increase the
probability that the project’s goals of time,
cost and performance will not be met
• See Figures 14-14, 14-15 and Table 14-13
(Especially useful)
Common Risks include:
Poorly defined requirements
 Lack of qualified resources
 Lack of management support
 Poor estimating
 Inexperienced project manager

Tools to Aid in Risk
Identification
Decision Support Systems
 Expected value measures
 Trend analysis/projection
 Independent reviews and audits

Six steps to risk management are:
Identification of the risk
 Quantification of the risk
 Prioritizing the risk
 Developing a strategy for managing the risk

– A contingency plan
Project sponsor/executive review
 Taking action

The Disaster of Applying the 10
% Solution to Project Estimates




10% is taken from every on-going project to create
a budget out of thin air
The result is havoc on top of chaos
Most high-level executive committees do not
realize the impact of adopting the 10% solution
A REDUCTION IN BUDGET MUST BE
ACCOMPANIED BY A TRADEOFF IN TIME
OR PERFORMANCE
The Disaster of the 10%
Solution, Cont’d
90% of the budget generates 10% of the
desired service or performance levels and
the remaining 10% will generate the last
90% of the desired service or performance
 If there is FAT, i.e., padding, it may,
however, be possible to sustain a cut in the
project budget without major consequence

– Most projects do not have FAT
Cost vs. Performance
I much prefer the word performance to
quality here
 A 10% reduction in cost can be expected to
produce much greater than a 10% reduction
in performance

More on the 10% Solution
10% reduction solutions should be
undertaken only after a careful impact study
has been completed
 A far better choice is for the executive
committee to cancel or de-scope some
projects in order to release funds

14.19 Life-Cycle Costing (LCC)
These are the total costs to the organization
for the ownership and acquisition of a
product over its full life
 Especially appropriate for in-house software
development projects, but is used in some
(outhouse) contracted projects as well

Life-cycle cost breakdown
R & D Costs (Definition, Analysis)
 Production cost (Design)
 Construction cost (Programming and
testing)
 Operation and maintenance cost
 Product retirement cost

Life-cycle costing process
Define the problem
 Define the requirements of the cost model
being used
 Collect historical data-cost relationships
 Develop estimates and test results

Successful applications of LCC
will:
Provide downstream resource impact
visibility
 Provide life-cycle cost management
 Influence R&D decision making
 Support downstream strategic budgeting

Estimating Methods for LCC


Method choice is based on the problem context,
operational considerations, etc.
Informal estimating methods
–
–
–
–

Judgment based on experience
Analogy
SWAG method, ROM method
Rule-of-thumb method
Formal estimating methods
– Detailed (from industrial engineering standards)
– Parametric
Figure 14-18
For every $12 DOD puts into R&D, $28 are
needed downstream for production and $60
for operation and support
 After Conceptual definition and
demonstration/validation, 85% of the
lifecycle decisions are made and cost
reduction opportunities are down to 22%

14.20 Logistics Support


A frequent occurrence in software development
where the developer is paid to provide aftermarket support in the form of operation and
maintenance on the product (deliverable)
Recall that after the design phase 85% of the
deliverable’s life-cycle cost has been committed
and the majority of the total life-cycle cost is still
ahead >> 60%
Performance metrics for Products
requiring Logistics Support
Suppportability--the ability to maintain or
acquire the necessary human resources to
support the system
 Readiness--measure of how good we are at
keeping the product performing as planned
and how quickly we can make repairs
during a shutdown

Estimating -
An iterative process
– Definition, Analysis, Design
After Definition, 50-100% off
 After Analysis, 25-50% off
 After Medium level design--within 10%
 A good WBS is absolutely essential to do
estimating

Estimating Techniques
Professional Judgment
 Developer estimate
 History (database)
 Formulas

Use of Professional Judgment
Based on WBS, an expert judgment
estimate is made for each work package
 Amazingly accurate when experts are
available
 Often, however experts aren’t available

Developer Estimate

The programmer assigned to the work
package will make every effort to complete
the task in the time he estimated it would
take
Use of History Database
For this to work, your firm must keep a
history database
 The database should record how long each
task took and who did the task
 Break new projects up into tasks that have a
history database
 8 to 1 productivity ratio between best to
worst professional

Questions, Cont’d

How much of the total time does Brooks devote to
Definition, Analysis and Design?


How much time to coding?


1/6 to Coding
How much time to testing?



1/3
1/4 to component test and early system test
1/4 to total system test
So how much time are you going to devote to
testing in your projects?????
Use of Formulas

COCOMO--project cost, effort, schedule,
staffing for each of the phases:
–
–
–
–

Preliminary design
Detailed design
Code and unit test
System test
COCOMO was developed by Barry Boehm
in 1981--COnstructive COst MOdel
Inputs to COCOMO
Monthly cost of staff involved
 Factors indicating the general level of
complexity of the software
 Programming practices and tools used
 Experience of staff
 Lines of LOSC--rendering COCOMO
unusable

Function Points
A user input
 User display
 Peripheral I/O
 Restructuring data
 Condition checking
 Calculation
 Branching

Function point approach-BEFORE YOU LEAP
Vendor is Gordon Group
 It must know how many LOSC are required
for each function point.
 It calculates LOSC based on function points
it knows about and feeds this into the
COCOMO algorithm

Estimacs from CA (Computer
Associates)
Can take into account modern code
generation tools
 Determines effort, but also

–
–
–
–

Hardware required
financial break-even analysis
risk analysis
maintenance costs
Expensive > $20K
Estimating Programming:
Function Points
D = C * ( G + J)
 D is the task duration in person-days
 C is the complexity of the task
 G is the assigned persons’ general
experience
 J is the assigned professional’s job
knowledge factor

Complexity
Must break task down into its smallest
possible repeatable functions
 Then add up the complexity of each
function
 User input, user display, peripheral I/O,
restructuring data, condition checking,
calculation, etc.


Repeatable functions are called function points.

Function points are graded as SIMPLE, COMPLEX and VERY
COMPLEX
Productivity
Your average programmer gets a
productivity factor of 1 for G
 Slower programmers get factors > 1
 Faster programmers get factors < 1

Formula method conclusions
Will work if you develop accurate factors
 Can be used for any task from building a
house to developing software
 Depends on how well you granularize

Estimating The Analysis Phase
Interviews
 Analyze Existing Documents and Systems
 Prepare Functional Specification
 Presentation

RATIOS
PHASE
PERCENTAGE
 Definition phase -- 10%
 Analysis phase -- 20%
 Design phase
-- 10%
 Programming
-- 20%
 System test
-- 17%
 Acceptance
-- 7%
 Operation
-- 16%

This breaks down to:
PLAN -- 40%
 BUILD -- 20%
 TEST -- 40%

Another Rule of Thumb
The time to design, document and code a
module =
 equals the time to debug it


According to Gildersleeve
Can you use RATIOS for
Forecasting?
Suppose you found that it took 20 days to
do definition.
 How long, based on ratios will it take to do
the project?

Estimating Rules







Never use inexperienced persons to estimate
Get group estimates if possible
Never force an estimate on a programmer
Never take an average of different estimates
Granularize down to one week or less
Always add for contingency
Always quote a range when giving estimates
Conclusions to Estimating
Our weakest talent
 Estimating is iterative
 Estimating is still an art

Scheduling -
Also assists with estimating, especially
when PM software is used
PM software supports
WBS
 Gantt
 PERT
 Calendar(s)
 Resources and their assignments

PERT

Use activity on node approach
– doesn’t require dummy activities
Understand what float is--it is slack
 Critical path is the longest path
 shows precedent activities, relationships
 doesn’t show what will be done when, by
whom

Resource allocation
Assign tasks to individuals whose skill level
suits the task
 Assign similar tasks to the same person
 Assign time-critical tasks to your most
reliable people
 Assign tasks that communicate to the same
individual to minimize people’s interaction
 Don’t assign too many different tasks to any
one individual

Reducing task duration by adding
manpower
Add 20% direct time for each additional
member on a professional team
 If it takes 10 person days for one person, it
will take 12 person days for two people,
14.4 person days for three people, etc.

Cost effects of adding resources
More resources, gets the project done
sooner, USUALLY
 But it also costs more
 The PM must come up with the best
balance, depending on the priorities set by
management or the user

Shortening the duration of
projects
Fast tracking
 Crashing

– Adding resources to the critical path
– Allowing your current CP teams members to
work overtime
Crashing projects
Crash tasks on the critical path only, only as
long as no other path becomes critical
 If other paths become critical, the analyst
must crash those as well

Gantt Chart
a time bar chart
 Invented by Henry Gantt in 1910
 Determine the units of time
 Mark all known calendar events at bottom
 Schedule each activity from PERT

Use three sets of Gantt’s
one for yourself alone, with all float and
contingency visible
 second for the individuals involved--their
resource Gantt, contingencies hidden
 third for distribution to upper management-contingencies hidden
 Include a 10% contingency into all
estimates

Conclusions to Scheduling
Use PM software--worth every penny
 Do at least one PERT and one GANTT
manually, just to get a feel for the process

Recitation




What is the probability of completing a project by
its estimated completion time??
What is the formula for calculating the completion
time for a PERT network?
What is the formula for calculating the standard
deviation of the completion time for a PERT
network?
Name some processes that are part of project
integration management