1. The Role of Business Case Analysis in Software Engineering Lecture #1
Supannika Koolmanojwong
Based on Donald J. Reifer’s lecture
Copyright RCI, 2005

2. Copyright RCI, 2005

3. For Software, Change is Constant
Other silver bullets
Reuse/patterns
Streamlined processes
Agile methods
Architecture-first
COTS-based systems
Process paradigms
Experience factory
Metrics-based
management
Component-based
composition
Best engineering
practices
Extreme programming
Product-lines
Searching for ways to do the job faster, better and cheaper
Copyright RCI, 2005

4. Business Cases Quantify the Impact of Such Changes
As understood by most, 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 because the business benefits are not quantified
Copyright RCI, 2005

5. 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
Copyright RCI, 2005

6. Justifying Improvement Initiatives to Address Change
Reduce Avoid/Cut
Improve
Customer
Satisfaction
Time to Market Cost
Productivity Quality
Increase Improve
There needs to be some compelling business reason
for making an improvement, else it won’t be approved
Copyright RCI, 2005

7. So now, you want to make some improvement.
How can we introduce the changes / improvement to the organization ?
Will they believe my idea?
Are they going to listen to me?

9. Technology Adoption Life Cycle Model
Stage in Life Cycle
Organizations’ Characteristics
Innovators
Risk takers
Develop new technology
Push the envelope
Early adopters
Trend setters
Advance technology
Will take high risks when justified
Early majority
Take moderate risks
Late majority
Followers
Exploit technology
Take limited risks
Laggards
Critics
Use proven technology
Risk averse
Copyright RCI, 2005

10. Example: 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
Source: Ahern, CMMI Distilled
Copyright RCI, 2005

11. 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
Copyright RCI, 2005

12. 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
Copyright RCI, 2005

13. Overcoming Resistance to Change
Organizations fight changes for many reasons
ISLAND
CULTURE
MIDDLE
MANAGEMENT
BARRIERS
WHY CHANGE-
WE’RE SUCCESSFUL
HACKER
MENTALITY
CUSTOMER
INCENTIVES
NEVER
ENOUGH $$
IGNORANCE
IS BLISS
MIDDLE
MANAGEMENT
BARRIERS
NEVER
ENOUGH TIME
NOT INVENTED
HERE (NIH)
Copyright RCI, 2005

14. Are You Ready for Change?
Examine the following:
Consistency with business goals/cycle
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
Copyright RCI, 2005

15. Changing Corporate Cultures
Entrepreneurial Culture Old-Fashioned Culture
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
Copyright RCI, 2005

16. Making Changes: Eight Lessons Learned the Hard Way
Tie improvement to organizational goals
Emphasize making product-oriented improvements
Demonstrate value that justifies improvements
Make your new processes the way you do business
Recognize major barriers to change are primarily political and psychological
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
Copyright RCI, 2005

17. Success is a Numbers Game
Answer Basic Business-Related Questions
Will this proposal save money, cut costs, increase productivity, speed development or improve quality?
Have you looked at the financial and tax 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
Copyright RCI, 2005

18. Business Cases Supply You with the Winning 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
Copyright RCI, 2005

19. Business Versus Technical Cases
Factors (5 is best) Java C/C++
- Core language features
- Degree of standardization & portability 3 4
- Object-oriented support
- Reuse facilities (library, browser, etc.) 3 4
- Web programming support
- Optimizing compilers available 4 5
- Bindings available
- Rich libraries available
- Compiler support tools available 4 5
- Inexpensive visual tools available 5 3
- Oriented toward your products 5 3
Score
Copyright RCI, 2005

20. Business Versus Technical Cases
Factors (5 is best) Java C++
- Popularity - improve resumes
- Training opportunities available
- Literature and books available
- Consultants & subcontractors available
with language skills
- Staff maintains competency in language/tools
- Retooling and retraining costs
- Transition costs associated with learning
curve (bring staff up to speed) ___ ___
Subtotal 24 33
Combined Score 67 77
Copyright RCI, 2005

21. The Business Planning Process
GQM Results
Idea or proposal
7. Get ready
to execute
1. Prepare
white paper
2. Demonstrate
technical feasibility
6. Sell the idea and
develop support base
3. Conduct
market survey
5. Prepare
business case
Proof of
Concept
4. Develop
business plan
Approval to
go-ahead
Copyright RCI, 2005

22. Aligning with Goals - Your First Step
Goal - successful technology transition
Q1 - ready for use? Q2 - benefits quantified? Q3 - costs of use
understood?
M1 - availability of tools M1 - cost avoidance in $ M1 - startup costs
M2 - availability of M2 - time-to-market delta M2 - operational
training M3 - quality delta costs
M3 - availability of M3 - opportunity
methods costs
M4 - availability of
infrastructure
Use the G-Q-M
Paradigm
Copyright RCI, 2005

23. Stepping 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
Provide management with early evidence that you can deliver what you promised them
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 agile and take risks that allow you to seize the opportunity
Copyright RCI, 2005

24. More on the Process Develop business plan Prepare business case
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 and provides value
Sell the idea
Package for sales/champion
Get ready to execute
Plan the project thoroughly (your project plan)
Start recruiting key staff
Work communications and outreach up front
Search out facilities to co-locate team and for conducting demos
Prepare your operational concepts (support, etc.)
Copyright RCI, 2005

25. Business Process Framework
Process The business planning process proceeds in parallel
Framework and interfaces with the software development process
“Principles, Rules and Tools for Business Case Development”
Business Planning Process
Tradeoff and Analysis Processes
Software Development Process
Analytical
Methods
Models
Guidelines for
Decision-Making
Copyright RCI, 2005

26. Assume you are moving towards java, but no one knows java You need to improve their skills What are the choices do we have here?
Copyright RCI, 2005

27. Let say you are thinking about running a seminar
Let say you are thinking about running a seminar. How can you make a business case on this?
Copyright RCI, 2005

28. Nine Business Case Principles
thinking about running a seminar.
Nine Business Case Principles
Decisions should be made relative to alternatives
If possible, use money as the common denominator
Sunk costs are irrelevant (Engineering Econ 101)
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
Do nothing, learn by themselves
On-the-job training
Bring in seminar / hands-on training
How can a training seminar save costs / save time / improve quality ?
Calculate that in $$
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 year
Save in the bank, %6 interest
Any better option ?
If you need select a training firm, use different criteria, don’t mix them up.
Copyright RCI, 2005

29. Nine Business Case Principles
thinking about running a seminar.
Nine Business Case Principles
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
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.
Copyright RCI, 2005

30. Success Tactics
Address the cultural issues first - they’re the hardest
Keep senior management informed of your progress
Build alliances with both projects and people
Publicize successes and spread the word widely
Mix it with the middle managers and critics
Don’t be afraid to change horses in mid-stream
Deliver something that you can brag about
Be perceived as successful by others (perception is reality)
Work continuously to improve the infrastructure you’ve set up to manage the initiative and transfer the technology
Copyright RCI, 2005

31. Use Engineering Economics as its Analytical 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
Normalizes future expenditures using current year dollars as a basis for comparison
Lets you establish a minimum attractive rate of return
Copyright RCI, 2005

32. Present Value Calculation for Training Example
Cost of Money or Interest rate = 8%
Assuming that the training will reduce the personnel turnover by from 6% to 3%
Reduce lost in productivity $35K a year
Year
Training Cost
Benefits
Net Benefits
1/(1+i)N
Present Value 1
$25K
$35K
$10K
0.9259
$9259 2
0.8573
$8753 3
0.7938
$7938 4
0.7350
$7350
$40K
$33120
Copyright RCI, 2005

33. Then calculate ROI Good choice ? ROI = net benefit / investment
Year
Training Cost
Benefits
Net Benefits
1/(1+i)N
Present Value 1
$25K
$35K
$10K
0.9259
$9259 2
0.8573
$8753 3
0.7938
$7938 4
0.7350
$7350
$40K
$33120
ROI = net benefit / investment
= $40,000 / $100,000 = 40% or 10% annually
Good choice ?
10% annually for manager – may not be a good idea
Put in the bank, no risks – get 8%
What can we do ?
Copyright RCI, 2005

34. Use Other Available Techniques
Analysis Techniques
Balanced scorecard
Break-even analysis
Cause and effect analysis
Cost/benefit analysis
Opportunity tress
Pareto analysis
Payback analysis
Portfolio analysis
Real options theory
Return-on-Investment/Capital
Risk analysis (exposure)
Sensitivity analysis
Trend analysis
Value chains
Source: Boehm, Software
Engineering Economics
Copyright RCI, 2005

35. Balanced Score Card
Used by managers to keep track of the execution of activities by the staff within their control and to monitor the consequences arising from these actions

36. Breakeven Analysis

37. Payback Analysis
Year
Training Cost
Benefits
Net Benefits
1/(1+i)N
Present Value 1
$25K
$35K
$10K
0.9259
$9259 2
0.8573
$8753 3
0.7938
$7938 4
0.7350
$7350
$40K
$33120
To determine the number of periods required to recover one’s investment
Payment period = investment /net savings
=($25K) / ($10K/year)
= 2.5 years
= the payback period for the first year’s investment is 2.5 years
Copyright RCI, 2005

38. Example – Cost/Benefit Analysis
Want to bring in training to support PSP/TSP initiative
How would you justify the investment?
Should you use cost/benefits, quality improvement or some 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 take advantage of them?
Can you influence next year’s training budget?
Is there State funds available? Can we partner? Is there mid-year or year-end funds available?
Copyright RCI, 2005

39. Doing a Cost/Benefit Analysis
Cost/Benefit Ratio = PV (Total costs ($)/Total Benefits ($))
Non-recurring costs
Course acquisition ____
Course conduct ____
Recurring costs
Course maintenance ____
Continuing education ____
Tangible savings
Cost avoidance ____
Cost savings ____
Intangible savings
Reduced turnover ____
Less risk exposure____
Total ____
Total ____
Total ____
Total Costs ____
Total ____
Total Benefits ____
Copyright RCI, 2005

40. Quantifying Avoidance: Software Dependability Opportunity Tree
Decrease
Defect
Risk
Exposure
Continuous
Improvement
Impact,
Size (Loss)
Prob (Loss)
Defect Prevention
Defect Detection
and Removal
Value/Risk - Based
Defect Reduction
Graceful Degradation
CI Methods and Metrics
Process, Product, People
Technology
Source: Boehm
Copyright RCI, 2005

41. - Loss due to unacceptable dependability
Quantifying Risk Exposure (RE) via a Profile: Time to Ship
- Loss due to unacceptable dependability
Many defects: high P(L)
Critical defects: high S(L)
Risk
Exposure
(RE)
Few defects: low P(L)
Minor defects: low S(L)
Time to Ship (Amount of Testing)
Source: Boehm
Copyright RCI, 2005

42. Example RE Profile: Time to Ship
- Loss due to unacceptable dependability - Loss due to market share erosion
Many defects: high P(L)
Critical defects: high S(L)
Many rivals: high P(L)
Strong rivals: high S(L) RE
Few rivals: low P(L)
Weak rivals: low S(L)
Few defects: low P(L)
Minor defects: low S(L)
Time to Ship (Amount of Testing)
Source: Boehm
Copyright RCI, 2005

43. Example RE Profile: Time to Ship
- Sum of Risk Exposures
Time to Ship (Amount of Testing) RE
Few rivals: low P(L)
Weak rivals: low S(L)
Many rivals: high P(L)
Strong rivals: high S(L)
Sweet
Spot
Many defects: high P(L)
Critical defects: high S(L)
Few defects: low P(L)
Minor defects: low S(L)
Source: Boehm
Copyright RCI, 2005

44. 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 opportunity is knocking & 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
Copyright RCI, 2005

45. Many Supportive Tools Software packages Decision support systems
Tax planning and schedules
Trade studies and analysis
Spreadsheets
Comparative analysis
Software cost models
Parametric analysis
Copyright RCI, 2005

46. Including Estimating Models like COCOMO II - Of Course
Sizing
Model
Risk
Model
* Benchmark analysis * Parametric analysis
* Comparative analysis * Trade studies
* Life cycle cost analysis * “What-if” analysis
Copyright RCI, 2005

47. 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
Copyright RCI, 2005

48. Emphasize Cost Avoidance
Things to Do Things Not to Do
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
Copyright RCI, 2005

49. 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
Copyright RCI, 2005

50. 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
Copyright RCI, 2005

51. Final Points So Far Numbers can be your ally when asking for money
When talking money, speak your management’s language not your own
Don’t be casual about numbers, be precise
To be successful, be perceived as successful
Copyright RCI, 2005

52. 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
Copyright RCI, 2005

53. Organizational Structure
Aerospace firm
Senior Management
Your
home
QA Group
Process Group
Senior Staff
Engineering
Manufacturing
Field Support
Program Mgmt
* Systems * Fabrication * Field service
* Software * Assembly * Training
* Digital design * Production * Test & evaluation
Line of Business
Management
* Fund functional
groups
* Coordinate
* Facilitate
Project A
Copyright RCI, 2005

54. History of Process Improvement
Maturity Level
Aim- Reach
Level 4
in 2 years
Process
budget
axed 5 4 3 2 1
Acquisition
falls through
Level 3 -
a customer
requirement
Seniors
get serious
about process
Firm positioned
to be acquired
Reach Level 3 -
corporate goal
Process group
reformed
Now
Copyright RCI, 2005

55. 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
Copyright RCI, 2005

56. The Software CMMI 5 4 3 2 Contains: - 5 Maturity Levels
- Defect prevention
- Technology change management
- Process change management 5 4
- Quantitative process management
- Software quality management
The Software CMMI
- Organization process focus
- Organization process definition
- Training program
- Integrated software management
- Software product engineering
- Inter-group coordination
- Peer reviews 3
- Requirements management
- Software project planning
- Software project tracking and oversight
- Software subcontract management
- Software qualify assurance
- Software configuration management
Contains:
- 5 Maturity Levels
- 18 Key Process Areas
- 318 Key Practices 2
Copyright RCI, 2005

57. 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
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
Copyright RCI, 2005

58. Software Improvement Strategy
Discipline the
Software Process
Standardize
Products
Professional
workforce
Quicken use of
new technology
* Proactive, not * Architecture- * Career paths * Project sponsors
reactive based * Skill-based for IR&D
* Optimizing * Massive reuse education and * Good idea
* CMM-based * Open systems training programs
* ISO-certified * Product lines * Distance * Technology
* Components learning roadmap
Copyright RCI, 2005

59. 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
Copyright RCI, 2005

60. 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
Copyright RCI, 2005

61. Process Group Organization
Manager
(New)
Curriculum
Developer
(Part-Timer)
Process
Developer
(Vacant)
Metrics
Analyst
(New)
Project
Liaison
(Consultant)
Process
Developer
(Vacant)
Project
Liaison
(Consultant)
Curriculum
Developer
(Part-Timer)
Copyright RCI, 2005

62. Start - Why Focus on Process?
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 approach
COCOMO SEI Maturity Non-discounted
Model ROI
Copyright RCI, 2005

63. Recommended Process Vision statement * WBS dictionary * Game plan
Positive public
relations
1. Involve the
Stakeholders
* Expectations
* Measures of
success
5. Promote the
results
Pilot
results
2. Develop a
vision and
strategy
4. Build
partnerships
3. Define the
work to be
performed
Vision
statement
* WBS dictionary
* Game plan
Copyright RCI, 2005

64. Work Breakdown Structure
Process development
Education & training
Process roll-out/project support
Process assessment
Promotion & outreach
Support environment
1.1 Write processes/practices
1.2 Review processes/practices
1.3 Improve process/practices
2.1 Develop/update courseware
2.2 Conduct courses
3.1 Pilot processes/gather feedback
3.2 Provide support to projects
3.3 Deploy metrics/statistical controls
3.4 Perform statistical analysis
4.1 Conduct periodic assessments
5.1 Promote results
5.2 Publish newsletter, articles, and so on
6.1 Establish web site
6.2 Establish process asset library
Copyright RCI, 2005

65. Process Group Budget = $2.4M/year
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
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
Copyright RCI, 2005

66. 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
Copyright RCI, 2005

67. 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
Copyright RCI, 2005

68. Accelerating Productivity from 10 to 20 Percent Annually
Conservative estimate of savings is $4 million/year
Copyright RCI, 2005

69. 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
Copyright RCI, 2005

70. 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 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
Copyright RCI, 2005

71. 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
Copyright RCI, 2005

72. COTS Pluses and Minuses
Pluses 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
Copyright RCI, 2005

73. 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
Copyright RCI, 2005

74. 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
Copyright RCI, 2005

75. 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
Copyright RCI, 2005

76. Three Views of an Architecture
Operational Architecture
- Information needs
- User functions
- Performance bounds
System Architecture
- Components and topology
- Networks and connectivity
- Capacity/performance
Technical Architecture
- Information processing standards
- Human-computer interface standards
Copyright RCI, 2005

77. Radar Architecture Example
Mathematical libraries
Activity
Managers
Measurement
Functions
Sensor
Manager
Inputs
Libraries
Posix kernel
Multi-threading executive
Platform
Copyright RCI, 2005

78. Reuse-Based Development Paradigm
Purchased products
Domain Model
Domain
Analysis
Asset
Development
Products
for sale
Domain
Design
Scope
Assets
Domain Engineering
Software Reuse Library
Requirements
Architecture
Assets
Requirements Software Integration Operations &
Analysis Development & Test Maintenance
Applications Engineering
Project-specific deliverables
Copyright RCI, 2005

79. COCOMO II Reuse Model
ESLOC = ASLOC [AA + AAF( (SU)(UNFM))] AAF < 0.5
100
ESLOC = ASLOC [AA + AAF + (SU)(UNFM)] AAF > 0.5
Where: AAF = 0.4 (DM) (CM) (IM)
SU = Software Understanding
(zero when DM = 0 & CM = 0)
UNFM = Programmer Unfamiliarity
AA = Assessment and Assimilation
ASLOC = Adapted SLOC
ESLOC = Equivalent new SLOC
Copyright RCI, 2005

80. The Impact of Reuse
Conservative estimate of savings is $10 million/year
Copyright RCI, 2005

81. 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 K
Process updates K
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
Total Costs $800K
Total Benefits $10 million
Copyright RCI, 2005

82. Strategy Yields Positive Returns
Early Error Reduction
Cost avoidance = $1.2M/year
Increased customer satisfaction based on quality
Systematic Reuse
Cost avoidance = $10M/year
Faster to market
10X quality
Just starting – expect to reap
benefits within 3 years
Process can be built with
reuse in mind
Exploitation of COTS
Cost avoidance = $1M/year
Improved maintenance and
license leverage with vendors
Productivity Improvement
Cost avoidance = $4M/year
Improved capabilities & capacity
Copyright RCI, 2005

83. 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
Copyright RCI, 2005

84. 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
Copyright RCI, 2005

85. 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
Copyright RCI, 2005

86. 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
Copyright RCI, 2005

87. You Can Be Successful Guidelines
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
Copyright RCI, 2005

88. 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
Copyright RCI, 2005

89. Lots of Available Web Resources
Copyright RCI, 2005