Upload
bryce-haynes
View
214
Download
1
Embed Size (px)
Citation preview
©RCI, USC-CSSE 1
Business Case Analysis
Adapted from Donald J. Reifer’s 2005 lectures
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Barry BoehmCS 510, 577, Fall 2014
09/22/2014
09/22/2014 ©RCI, USC-CSSE 2
Business Cases in ICSM Decision MilestonesFeasibility 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
©RCI, USC-CSSE 3
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 rejects many of these recommendations
if the business benefits are not quantified
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 4
Pervasive Issues When Developing Business Justifications
USC
C S E University of Southern CaliforniaCenter for Software Engineering
• 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
09/22/2014
©RCI, USC-CSSE
Benefit Chain Diagram
• A good example
509/22/2014
©RCI, USC-CSSE 6
Nine Business Case Principles1. 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
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
1. Do nothing, learn by themselves2. On-the-job training3. Bring in seminar / hands-on
training How can a training seminar save costs / save time / improve quality ? Calculate that in $$
thinking about running a seminar.
What happened in the past, stay in the past. Already ran a java seminar last year ? it does not matter. New staff$10 today = $8 next yearSave in the bank, %6 interestAny better option ?If you need select a training firm, use different criteria, don’t mix them up.
09/22/2014
©RCI, USC-CSSE 7
Nine Business Case Principles6. 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Training seminar might improve image and morale.
What if no trainer available , any back up plan ? What is the extra cost?
thinking about running a seminar.
Time your decision carefully. Any budget cycle ?Propose when there is money available.
Keep your eyes open, look for possible improvement.
09/22/2014
©RCI, USC-CSSE 8
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 9
Organizational Structure
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Senior Management
Engineering Field SupportManufacturing Program Mgmt
Process GroupQA Group
Senior Staff
* Systems * Fabrication * Field service* Software * Assembly * Training* Digital design * Production * Test & evaluation
Project A
Line of BusinessManagement
* Fund functional groups* Coordinate * Facilitate
Yourhome
Aerospace firm
09/22/2014
©RCI, USC-CSSE 10
History of Process Improvement
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Maturity Level
1985 1987 1989 1991 1993 1995 1997 1999 Now
Level 3 -a customerrequirement
Reach Level 3 - corporate goal
5
4
3
2
1
Processbudgetaxed
Acquisitionfalls through
Firm positionedto be acquired
Process groupreformed
Seniorsget serious
about process
Aim- ReachLevel 4
in 2 years
09/22/2014
©RCI, USC-CSSE 11
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 12
The Software
CMM
- Requirements management- Software project planning- Software project tracking and oversight- Software subcontract management- Software qualify assurance- Software configuration management
- Organization process focus- Organization process definition- Training program- Integrated software management - Software product engineering- Inter-group coordination- Peer reviews
- Quantitative process management - Software quality management
- Defect prevention- Technology change management - Process change management
3
2
4
5
Contains:- 5 Maturity Levels- 18 Key Process Areas- 318 Key Practices
09/22/2014
©RCI, USC-CSSE 13
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 14
Rules of Engagement• Let the numbers do the talking• Don’t assume that Program Managers understand
software (many are clue-less)• 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 15
Start - Why Focus on Process?
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Why (Goal):
Questions:
Metrics:
Models:
Increase Productivity and Meet Customer Requirements
Measured What Why this how? option? option?
SLOC/hour Do Process Other ROI Nil improvement approaches
COCOMO SEI Maturity Non-discounted Model ROI
09/22/2014
©RCI, USC-CSSE 16
Process Group Budget = $2.4M/year• Process development
– 4 employees ($700K)
• Education & training– 2 part-timers ($200K)– $250K for seminars
• Process roll-out/project support– 2 consultants ($450K)– Retirees with
credibility
• Process assessment– $200K for outside
facilitator
• Promotion and outreach– $250K to prepare
news-letter, work with clients and attend conferences
• Support environment– $350K for web site
development
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 17
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 architecture-
based reuse strategy • Show intangibles as added value
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 18
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:
USC
C S E University of Southern CaliforniaCenter for Software Engineering
(12 jobs/year)(10 defects1/KSLOC)(500KSLOC/job) = 60Kdefects/year(60K defects/year)($20/defect (avoidance)) = $1.2 million/year
1 As jobs enter test and evaluation; goal is 0.1 defect/KSLOC on delivery
09/22/2014
©RCI, USC-CSSE 19
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 20
COTS Pluses and Minuses
• Cheaper; but does not come for free
• Available immediately• Known quality (+ or -)• Vendor responsible for
evolution/maintenance– 15-20% annual fee
• Can use critical staff resources elsewhere
• License costs can be high• COTS products are not
designed to plug & play• Vendor behavior varies• Vendor responsible for
evolution/maintenance– Have no control over
the product’s evolution
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Pluses Minuses
09/22/2014
©RCI, USC-CSSE 21
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 22
Reuse-Based Development Paradigm
DomainAnalysis
Domain Design
Domain Model
AssetDevelopment
Requirements Software Integration Operations & Analysis Development & Test Maintenance
Software Reuse LibraryArchitecture
Project-specific deliverables
Products for sale
Scope
Requirements
Purchased products
Domain EngineeringAssets
Assets
Applications Engineering
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 23
COCOMO II Reuse ModelESLOC = ASLOC [AA + AAF(1 + 0.02(SU)(UNFM))] AAF < 0.5 100
ESLOC = ASLOC [AA + AAF + (SU)(UNFM)] AAF > 0.5 100
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 24
The Impact of Reuse
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Without Reuse With ReuseNominal Development Time (months) 30 23.4Nominal Effort (staff-months) 845.3 383.7Shortest Development Time (months) 22.5 17.6Shortest Development Time Effort 1208.7 548.7
Application Without Reuse With ReuseReal-time executive 10,000 500Scheduler 25,000 500Real-time data acquisition 50,000 10,000Sensor data processing 50,000 21,000Data analysis and alarms 25,000 10,000
TOTAL 160,000 42,000
Conservative estimate of savings is $10 million/year, minus cost of $2 million/year in evolving reusable assets
09/22/2014
©RCI, USC-CSSE 25
Reuse Cost/Benefit Worksheet• Non-Recurring Costs
– Domain engineering – $500K– Reusable assets – added $1000K– Infrastructure creation – $500K
• Recurring Costs (per year)– Architecture maintenance $500K– Asset maintenance 1500K
• Tangible Benefits– 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Total Costs $2M + $2M/yr Total Benefits $10 million09/22/2014
©RCI, USC-CSSE 26
Strategy Yields Positive Returns Early Error Reduction• Cost avoidance = $1.2M/year• Increased customer satisfaction based on quality
Exploitation of COTS• Cost avoidance = $1M/year• Improved maintenance and license leverage with vendors
Productivity Improvement• Cost avoidance = $7.5M/year• Improved capabilities & capacity
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 27
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%
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
ROI Includes IntangiblesInclude these in briefings
©RCI, USC-CSSE 28
• Better product quality
• Quicker to market
• Increased customer satisfaction
• Improved employee morale
• Responds directly to customer needs
09/22/2014
©RCI, USC-CSSE 29
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 30
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 31
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014
©RCI, USC-CSSE 32
Lots of Available Web ResourcesTopic Web Resources
Engineeringeconomics andbusiness cases
www.isye.gatech.edu (Georgia Institute of Technology) - The WWW virtual library of industrial engineering with information
on academic programs, conferences, courses, publications whichemphasize their engineering economics core expertise area
Computereconomics andbusiness cases
http://info.berkeley.edu/resources/infoecon (UC Berkeley) - Economics of the Internet with pointers to sites on E-Commerce, E-
Publishing, intellectual property, etc.www.computereconomics.com - IT cost management support including industry benchmarks- E-Business strategies and market forecastswww.hbsp.harvard.edu (Harvard Business School) - Access to case studies on E-Commerce and the Internet, change
management, entrepreneurship and new technologySoftwareeconomics andbusiness cases
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) effortswww.software.org (Software Productivity Consortium) - Practical measurement techniques including controlled access to their
guidebooks, case studies and lessons learned reportsAddison-Wesleysite for this book
www.aw.com/softwarebusinesscases - Updates to this book, student exercises and pointers to additional
useful information
USC
C S E University of Southern CaliforniaCenter for Software Engineering
09/22/2014