VIII 1 ReiferCase

USC
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
S E
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
USC
S E
Why Write a Book on Software Business Cases?

Over the years, I have observed that software engineers dont 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
USC
S E
I Didnt Write it for the Money

Those writing books do it for recognition and selfsatisfaction Authors dont write technical books to make lots of money If my publisher sold 5,000 copies of the book, I would make about $15/hour
USC
S E
Table of Contents
Part I - Fundamental Concepts
Chapter 1: Improvement is Everybodys 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
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
5
September 2001
Copyright RCI, 2001
USC
S E
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

USC
S E
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

USC
S E
Fundamentals
Key Point Summary Must view software as a business Must use business measures to justify improvements
Reduce Time to Market
Productivity Increase
Avoid/Cut Cost
Quality Improve
Making the leap forward involves overcoming the resistance to change

USC
S E
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? Whats 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?
USC
S E
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
USC
S E
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

USC
S E
The Business Planning Process

GQM Results
1. Prepare white paper Idea or proposal
7. Get ready to execute

6. Sell the idea and develop support base 5. Prepare business case Approval to go-ahead
12
2. Demonstrate technical feasibility 3. Conduct market survey
Proof of Concept
4. Develop business plan

Copyright RCI, 2001
September 2001
USC
S E
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
13
Copyright RCI, 2001
USC
S E
Many Rules to Use as Guidelines

Preparation
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
Presentation
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
14
Copyright RCI, 2001
USC
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
15
Copyright RCI, 2001
USC
S E
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
USC
Use Engineering Economics As Your Basis

FW = P (1 + i)N
Future Worth
Takes cost of money into account
A $ today is worth more than tomorrow due to inflation
PV = FW/(1 + i)N
Present Value
Normalizes future expenditures using current year dollars as a basis for comparison Lets you establish a minimum attractive rate of return
17
Takes compounding into account

September 2001
Copyright RCI, 2001
USC
S E
Business Case Information Needs

Business cases
Recurring costs Non-recurring costs Tangible benefits Intangible benefits
Financial data
Inflated labor costs Labor categories/rates Overhead/G&A rates Past costs/performance Tax rates/legalities
Benchmarks
Competitive comparisons Industry norms
Marketing information
Demographic data Market position Sales forecast
18
Metrics
Management measures
September 2001
Copyright RCI, 2001
USC
Preparing a COTS Business Case

Non-recurring costs
- Market research/purchasing - Package assessment - Package tailoring & tuning - Glue code/wrapper development
Tangible benefits
- 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 Copyright RCI, 2001
TOTAL
19
USC
Computing Costs/Benefits
Costs Use COCOTS
Estimates most of the nonrecurring costs Recurring costs should be estimated, for now, using rules of thumb
Benefits
Use COCOMO II
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
Relationship management
Nurtures relationships and develops partnerships
Intangibles
Hard to quantify the cost and schedule impacts Even if you did quantify them, lots of controversy
20
Technology refresh
Market watch looks for better value for $$$
September 2001
Copyright RCI, 2001
USC
Presenting the Business Case

Determine decision timeline (5 years) Take PV of B/C Ratio Calculate ROI Try to quantify the intangibles
Discuss the impact, but dont dilute the numbers using it (credibility)
ROI = ?/year
Make a second pass to include depreciation
ROI = ?/year
September 2001
List pluses and minuses of options considered Make a recommendation based on the information presented
21
Copyright RCI, 2001
USC
COTS Pluses and Minuses

Pluses
Cheaper; but does not come for free Available immediately Known quality (+ or -) Vendor responsible for evolution/maintenance
Dont have to pay for it
Minuses
License costs can be high COTS products are not designed to plug & play Vendor behavior varies Performance often poor Vendor responsible for evolution/maintenance
Have no control over the products evolution
Copyright RCI, 2001 22
Can use critical staff resources elsewhere

September 2001
USC
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 doesnt 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
USC
The COTS Life Cycle

Requirements Design Implementation Tailor Evaluate, Select & Acquire Deploy Integration & Test Renew Operate & Maintain
Refresh
COTS tends to have a life cycle of its own

September 2001
USC
COTS Success Strategies

Process
Merge COTS life cycle into your organizational framework Make needed tradeoffs Think both technical and business issues
People
Make COTS vendors a part of your team Increase awareness of COTS experience Provide workforce with structure and information
Products
Fit COTS components into product line strategies Maintain open interfaces Manage technology refresh
September 2001
Institutional
Improve purchasing and licensing processes Maintain market watch Capture past performance
25
Copyright RCI, 2001
USC
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
USC
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
USC
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 theyve worked for me over the years
USC
For Example: Making Your Numbers Believable

Concepts:

September 2001 Copyright RCI, 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
29
USC
Final Thoughts
Numbers can be your ally when asking for money When asking for money, talk your managements language not ours Dont be casual about numbers, be precise If you want to learn more, read my book

VIII 1 ReiferCase

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VIII 1 ReiferCase

Uploaded by

Copyright:

Available Formats

USC

University of Southern California

Center for Software Engineering

Business Case Analysis

University of Southern California and Reifer Consultants, Inc.

University of Southern California

Center for Software Engineering

University of Southern California

Center for Software Engineering

Why Write a Book on Software Business Cases?

University of Southern California

Center for Software Engineering

I Didnt Write it for the Money

University of Southern California

Center for Software Engineering

Part II - The Case Studies

Copyright RCI, 2001

University of Southern California

Center for Software Engineering

Appendix A: Recommended Readings Appendix B: Compound Interest Tables Acronyms Glossary

University of Southern California

Center for Software Engineering

Unique Features of Book

Look for updates Converse with author

Realistic case studies Actual management briefings as part of case studies

University of Southern California

Center for Software Engineering

Making the leap forward involves overcoming the resistance to change

University of Southern California

Center for Software Engineering

Success is a Numbers Game

University of Southern California

Center for Software Engineering

Business Cases Supply You with the Numbers

University of Southern California

Center for Software Engineering

Business Process Framework

Business Planning Process

Tradeoff and Analysis Processes

Principles, Rules and Tools for Business Case Development

University of Southern California

Center for Software Engineering

The Business Planning Process

7. Get ready to execute

2. Demonstrate technical feasibility 3. Conduct market survey

4. Develop business plan

University of Southern California

Center for Software Engineering

Nine Business Case Principles

Copyright RCI, 2001

University of Southern California

Center for Software Engineering

Many Rules to Use as Guidelines

Copyright RCI, 2001

University of Southern California

Center for Software Engineering

Many Tools and Techniques

Copyright RCI, 2001

University of Southern California

Center for Software Engineering

Software cost models

University of Southern California

Center for Software Engineering

Use Engineering Economics As Your Basis