The Role of Business Case Analysis in Software Engineering

1. 10/22/2001 Copyright RCI, 2001 1 The Role of Business Case Analysis in Software Engineering Donald J. Reifer Guest Lecturer USC Center for Software Engineering

2. 10/22/2001 Copyright RCI, 2001 2

3. 10/22/2001 Copyright RCI, 2001 3 For Software, Change is Constant

4. 10/22/2001 Copyright RCI, 2001 4 Impacts in Making Needed Changes Are Many Technical changes Paradigms, methods and tools engineers use to do the work Management changes Infrastructure, methods & tools managers use to plan, organize, staff, direct and control the work Organizational changes Decision-making infrastructure seniors used to establish vision and guide action

5. 10/22/2001 Copyright RCI, 2001 5 Business Cases Focus on Quantifying Impact of Changes As understood by most, engineering decisions involve many options and difficult tradeoffs May be several feasible solutions for the problem The optimal solution is determined by evaluating the tradeoffs in the many dimensions of the solution space Cost/schedule, functionality and performance envelopes Software engineering provides you the methods and tools to understand the tradeoffs and select the best answer (typically under constraints)

6. 10/22/2001 Copyright RCI, 2001 6 This Role Is Controversial I cannot recommend this book to be part of the SEI Series on Software Engineering. First, it does not really address engineering issues. Rather, it discusses how business reasoning and models apply to a variety of issues confronting software organizations. This is of value and important to such organizations. However, it is somewhat outside of the scope of software engineering. So, in my judgment, it is outside the scope of the series, although relevant due primarily to cases or illustrations described in the manuscript. ----- SEI Reviewer

7. 10/22/2001 Copyright RCI, 2001 7 What Are we Going to Cover? 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 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

8. 10/22/2001 Copyright RCI, 2001 8 Coverage (Continued) Part III - Finale Chapter 9: Overcoming Adversity: More Than a Pep Talk Appendix A: Recommended Readings Appendix B: Compound Interest Tables Acronyms Glossary

9. 10/22/2001 Copyright RCI, 2001 9 View Software As A Business

10. 10/22/2001 Copyright RCI, 2001 10 Understand the Software Industry is in Constant Turmoil

11. 10/22/2001 Copyright RCI, 2001 11 Improvement Framework

12. 10/22/2001 Copyright RCI, 2001 12 Making the Leap Forward

13. 10/22/2001 Copyright RCI, 2001 13 CMMI Level 5 - Technology Innovation Seven Step Process Establish improvement objectives Improvement proposal collection & analysis Identify innovations Perform cost/benefit analysis Perform pilot Select candidate improvements Provide feedback

14. 10/22/2001 Copyright RCI, 2001 14 Challenges Associated with Making Organizational Changes Lack of incentives “Good of the firm” versus “Good of the project” Infrastructure shortfalls Few meaningful metrics Limited cash available Reward system must be altered Reward system must be altered to emphasize “good of firm” Policies, processes and decision making structure changes Must collect data to quantify impact of changes To get funded, must make compelling business case

15. 4/18/97 Copyright RCI, 1997 15 Many Obstacles to Change Organizations fight changes for many reasons

16. 10/22/2001 Copyright RCI, 2001 16 Making Changes: Eight Lessons Learned Tie improvement to organizational goals Emphasize making product-oriented improvements Demonstrate value that justifies improvements Make new processes how you do business Recognize major barriers are psychological & political Change your culture to one that rewards risk-taking If you don’t have the talent, buy it Use numbers to overcome post-decision dissonance

17. 10/22/2001 Copyright RCI, 2001 17 Why Change - Five Good Reasons? Keeping up with the competition Playing catch-up is always a motivation for change Achieving economic benefits Having a compelling business reason also works Supporting new product needs Tying change to a product need justifies investment Avoiding legal entanglements Sometimes changes are needed to comply with the law Achieving efficiencies Streamlining/simplifying process also justifies change

18. 10/22/2001 Copyright RCI, 2001 18 Are You Ready for Change? Examine the following: Consistency with business goals Compatibility with level of process maturity Consistency with corporate culture Compatibility with investment strategies Achievability within desired timetable If warranted, be willing to take the risk The opportunity should be justifiable in terms of the risk/returns

19. 10/22/2001 Copyright RCI, 2001 19 Corporate Cultures Compared Seeks opportunity for improvement Action-oriented and willing to take risks Team-oriented Rewards innovation Learns from failure Creative, imaginative, pliant and flexible Prefers the status quo Avoids change and risk Territorial by nature Rewards followers, not innovators Penalizes failure Persistent, authoritative and rigid

20. 10/22/2001 Copyright RCI, 2001 20 Success is a Numbers Game 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? + Many more tough questions

21. 10/22/2001 Copyright RCI, 2001 21 Business Cases Supply You with the Numbers Business Case = the materials prepared for decision-makers 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 to complement the technical case can greatly increase their chances of success

22. 10/22/2001 Copyright RCI, 2001 22 Business Versus Technical Cases

23. 10/22/2001 Copyright RCI, 2001 23 Business Versus Technical Cases

24. 10/22/2001 Copyright RCI, 2001 24 The Business Planning Process

25. 4/18/97 Copyright RCI, 1997 25 Aligning Goals as the First Step

26. 10/22/2001 Copyright RCI, 2001 26 Let’s Step Through the Process Prepare white paper State what you are trying to do crisply Demonstrate technical feasibility Let’s you prove the idea’s value Let’s management see, smell and touch evidence that you can deliver as promised Conduct market survey Determine the market need for your idea Understand what the competition is doing and what your customers want Focus on market creation, not sharing Get to market first, be nimble and take risks to seize the opportunity

27. 10/22/2001 Copyright RCI, 2001 27 More on the Process Develop business plan Needed before idea will be funded Such plans summarize how you will make or save money, not how you’ll get the job done Prepare business case Convince sponsor idea makes both good technical and business sense Sell the idea Package for sales/champion Get ready to execute Plan the project thoroughly Start recruiting key staff Work communications and outreach Search out facilities to co-locate team and for demos Prepare your operational concepts

28. 10/22/2001 Copyright RCI, 2001 28 Business Process Framework

29. 10/22/2001 Copyright RCI, 2001 29 Nine Business Case Principles Decisions should be 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 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

30. 4/18/97 Copyright RCI, 1997 30 Success Tactics Address the cultural issues first - they’re the hardest Keep senior management informed of your progress Build alliances with programs and people Publicize successes and spread the word widely Mix it with the middle managers and critics Don’t be afraid to change in mid-stream Deliver something that you can brag about Be perceived as successful by others Work continuously to improve the improvement infrastructure you’ve set up

31. 10/22/2001 Copyright RCI, 2001 31 Use Engineering Economics as its Analytical Basis Takes cost of money into account A $$ today is worth more than tomorrow due to inflation Takes compounding into account Normalizes future expenditures using current year dollars as a basis for comparison Lets you establish a minimum attractive rate of return

32. 10/22/2001 Copyright RCI, 2001 32 Many Available Techniques Break-even analysis Cause and effect analysis Cost/benefit analysis Value chain analysis Investment opportunity analysis Pareto analysis Payback analysis Sensitivity analysis Trend analysis

33. 10/22/2001 Copyright RCI, 2001 33 Example - Cost Benefit Analysis Want to bring in training to learn a modern set of methods How would you justify the investment? Should you use Cost Benefits, ROI or other approach? How would you pay for the training? Is this a capital, project or customer expense? What are the windows of opportunity and how would you capitalize on them? Is there State funds available? Can we partner? Is there mid-year or year-end funds available?

34. 10/22/2001 Copyright RCI, 2001 34 Doing a Cost Benefit Analysis Non-recurring costs Course acquisition ____ Course conduct ____ Recurring costs Course maintenance ____ Continuing education ____ Tangible savings Cost avoidance ____ Cost savings ____ Intangible savings Reduced turnover ____ Improved morale ____

35. 10/22/2001 Copyright RCI, 2001 35 Getting Management Approval Why should they invest in training instead of other alternatives? There needs to be a compelling business reason, else why make the effort This must be the most attractive option examined Why invest now instead of some later time? Need to show problem is important & funds are available What do I have to do if I say yes to the proposal? Must show them that their efforts will be minimal; you’ve done all of the leg work and all they have to do is sign

36. 10/22/2001 Copyright RCI, 2001 36 Many Supportive Tools 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

37. 10/22/2001 Copyright RCI, 2001 37 Including Estimating Models like COCOMO II - Of Course

38. 10/22/2001 Copyright RCI, 2001 38 Business Case Information Needs Business cases Recurring costs Non-recurring costs Tangible benefits Intangible benefits Benchmarks Competitive comparisons Industry norms Metrics Management measures Financial data Inflated labor costs Labor categories/rates Overhead/G&A rates Past costs/performance Tax rates/legalities Marketing information Demographic data Market position Sales forecast

39. 10/22/2001 Copyright RCI, 2001 39 Plan to Emphasize Cost Avoidance Justify using cost avoidance not reduction Keep cost & productivity considerations separate Tap money when it becomes available Know what cost you can control and who controls the others Package numbers for consumption by seniors Don’t assume the numbers won’t be scrutinized Don’t assume you know what your current costs are and how they are allocated to cost centers Don’t confuse management by combining cost and profit in same proposal Don’t mix cost accounts when justifying ideas

40. 10/22/2001 Copyright RCI, 2001 40 Packaging Business Cases for Management Consumption Convincingly summarize the numbers at the start Define your terms precisely - communicate meaning using examples Be conservative with your numbers Quantify tangible benefits in monetary terms Don’t mix capital expenditures with project budgets Use ranges for cost/benefits whenever possible Portray the PV of your benefits in this year’s dollars Focus attention on the business, not technical issues

41. 10/22/2001 Copyright RCI, 2001 41 When Communicating with Senior Managers, Remember They are like elephants, they never forget a number once uttered They will hear only what they want to hear Simple is better - package charts with at most five bullets

42. 10/22/2001 Copyright RCI, 2001 42 Chapter 5 - 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

43. 10/22/2001 Copyright RCI, 2001 43 Organizational Structure

44. 10/22/2001 Copyright RCI, 2001 44 History of Process Improvement

45. 10/22/2001 Copyright RCI, 2001 45 The SEI Software CMM 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

46. 10/22/2001 Copyright RCI, 2001 46 The Software CMM

47. 10/22/2001 Copyright RCI, 2001 47 CMM Lessons Learned Takes 18 to 30 months to move a maturity level From Level 1 to 2 - average of 25 months From Level 2 to 3 - average of 23 months From Level 3 to 4 - average of 36 months Average investment to move up a maturity level is several million The gains attributable to early error detection and correction are substantial (20X cheaper) The average increase in productivity attributable to process improvement is 10 percent

48. 10/22/2001 Copyright RCI, 2001 48 Software Improvement Strategy

49. 10/22/2001 Copyright RCI, 2001 49 More Background Information Overall experience Workforce averages 20 years experience Staff capabilities and morale Good - newcomers more open to change Education & training Myriad of training opportunities available World-class facilities and environment Undercapitalized, but making improvements primarily to reduce personnel turnover Technology adoption IR&D for software tripled after major client criticized management

50. 10/22/2001 Copyright RCI, 2001 50 Rules of Engagement Let the numbers do the talking Don’t assume that Program Managers understand software (they 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

51. 10/22/2001 Copyright RCI, 2001 51 Process Group Organization

52. 10/22/2001 Copyright RCI, 2001 52 Start - Why Focus on Process?

53. 10/22/2001 Copyright RCI, 2001 53 Recommended Process

54. 10/22/2001 Copyright RCI, 2001 54 Work Breakdown Structure Process development Education & training Process roll-out/project support Process assessment Promotion & outreach Support environment

55. 10/22/2001 Copyright RCI, 2001 55 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

56. 10/22/2001 Copyright RCI, 2001 56 Proposed Operational Concepts Process development Transition Deployment CM QA Distribution management User support Exploit industry experience by hiring outside assessment firm Pilot to demo feasibility, do things middle managers think important E&T JIT; dedicated project liaisons Steering group CCB; shared/reused assets distinction Use process to assure processes Access via web site FAQ; metrics; dedicated support for users

57. 10/22/2001 Copyright RCI, 2001 57 Your Justification Approach Justify process budget by: Showing the impact of accelerating productivity improvement from 10% to 20% annually Looking at impact of early error detection/correction Assessing the impact of COTS usage strategy Evaluating the impact of moving to an architecture-based reuse strategy Show intangibles as added value

58. 10/22/2001 Copyright RCI, 2001 58 Accelerating Productivity from 10 to 20 Percent Annually

59. 10/22/2001 Copyright RCI, 2001 59 Productivity Versus Cost Cost and productivity are related, but are influenced by different factors To increase your productivity, you should address: Staff skills/expertise, process maturity and tools To reduce cost, you should attack: Overhead, scope of the job and efficiencies There are cases where improvements in your productivity result in increased costs

60. 10/22/2001 Copyright RCI, 2001 60 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:

61. 10/22/2001 Copyright RCI, 2001 61 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

62. 10/22/2001 Copyright RCI, 2001 62 COTS Pluses and Minuses Cheaper; but does not come for free Available immediately Known quality (+ or -) Vendor responsible for evolution/maintenance Don’t have to pay for it Can use critical staff resources elsewhere 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 product’s evolution

63. 10/22/2001 Copyright RCI, 2001 63 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

64. 10/22/2001 Copyright RCI, 2001 64 COTS Success Strategies Process Merge COTS life cycle into your organizational framework Make needed tradeoffs Think both technical and business issues Products Fit COTS components into product line strategies Maintain open interfaces Manage technology refresh People Make COTS vendors a part of your team Increase awareness of COTS experience Provide workforce with structure and information Institutional Improve purchasing and licensing processes Maintain market watch Capture past performance

65. 10/22/2001 Copyright RCI, 2001 65 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 & use of high-leverage assets Establish the building blocks and codes 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

66. 10/22/2001 Copyright RCI, 2001 66 Three Views of an Architecture

67. 10/22/2001 Copyright RCI, 2001 67 Radar Architecture Example

68. 10/22/2001 Copyright RCI, 2001 68 Reuse-Based Development Paradigm

69. 10/22/2001 Copyright RCI, 2001 69 COCOMO II Reuse Model

70. 10/22/2001 Copyright RCI, 2001 70 The Impact of Reuse

71. 10/22/2001 Copyright RCI, 2001 71 Reuse Cost/Benefit Worksheet Non-Recurring Costs Domain engineering - done on IR&D Reusable assets - project funded Infrastructure development - done by process group Recurring Costs (per year) Architecture maintenance $200K Asset maintenance 500K Process updates 100K 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

72. 10/22/2001 Copyright RCI, 2001 72 Strategy Yields Positive Returns

73. 10/22/2001 Copyright RCI, 2001 73 Return-On-Investment Is High Tangibles ROI = Annual Benefits Investment ROI = $6.2M $2.4M ROI > 250% per year Assumptions: cost avoidances on page 3 realized with exception of reuse which kicks in after we reach CMM level 4. Intangibles Better product quality Quicker to market Increased customer satisfaction Improved employee morale Responds directly to customer requirements

74. 10/22/2001 Copyright RCI, 2001 74 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 on our side (bonus is a good start) 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 moving

75. 10/22/2001 Copyright RCI, 2001 75 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

76. 10/22/2001 Copyright RCI, 2001 76 Final Points Before We Adjourn Numbers can be your ally when asking for money When asking for money, talk your management’s language not yours Don’t be casual about numbers, be precise To be successful, be perceived as successful

77. 10/22/2001 Copyright RCI, 2001 77 You Can Be Successful Change only if it makes good business sense Don’t become enamored with the technology Get everyone involved - but not too involved Focus changes on product developments Look to the future, not the past (sunk costs) Be patient and don’t reinvent the wheel Do the easy things first to establish credibility Be satisfied with a 90 percent solution The sum of many small successes is a big success

78. 10/22/2001 Copyright RCI, 2001 78 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

79. 10/22/2001 Copyright RCI, 2001 79 Lots of Available Web Resources

80. 10/22/2001 Copyright RCI, 2001 80 Chat Session - 10/29/2001 Scheduled for 7 to 8:20 am on 10/29/2001 Provide me your questions prior to end of the week My email is dreifer@earthlink.net I will sort them and develop answers over the weekend Hope this lecture has been stimulating

81. 10/22/2001 Copyright RCI, 2001 81 Parting Remarks