USC
C
S E
University of Southern California
Center for Software Engineering
Business Case Analysis
Barry Boehm
CS 510, 577, Fall 2015
Adapted from Donald J. Reifer’s 2005 lectures
Fall 2015
©RCI, USC-CSSE
1
Business Cases in ICSM Decision Milestones
Feasibility Evidence Description
•
•
•
Evidence provided by developer and validated by independent experts that:
If the system is built to the specified architecture, it will
– Satisfy the specified operational concept and requirements
• Capability, interfaces, level of service, and evolution
– Be buildable within the budgets and schedules in the plan
– Generate a viable return on investment (ROI)
– Generate satisfactory outcomes for all of the success-critical
stakeholders
Shortfalls in evidence are uncertainties and risks
– Should be resolved or covered by risk management plans
Assessed in increasing detail at major anchor point milestones
– Serves as basis for stakeholders’ commitment to proceed
– Serves to synchronize and stabilize concurrently engineered elements
Can be used to strengthen current schedule- or event-based reviews
Fall 2015
©RCI, USC-CSSE
2
USC
C
S
E
University of Southern California
Center for Software Engineering
Business Cases Quantify the
Impact of Proposed Changes
• Engineering decisions involve many options and
difficult tradeoffs
– May be several technical solutions for the problem
– The best technical solution is determined by
evaluating the tradeoffs using a variety of criteria
selected for that purpose
• Software engineering provides you the methods
and tools to understand the tradeoffs and select
the best answer (typically under constraints)
– Management prefers quantified impacts
– But qualitative impacts are important also
Fall 2015
©RCI, USC-CSSE
3
USC
C
S E
University of Southern California
Center for Software Engineering
Pervasive Issues When
Developing Business Justifications
• Common definition of costs and benefits not widely
accepted across the industry
• Productivity, cost and quality data considered highly
confidential and kept secret
• Common definition of the justification processes involved
lacking within the engineering community
• Difficult to attribute resulting numbers to one cause or
another
• Hard to communicate results - engineers talk technical,
decision-makers talk business
• Goal of the lecture is to help you communicate better
Fall 2015
©RCI, USC-CSSE
4
Business Cases Address Stakeholder Values
Benefits Chains Help Identify These
Fall 2015
©RCI, USC-CSSE
5
USC
C
S E
University of Southern California
Center for Software Engineering
thinking about running a seminar.
Nine Business Case Principles
1. Decisions should be made
relative to alternatives
2. If possible, use money as
the common denominator
3. Sunk costs are irrelevant
(Engineering Econ 101)
4. Investment decisions
should recognize the time
value of money
5. Separable decisions must
be considered separately
Fall 2015
6. Decisions
1. Do nothing,should
learn by consider
themselves
2.
On-the-job
training and
both
quantitative
3.
Bring
seminarseminar
/ hands-on
How
can aintraining
save
qualitative
factors
training
costs
/ save time / improve quality ?
7. The
risks
with
Calculate
thatassociated
in $$
What
happened in
the past,be
stay in
the decision
should
the past.
quantified if possible
Already ran a java seminar last year ?
today
$8 next
yearstaff with
it
does
not=matter.
New
8. $10
The
timing
associated
Save in the bank, %6 interest
making decisions is critical
Any better option ?
you select aprocesses
training firm,should
use
9. IfDecision
different criteria, don’t mix them up.
be periodically assessed
and continuously improved
©RCI, USC-CSSE
6
USC
C
S E
University of Southern California
Center for Software Engineering
thinking about running a seminar.
Nine Business Case Principles
6. Decisions should consider
both quantitative and
qualitative factors
7. The risks associated with
the decision should be
quantified if possible
8. The timing associated with
making decisions is critical
9. Decision processes should
be periodically assessed
and continuously improved
Fall 2015
Training seminar might improve
image and morale.
What if no trainer available , any
back up plan ? What is the extra
cost?
Time your decision carefully.
Any budget cycle ?
Propose when there is money
available.
Keep your eyes open, look for
possible improvement.
©RCI, USC-CSSE
7
USC
C
S E
University of Southern California
Center for Software Engineering
Case Study- Justifying Process
Improvement
• Purpose of case
– Justify investments in process improvement
• Goals of effort
– Develop numbers that get management to buy into
near- and long-term investment tactics
• Constraints
– Deal with the firm’s related process improvement
folklore, biases and history
Fall 2015
©RCI, USC-CSSE
8
USC
C
S E
University of Southern California
Center for Software Engineering
Organizational Structure
Senior Management
Your
home
Aerospace firm
QA Group
Process Group
Senior Staff
Engineering
Manufacturing
* Systems
* Software
* Digital design
* Fabrication
* Assembly
* Production
Fall 2015
Field Support
Program Mgmt
* Field service
Line of Business
* Training
Management
* Test & evaluation * Fund functional
groups
Project A
* Coordinate
* Facilitate
©RCI, USC-CSSE
9
USC
S E
C
University of Southern California
Center for Software Engineering
History of Process Improvement
Maturity Level
5
Process
budget
axed
Level 3 a customer
requirement
4
3
Aim- Reach
Level 4
in 2 years
Acquisition
falls through
Seniors
get serious
about process
Firm positioned
to be acquired
2
1
1985
Fall 2015
Reach Level 3 corporate goal
1987
1989
Process group
reformed
1991
1993
©RCI, USC-CSSE
1995
1997
1999
Now
10
USC
C
S E
University of Southern California
Center for Software Engineering
The SEI Software CMMI
• Used by many to characterize the maturity of the
processes used to develop software
• Important because:
– Employed as a means to benchmark firms
– Acts as a framework for structuring improvements
– Shown to have positive effect on productivity,
quality and cost
– Makes it easier to tackle a big software job like
the one you are working on
Fall 2015
©RCI, USC-CSSE
11
5
4
- Defect prevention
- Technology change management
- Process change management
- Quantitative process management
- Software quality management
- Organization process focus
3
- Organization process definition
- Training program
- Integrated software management
- Software product engineering
- Inter-group coordination
- Peer reviews
- Requirements management
2
- Software project planning
- Software project tracking and oversight
- Software subcontract management
- Software qualify assurance
- Software configuration management
Fall 2015
©RCI, USC-CSSE
The
Software
CMM
Contains:
- 5 Maturity Levels
- 18 Key Process Areas
- 318 Key Practices
12
USC
C
S E
University of Southern California
Center for Software Engineering
CMMI Lessons Learned
• Takes 18 to 30 months to move a maturity level
– From Level 1 to 2 - average of 23 months
– From Level 2 to 3 - average of 21 months
– From Level 3 to 4 - average of 28 months
• Average investment to move up a maturity level is
several million $ for a 500-person organization
• The gains attributable to early error detection and
correction are substantial (20X cheaper per error)
• The average increase in productivity attributable to
process improvement is 10 percent per level
Fall 2015
©RCI, USC-CSSE
13
USC
C
S E
University of Southern California
Center for Software Engineering
Rules of Engagement
• Let the numbers do the talking
• Don’t assume that Program Managers understand
software (many are clueless)
• Justifications must be made at the project level
• You must address past experience, both pro & con
• Your plan must focus on near-term results
• Any software processes must be compatible with your
existing management infrastructure
• You must track/demonstrate accomplishment of goals
Fall 2015
©RCI, USC-CSSE
14
USC
C
S E
University of Southern California
Center for Software Engineering
Start - Why Focus on Process?
Why (Goal):
Questions:
Increase Productivity and Meet Customer Requirements
Measured
how?
What
option?
Why this
option?
Metrics:
SLOC/hour Do
Process
Other
ROI
Nil improvement approaches
Models:
COCOMO
Fall 2015
SEI Maturity
Model
©RCI, USC-CSSE
Non-discounted
ROI
15
USC
C
S E
University of Southern California
Center for Software Engineering
Process Group Budget = $2.4M/year
• Process development
– 4 employees ($700K)
• Education & training
– 2 part-timers ($200K)
– $250K for seminars
• Process assessment
– $200K for outside
facilitator
• Promotion and outreach
– $250K to prepare newsletter, work with clients
and attend conferences
• Process roll-out/project
support
• Support environment
– 2 consultants ($450K)
– Retirees with credibility
Fall 2015
– $350K for web site
development
©RCI, USC-CSSE
16
USC
C
S E
University of Southern California
Center for Software Engineering
Your Justification Approach
• Justify process budget by ROI analysis of the
initial and continuing:
– Cost and impact of COCOMO-determined 10%
annual productivity increase, including cost of
staff training
– Impact of early error detection/correction
– Impact of COTS usage strategy
– Cost and impact of moving to an architecturebased reuse strategy
• Show intangibles as added value
Fall 2015
©RCI, USC-CSSE
17
USC
C
S E
University of Southern California
Center for Software Engineering
Early Error Detection/Correction
• Benefit of achieving Level 4 is a reduction in errors
by a factor of between 20 and 25%
– Majority caught early in requirements and design phases
• Cost avoidance associated with early defect removal is
$20/defect
• For the 12 major programs in your firm, you compute
cost avoidance is $1.2 million calculated as follows:
(12 jobs/year)(10 defects1/KSLOC)(500KSLOC/job) = 60Kdefects/year
(60K defects/year)($20/defect (avoidance)) = $1.2 million/year
1 As
Fall 2015
jobs enter test and evaluation; goal is 0.1 defect/KSLOC on delivery
©RCI, USC-CSSE
18
USC
C
S E
University of Southern California
Center for Software Engineering
Exploitation of COTS
• Benefits of enterprise-wide licensing can be
substantial
– At the corporate level, this includes major software
packages like DBMS
– At the project level, this includes software tools and
specialized software like operating systems
• As part of your Level 4 initiative, you plan to put
in a licensing process that allows you to lever
your buying power and save $1 million/year as an
early payoff of the productivity initiative
Fall 2015
©RCI, USC-CSSE
19
USC
C
S
University of Southern California
E
Center for Software Engineering
COTS Pluses and Minuses
Pluses
Minuses
• Cheaper; but does not
come for free
• Available immediately
• Known quality (+ or -)
• Vendor responsible for
evolution/maintenance
• License costs can be high
• COTS products are not
designed to plug & play
• Vendor behavior varies
• Vendor responsible for
evolution/maintenance
– 15-20% annual fee
• Can use critical staff
resources elsewhere
Fall 2015
– Have no control over the
product’s evolution
©RCI, USC-CSSE
20
USC
C
S
E
University of Southern California
Center for Software Engineering
Architecture-Based Reuse
• Architectures are the framework you use to pull your
product lines together
– They are domain-specific and standards-based
– They encapsulate generality and variability
• They guide selection and use of high-leverage assets
– The 20% responsible for 80% of the reuse
• They allow you to take full advantage of both COTS
components and reusable assets
– Cost to build for reuse must be factored into analysis
– Benefits of reuse adhere to the 3 times rule
Fall 2015
©RCI, USC-CSSE
21
USC
C
S
E
University of Southern California
Center for Software Engineering
Reuse-Based Development Paradigm
Purchased products
Domain Model
Domain
Analysis
Scope
Requirements
Asset
Development
Domain
Design
Assets
Architecture
Products
for sale
Domain Engineering
Software Reuse Library
Assets
Requirements
Analysis
Software
Integration
Development
& Test
Applications Engineering
Fall 2015
©RCI, USC-CSSE
Operations &
Maintenance
Project-specific deliverables
22
USC
C
S E
University of Southern California
Center for Software Engineering
COCOMO II Reuse Model
ESLOC = ASLOC [AA + AAF(1 + 0.02(SU)(UNFM))] AAF < 0.5
100
ESLOC = ASLOC [AA + AAF + (SU)(UNFM)]
100
AAF > 0.5
Where: AAF = 0.4 (DM) + 0.3 (CM) + 0.3 (IM)
SU = Software Understanding
(zero when DM = 0 & CM = 0)
UNFM = Programmer Unfamiliarity
AA = Assessment and Assimilation
ASLOC = Adapted SLOC
ESLOC = Equivalent new SLOC
Fall 2015
©RCI, USC-CSSE
23
USC
C
S E
University of Southern California
Center for Software Engineering
The Impact of Reuse
Application
Real-time executive
Scheduler
Real-time data acquisition
Sensor data processing
Data analysis and alarms
TOTAL
Nominal Development Time (months)
Nominal Effort (staff-months)
Shortest Development Time (months)
Shortest Development Time Effort
Without Reuse
10,000
25,000
50,000
50,000
25,000
160,000
Without Reuse
30
845.3
22.5
1208.7
With Reuse
500
500
10,000
21,000
10,000
42,000
With Reuse
23.4
383.7
17.6
548.7
Conservative estimate of savings is $10 million/year, minus
cost of $2 million/year in evolving reusable assets
Fall 2015
©RCI, USC-CSSE
24
USC
C
S E
University of Southern California
Center for Software Engineering
Reuse Cost/Benefit Worksheet
• Non-Recurring Costs
• Tangible Benefits
– Domain engineering – $500K
– Reusable assets – added $1000K
– Infrastructure creation – $500K
• Recurring Costs (per year)
– Architecture maintenance $500K
– Asset maintenance
1500K
Total Costs
Fall 2015
$2M + $2M/yr
– Cost avoidance
$10 million
• Intangible Benefits
– Deliver 12 months earlier than the
norm
– 10 times reduction in efforts at
delivery
– Architecture stable, proven and can
be demonstrated to clients
– Scheduling algorithms can be
optimized and improved
Total Benefits $10 million
©RCI, USC-CSSE
25
USC
C
S E
University of Southern California
Center for Software Engineering
Strategy Yields Positive Returns
Early Error Reduction
• Cost avoidance = $1.2M/year
• Increased customer satisfaction based on quality
Systematic Reuse
• Cost avoidance = $10M/year
• Faster to market
• Can be built by enhancing
first-project assets
• COCOMO added cost $2M
•Process can be built with
reuse in mind
Fall 2015
Exploitation of COTS
• Cost avoidance = $1M/year
• Improved maintenance and
license leverage with vendors
Productivity Improvement
• Cost avoidance = $7.5M/year
• Improved capabilities & capacity
©RCI, USC-CSSE
26
USC
C
S E
University of Southern California
Center for Software Engineering
Return-On-Investment Is High
•
•
•
•
•
•
•
•
•
•
•
Annual Software Staff Cost: 500 * $150K/yr = $75M/yr
Process Group Cost: 2 * $2.4M/yr = $4.8M
3 week staff training cost: $75M * .06 = $4.5M
Developing reusable assets: $2M
Initial investment cost: $11.3M over 2 years
Annual evolution cost: $3M: $1M process; $2M reusable assets
Annual benefits $19.7M: Reuse $10M, COTS $1M; EER $1.2M;
Productivity 10% 0f $75M/year = $7.5M/year
Cumulative ROI: (Benefits –Costs)/Costs
After year 1: ($19.7M - $14.3M)/$14.3M = 38%
After year 2: ($39.4M - $17.3M)/$17.3M = 128%
After year 3) ($59.1M - $20.3M)/$20.3M = 191%
Fall 2015
©RCI, USC-CSSE
27
ROI Includes Intangibles
Include these in briefings
• Better product quality
• Quicker to market
• Increased customer satisfaction
• Improved employee morale
• Responds directly to customer needs
Fall 2015
©RCI, USC-CSSE
28
USC
C
S E
University of Southern California
Center for Software Engineering
When Briefing Management Always Ask For Help
• Reaching Level 4 will take 2 years assuming
things go as planned
• The major challenge is to get those in the middle
motivated; top management can help
• There are a number of operational challenges
– Need help in staffing process group – getting
requisitions through the system is tedious
– Need help in licensing – buyer, legal and staff support
• Must keep the momentum going
Fall 2015
©RCI, USC-CSSE
29
USC
C
S E
University of Southern California
Center for Software Engineering
Case Study - Final Thoughts
• Process improvement is a good investment
• To get management support, a good action plan
and solid business case is needed
• When justifying initiatives, cost avoidance is
preferred to cost reduction
• When determining benefits, categorize them as
tangibles and intangibles
• Be conservative, but make your case using the
numbers to justify the investments
Fall 2015
©RCI, USC-CSSE
30
USC
C
S E
University of Southern California
Center for Software Engineering
Most Importantly – Talk and Think
Like a Business-Person
• Talk like a business-person
– Translate technical jargon into business goals
• Act as a business-person
– Assess both the business and technical aspects of the
proposal
– Show your bosses you can run a business operation
• Be a business-person
– Focus on the bottom-line using the numbers when you
can to make decisions that are good for the firm
Fall 2015
©RCI, USC-CSSE
31
USC
C
S E
University of Southern California
Center for Software Engineering
Lots of Available Web Resources
Topic
Engineering
economics and
business cases
Computer
economics and
business cases
Software
economics and
business cases
Addison-Wesley
site for this book
Fall 2015
Web Resources
www.isye.gatech.edu (Georgia Institute of Technology)
- The WWW virtual library of industrial engineering with information
on academic programs, conferences, courses, publications which
emphasize their engineering economics core expertise area
http://info.berkeley.edu/resources/infoecon (UC Berkeley)
- Economics of the Internet with pointers to sites on E-Commerce, EPublishing, intellectual property, etc.
www.computereconomics.com
- IT cost management support including industry benchmarks
- E-Business strategies and market forecasts
www.hbsp.harvard.edu (Harvard Business School)
- Access to case studies on E-Commerce and the Internet, change
management, entrepreneurship and new technology
http://sunset.usc.edu (University of Southern California)
- Information on cost estimating/analysis and the COCOMO suite
Access to software downloads (COCOMO and code counters)
www.sei.cmu.edu (Software Engineering Institute)
- Information on their Team Software Process (TSP) and Software
Engineering Measurement & Analysis (SEMA) efforts
www.software.org (Software Productivity Consortium)
- Practical measurement techniques including controlled access to their
guidebooks, case studies and lessons learned reports
www.aw.com/softwarebusinesscases
- Updates to this book, student exercises and pointers to additional
useful information
©RCI, USC-CSSE
32