USC
C
S E
University of Southern California
Center for Software Engineering
Business Case Analysis
Donald J. Reifer
University of Southern California
and
Reifer Consultants, Inc.
September 2001
Copyright RCI, 2001
1
USC
C
S E
University of Southern California
Center for Software Engineering
Aim of Presentation
• Introduce you to the subject of business case
analysis and walk you through my book
• Highlight significant concepts and focus on
what you need to do to succeed
• Discuss how to use software cost models like
COCOMO II to help prepare business cases
• Hopefully, motivate you to read and use the
book in practice, the classroom and for fun
September 2001
Copyright RCI, 2001
2
USC
C
S E
University of Southern California
Center for Software Engineering
Why Write a Book on Software
Business Cases?
• Over the years, I have observed that software
engineers don’t know how to prepare sound
business cases and improvement justifications
• However, these same engineers are being asked
to justify recommended investments using
business cases as software is being capitalized
• The book was written to fill this void and to
serve as a textbook for those teaching the subject
September 2001
Copyright RCI, 2001
3
USC
C
S E
University of Southern California
Center for Software Engineering
I Didn’t Write it for the Money
• Those writing books do it
for recognition and selfsatisfaction
• Authors don’t write
technical books to make lots
of money
• If my publisher sold 5,000
copies of the book, I would
make about $15/hour
September 2001
Copyright RCI, 2001
4
USC
C
S E
University of Southern California
Center for Software Engineering
Table of Contents
• Part I - Fundamental
Concepts
– Chapter 1: Improvement
is Everybody’s Business
– Chapter 2: Making a
Business Case
– Chapter 3: Making the
Business Case: Principles,
Rules, and Analysis Tools
– Chapter 4: Business
Cases that Make Sense
September 2001
• Part II - The Case Studies
– Chapter 5 - Playing the Game of
Dungeons and Dragons: Process
Improvement Case Study
– Chapter 6: Quantifying the
Costs/Benefits: Capitalizing
Software Case Study
– Chapter 7: Making Your
Numbers Sing: Architecting
Case Study
– Chapter 8: Maneuvering the
Maze: Web-Based Economy
Case Study
Copyright RCI, 2001
5
USC
C
S E
University of Southern California
Center for Software Engineering
Contents (Continued)
• Part III - Finale
– Chapter 9: Overcoming
Adversity: More Than a
Pep Talk
• Appendix A:
Recommended Readings
• Appendix B: Compound
Interest Tables
• Acronyms
• Glossary
September 2001
Copyright RCI, 2001
6
USC
C
S E
University of Southern California
Center for Software Engineering
Unique Features of Book
• Web site:
http://www.awl.com/cseng/titles/0-201-72887-7
– Look for updates
– Converse with author
• Realistic case studies
• Actual management
briefings as part of case
studies
September 2001
Copyright RCI, 2001
7
USC
C
S E
University of Southern California
Center for Software Engineering
Fundamentals
Key Point Summary
• Must view software as a business
• Must use business measures to justify improvements
Reduce
Time to Market
Avoid/Cut
Cost
Productivity
Quality
Increase
Improve
• Making the leap forward involves overcoming the
resistance to change
September 2001
Copyright RCI, 2001
8
USC
C
S E
University of Southern California
Center for Software Engineering
Success is a Numbers Game
Answer Business-Related Questions
• Will this proposal save money, cut costs, increase
productivity, speed development or improve quality?
• Have you looked at the tax and financial implications
of the proposal?
• What’s the impact of the proposal on the bottom line?
• Are our competitors doing this? If so, what are the
results they are achieving?
• Who are the stakeholders and are they supportive of
the proposal?
September 2001
Copyright RCI, 2001
9
USC
C
S E
University of Southern California
Center for Software Engineering
Business Cases Supply You with
the Numbers
• Business Case = the materials prepared for decisionmakers to show that the proposed idea is a good one
and that the numbers that surround it make sound
financial sense
– Most software engineers prepare detailed technical rather
than business justifications
– Many of their worthwhile proposals are rejected by
management as a consequence
– Use of business cases will increase your chances of success
September 2001
Copyright RCI, 2001
10
USC
C
S E
University of Southern California
Center for Software Engineering
Business Process Framework
Process
Framework
The business case process proceeds in parallel and
interfaces with the software development process
Business Planning Process
Tradeoff and Analysis Processes
Software Development Process
Analytical
Methods
Models
Guidelines for
Decision-Making
“Principles, Rules and Tools for Business Case Development”
September 2001
Copyright RCI, 2001
11
USC
C
S E
University of Southern California
Center for Software Engineering
The Business Planning Process
GQM Results
1. Prepare
white paper
Idea or proposal
2. Demonstrate
technical feasibility
Proof of
Concept
September 2001
7. Get ready
to execute
3. Conduct
market survey
6. Sell the idea and
develop support base
5. Prepare
business case
4. Develop
business plan
Copyright RCI, 2001
Approval to
go-ahead
12
USC
C
S E
University of Southern California
Center for Software Engineering
Nine Business Case Principles
• Decisions are made
relative to alternatives
• If possible, use money as
the common denominator
• Sunk costs are irrelevant
• Investment decisions
should recognize the time
value of money
• Separable decisions must
be considered separately
September 2001
• Decisions should consider
both quantitative and
qualitative factors
• The risks associated with
the decision should be
quantified if possible
• The timing associated with
making decisions is critical
• Decision processes should
be periodically assessed
and continuously improved
Copyright RCI, 2001
13
USC
C
S E
University of Southern California
Center for Software Engineering
Many Rules to Use as Guidelines
Preparation
Presentation
• Prepare business cases in
language to communicate
to management
• Define all of your terms
thoroughly
• Bring in the outside
experts to help if needed
• Double and triple check
your numbers
September 2001
• Never state a number
without bounding it
• Remember, numbers will
come back to haunt you
• Never talk cost reduction;
use avoidance instead
• Always relate your
numbers to benchmarks
and your competition
Copyright RCI, 2001
14
USC
C
S
E
University of Southern California
Center for Software Engineering
Many Tools and Techniques
Analysis Techniques
•
•
•
•
•
•
•
•
•
September 2001
Break-even analysis
Cause and effect analysis
Cost/benefit analysis
Value chain analysis
Investment opportunity
analysis
Pareto analysis
Payback analysis
Sensitivity analysis
Trend analysis
Copyright RCI, 2001
15
USC
C
S E
University of Southern California
Center for Software Engineering
Supportive Tools
Software packages
• Decision support systems
– Tax planning and schedules
– Trade studies and analysis
• Spreadsheets
– Comparative analysis
– Trade studies and analysis
• Software cost models
– Parametric analysis
– Trade studies and analysis
September 2001
Copyright RCI, 2001
16
USC
C
S
E
University of Southern California
Center for Software Engineering
Use Engineering Economics As
Your Basis
FW = P (1 + i)N
PV = FW/(1 + i)N
Future Worth
Present Value
• Takes cost of money
into account
– A $ today is worth
more than tomorrow
due to inflation
• Takes compounding
into account
September 2001
• Normalizes future
expenditures using
current year dollars as
a basis for comparison
• Lets you establish a
minimum attractive
rate of return
Copyright RCI, 2001
17
USC
C
S E
University of Southern California
Center for Software Engineering
Business Case Information Needs
• Business cases
–
–
–
–
• Financial data
–
–
–
–
–
Recurring costs
Non-recurring costs
Tangible benefits
Intangible benefits
• Benchmarks
– Competitive comparisons
– Industry norms
• Metrics
– Management measures
September 2001
Inflated labor costs
Labor categories/rates
Overhead/G&A rates
Past costs/performance
Tax rates/legalities
• Marketing information
– Demographic data
– Market position
– Sales forecast
Copyright RCI, 2001
18
USC
C
S
E
University of Southern California
Center for Software Engineering
Preparing a COTS Business Case
Non-recurring costs
Tangible benefits
- Market research/purchasing
- Package assessment
- Package tailoring & tuning
- Glue code/wrapper development
- Cost avoidance
- Reduced taxes (credits
and depreciation)
Intangible benefits
- Market drives features
- Vendor maintains the
product (good and bad)
- Package mature (better
quality/more robust)
- Lever the marketplace
Recurring costs
- Glue code maintenance
- Licensing/purchasing
- Market watch/test-bed
- Relationship management
- Technology refresh
TOTAL
September 2001
TOTAL
Copyright RCI, 2001
19
USC
C
S
E
University of Southern California
Center for Software Engineering
Computing Costs/Benefits
Costs
• Use COCOTS
Benefits
• Use COCOMO II
– Estimates most of the nonrecurring costs
– Recurring costs should be
estimated, for now, using rules
of thumb
• Relationship management
– Nurtures relationships and
develops partnerships
• Technology refresh
– Market watch looks for better
value for $$$
September 2001
– Estimates benchmark costs for
option of developing code
from scratch or legacy
– Calibrate model for domain
– Use maintenance model to
include rest of life cycle
• Intangibles
– Hard to quantify the cost and
schedule impacts
– Even if you did quantify
them, lots of controversy
Copyright RCI, 2001
20
USC
C
S
E
University of Southern California
Center for Software Engineering
Presenting the Business Case
• Determine decision
timeline (5 years)
• Take PV of B/C Ratio
• Calculate ROI
ROI = ?/year
• Make a second pass to
include depreciation
ROI = ?/year
September 2001
• Try to quantify the
intangibles
– Discuss the impact, but don’t
dilute the numbers using it
(credibility)
• List pluses and minuses
of options considered
• Make a recommendation
based on the information
presented
Copyright RCI, 2001
21
USC
C
S
E
University of Southern California
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
• Performance often poor
• Vendor responsible for
evolution/maintenance
– Don’t have to pay for it
• Can use critical staff
resources elsewhere
September 2001
– Have no control over the
product’s evolution
Copyright RCI, 2001
22
USC
C
S
E
University of Southern California
Center for Software Engineering
COTS Critical Success Factors
• Successful firms:
–
–
–
–
–
–
–
–
–
–
–
Make COTS-based system tradeoffs early
Try before they buy
Avoid modifying COTS at all costs
Reconcile products with their architectures
Emphasize use of standards and open interfaces
Understand that COTS doesn’t come for free
Plan to manage parts/technology obsolescence
Make the vendor a part of the team, whenever possible
Negotiate enterprise-wide licenses for COTS products
Influence future paths the vendor will take
Address the cultural and process issues
September 2001
Copyright RCI, 2001
23
USC
C
S
E
University of Southern California
Center for Software Engineering
The COTS Life Cycle
Requirements
Operate & Maintain
Design
Implementation
Deploy
Integration & Test
Tailor
Evaluate, Select
& Acquire
September 2001
Refresh
Renew
COTS tends to have a
life cycle of its own
Copyright RCI, 2001
24
USC
C
S
E
University of Southern California
Center for Software Engineering
COTS Success Strategies
• Process
• People
– Merge COTS life cycle
into your organizational
framework
– Make needed tradeoffs
– Think both technical and
business issues
• Products
• Institutional
– Fit COTS components into
product line strategies
– Maintain open interfaces
– Manage technology refresh
September 2001
– Make COTS vendors a
part of your team
– Increase awareness of
COTS experience
– Provide workforce with
structure and information
– Improve purchasing and
licensing processes
– Maintain market watch
– Capture past performance
Copyright RCI, 2001
25
USC
C
S
E
University of Southern California
Center for Software Engineering
Lots of Other Business Yardsticks
•
•
•
•
•
•
•
•
•
Cost of Sales
Cost/Benefit Ratio
Debt/Equity Ratio
Earnings/Share
Overhead Rate
Return on Assets
Price/Sales Ratio
Rate of Return
Return on Earnings
September 2001
Copyright RCI, 2001
26
USC
C
S
E
University of Southern California
Center for Software Engineering
Putting Cost Models to Work
• I use cost models in my
book to:
– Create benchmarks to
compute benefits for a
typical project
– Assess available options and
perform sensitivity analysis
– Quantify risk and its cost
and schedule consequences
– Address the many “what-if”
questions that arise via
parametric analysis
September 2001
Copyright RCI, 2001
27
USC
C
S
E
University of Southern California
Center for Software Engineering
Summary and Conclusions
• For software engineers to prosper in business,
they need to learn to prepare business cases
• The technical merit of engineering issues needs
to be quantified and the associated business
issues discussed when making recommendations
for improvement
• Hopefully, my book will help software engineers
to perform these duties and succeed - as they’ve
worked for me over the years
September 2001
Copyright RCI, 2001
28
USC
C
S
E
University of Southern California
Center for Software Engineering
For Example: Making Your
Numbers Believable
• Concepts:
September 2001
–
–
–
–
–
–
–
–
–
Cash Flow Impacts
Cost Basis
Cost/Benefits
Estimate Fidelity
Present Value (PV)
Profit and Loss
Risks and Their Impacts
Sources of funds
Tax implications
Copyright RCI, 2001
29
USC
C
S
E
University of Southern California
Center for Software Engineering
Final Thoughts
• Numbers can be your ally
when asking for money
• When asking for money,
talk your management’s
language not ours
• Don’t be casual about
numbers, be precise
• If you want to learn more,
read my book
September 2001
Copyright RCI, 2001
30