Business Case Analysis Barry Boehm CS 510 Fall

Business Case Analysis Barry Boehm CS 510, Fall 2017 v 2 of 9/24/2017 Adapted from Donald J. Reifer’s 2005 lectures Fall 2017 ©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 2017 ©RCI, USC-CSSE 2

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 2017 ©RCI, USC-CSSE 3

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 2017 ©RCI, USC-CSSE 4

Business Cases Address Stakeholder Values Benefits Chains Help Identify These Fall 2017 ©RCI, USC-CSSE 5

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 2017 6. Decisions should consider 1. Do nothing, learn by themselves 2. On-the-job training and both quantitative 3. Bring a training seminar save How can in seminar / hands-on qualitative factors training costs / save time / improve quality ? 7. The risks associated with Calculate that in $$ Whatdecision in the past, stay in the happened should be the past. quantified if possible Already ran a java seminar last year ? $10 today = $8 associated 8. it doestiming next. New staff with The not matter. year Save in the bank, %6 interest making decisions is critical Any better option ? 9. If you select a training firm, should Decision processes use different criteria, don’t mix them up. be periodically assessed and continuously improved ©RCI, USC-CSSE 6

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 2017 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

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 2017 ©RCI, USC-CSSE 8

Organizational Structure Senior Management Your home Aerospace firm QA Group Process Group Senior Staff Engineering Manufacturing * Systems * Software * Digital design * Fabrication * Assembly * Production Fall 2017 Field Support Program Mgmt * Field service Line of Business * Training Management * Test & evaluation * Fund functional groups Project A * Coordinate * Facilitate ©RCI, USC-CSSE 9

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 Reach Level 3 corporate goal 1 1985 Fall 2017 1989 Process group reformed 1991 1993 ©RCI, USC-CSSE 1995 1997 1999 Now 10

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 2017 ©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 2017 ©RCI, USC-CSSE The Software CMM Contains: - 5 Maturity Levels - 18 Key Process Areas - 318 Key Practices 12

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 (20 X cheaper error) • The average increase in productivity attributable to process improvement is 10 percent per level Fall 2017 ©RCI, USC-CSSE 13

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 2017 ©RCI, USC-CSSE 14

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 2017 SEI Maturity Model ©RCI, USC-CSSE Non-discounted ROI 15

Process Group Budget = $2. 4 M/year • Process development – 4 employees ($700 K) • Education & training – 2 part-timers ($200 K) – $250 K for seminars • Process assessment – $200 K for outside facilitator • Promotion and outreach – $250 K to prepare newsletter, work with clients and attend conferences • Process roll-out/project support • Support environment – 2 consultants ($450 K) – Retirees with credibility Fall 2017 – $350 K for web site development ©RCI, USC-CSSE 16

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 2017 ©RCI, USC-CSSE 17

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 defects 1/KSLOC)(500 KSLOC/job) = 60 Kdefects/year (60 K defects/year)($20/defect (avoidance)) = $1. 2 million/year 1 As jobs enter test and evaluation; goal is 0. 1 defect/KSLOC on delivery Fall 2017 ©RCI, USC-CSSE 18

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 2017 ©RCI, USC-CSSE 19

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 2017 – Have no control over the product’s evolution ©RCI, USC-CSSE 20

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 2017 ©RCI, USC-CSSE 21

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 2017 ©RCI, USC-CSSE Operations & Maintenance Project-specific deliverables 22

COCOMO II Reuse Model ESLOC = ASLOC [AA + AAF(1 + 0. 02(SU)(UNFM))] 100 AAF < 50 ESLOC = ASLOC [AA + AAF + (SU)(UNFM)] 100 AAF > 50 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 2017 ©RCI, USC-CSSE 23

The Impact of Reuse Conservative estimate of savings is $10 million/year, minus cost of $2 million/year in evolving reusable assets Fall 2017 ©RCI, USC-CSSE 24

Reuse Cost/Benefit Worksheet • Non-Recurring Costs • Tangible Benefits – Domain engineering – $500 K – Reusable assets – added $1000 K – Infrastructure creation – $500 K • Recurring Costs (per year) – Architecture maintenance $500 K – Asset maintenance 1500 K Total Costs Fall 2017 $2 M + $2 M/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 ©RCI, USC-CSSE $10 million 25

Strategy Yields Positive Returns Early Error Reduction • Cost avoidance = $1. 2 M/year • Increased customer satisfaction based on quality Systematic Reuse • Cost avoidance = $10 M/year • Faster to market • Can be built by enhancing first-project assets • COCOMO added cost $2 M • Process can be built with reuse in mind Fall 2017 Exploitation of COTS • Cost avoidance = $1 M/year • Improved maintenance and license leverage with vendors Productivity Improvement • Cost avoidance = $7. 5 M/year • Improved capabilities & capacity ©RCI, USC-CSSE 26

Return-On-Investment Is High • • • Annual Software Staff Cost: 500 * $150 K/yr = $75 M/yr Process Group Cost: 2 * $2. 4 M/yr = $4. 8 M 3 week staff training cost: $75 M *. 06 = $4. 5 M Developing reusable assets: $2 M Initial investment cost: $11. 3 M over 2 years Annual evolution cost: $3 M: $1 M process; $2 M reusable assets Annual benefits $19. 7 M: Reuse $10 M, COTS $1 M; EER $1. 2 M; Productivity 10% 0 f $75 M/year = $7. 5 M/year Cumulative ROI: (Benefits –Costs)/Costs After year 1: ($19. 7 M - $14. 3 M)/$14. 3 M = 38% After year 2: ($39. 4 M - $17. 3 M)/$17. 3 M = 128% After year 3) ($59. 1 M - $20. 3 M)/$20. 3 M = 191% Fall 2017 ©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 2017 ©RCI, USC-CSSE 28

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 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 2017 ©RCI, USC-CSSE 29

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 2017 ©RCI, USC-CSSE 30

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 2017 ©RCI, USC-CSSE 31