October 2005Copyright RCI, 20051 The Role of Business Case Analysis in Software Engineering Lecture...
-
Upload
tobias-holmes -
Category
Documents
-
view
214 -
download
1
Transcript of October 2005Copyright RCI, 20051 The Role of Business Case Analysis in Software Engineering Lecture...
October 2005 Copyright RCI, 2005 1
The Role of Business Case Analysis in Software Engineering
Lecture #1
Donald J. Reifer
Guest Lecturer
USC Center for Software Engineering
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 2
Why Write a Book on Software Business Cases?
• Over the years, I have observed that many software engineers don’t know how to justify proposed changes or improvements using either economic analyses methods or business cases
• In many of these cases, these engineers are trying to justify changes technically to managers who come from a non-technical background (financial, marketing, etc.)
• The book was written to serve as a textbook for teaching software engineers to win the battle of the budget
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 3
For Software, Change is Constant
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Agile methods Streamlined processes
Best engineeringpractices
Metrics-basedmanagement
COTS-based systemsArchitecture-first
Process paradigms
Component-basedcomposition
Reuse/patterns
Product-lines Extreme programming
Experience factory
Searching for ways to do the job faster, better and cheaperSearching for ways to do the job faster, better and cheaper
Other silver bullets
October 2005 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 5
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
October 2005 Copyright RCI, 2005 6
What Are we Going to Cover?
• Part I - Fundamental Part I - Fundamental ConceptsConcepts– Chapter 1Chapter 1: Improvement is
Everybody’s Business
– Chapter 2Chapter 2: Making a Business Case
– Chapter 3Chapter 3: Making the Business Case: Principles, Rules, and Analysis Tools
– Chapter 4Chapter 4: Business Cases that Make Sense
• Part II - The Case StudiesPart II - The Case Studies– Chapter 5Chapter 5 - Playing the Game of
Dungeons and Dragons: Process Improvement Case Study
– Chapter 6Chapter 6: Quantifying the Costs/Benefits: Capitalizing Software Case Study
– Chapter 7Chapter 7: Making Your Numbers Sing: Architecting Case Study
– Chapter 8Chapter 8: Maneuvering the Maze: Web-Based Economy Case Study
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Making the Software Business Case: Improvement by the Numbers
October 2005 Copyright RCI, 2005 7
Coverage (Continued)• Part III - FinalePart III - Finale
– Chapter 9Chapter 9: Overcoming Adversity: More Than a
Pep Talk
• Appendix AAppendix A: Recommended Readings
• Appendix BAppendix B: Compound Interest Tables
• AcronymsAcronyms
• GlossaryGlossary
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 8
Understand the Software Industry is in Constant Turmoil
Marketplace modelin transition
USC
C S E University of Southern CaliforniaCenter for Software Engineering
End-user programming
Computer as an appliance
Collaboration viaseamless networks
Systems of systemsconcepts
Software continuesto provide the edge
Global workforce
October 2005 Copyright RCI, 2005 9
Justifying Improvement Initiatives to Address Change
Time to Market Cost
Productivity Quality
Reduce Avoid/Cut
Increase Improve
There needs to be some compelling business reason for making an improvement, else it won’t be approved
USC
C S E University of Southern CaliforniaCenter for Software Engineering
ImproveCustomer
Satisfaction
October 2005 Copyright RCI, 2005 10
Relationships Can Be Deceptive
Drives Produces
Productivity
Cycle Time
Quality
Cost
Market Share, Profit
Customer Satisfaction
FewerFailures
ReducedEffort
IncreasedCapacity
ReducedRework
ShorterSchedules
Lower Support & Maintenance Costs
Time-to-Market
LowerPrice
HigherMargin,Low-costProvider
Image
Retention,Referrals,Bonuses,Award Fee
PrimaryIndicators
SecondaryIndicators
BusinessGoals
Legend Primary Indicator
Secondary Indicator
Business Goals
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Source: SSCI ROI framework
October 2005 Copyright RCI, 2005 11
So Can the Process of Making the Leap Forward
Innovators
Early Adopters
Early Majority
LateMajority
Laggards
Source: G. Moore, Crossing the Chasm
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Change takes time and is hard to accomplish
October 2005 Copyright RCI, 2005 12
Example: CMMI Level 5 - Technology Innovation Seven-Step Process
1. Establish improvement objectives
2. Improvement proposal collection & analysis
3. Identify innovations
4. Perform cost/benefit analysis
5. Perform pilot
6. Select candidate improvements
7. Provide feedback Source: Ahern, CMMI Distilled
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 13
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 14
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 15
Overcoming Resistance to Change• Organizations fight changes for many reasons
WHY CHANGE-WE’RE SUCCESSFUL
MIDDLE MANAGEMENT BARRIERS
MIDDLE MANAGEMENT BARRIERS
NEVERENOUGH TIME
IGNORANCE IS BLISS
ISLANDCULTURE
HACKER MENTALITY
NOT INVENTED HERE (NIH)
NEVERENOUGH $$
CUSTOMERINCENTIVES
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 16
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 17
Changing Corporate Cultures
• 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
Entrepreneurial Culture Old-Fashioned Culture
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 18
Making Changes: Eight Lessons Learned the Hard Way
1. Tie improvement to organizational goals
2. Emphasize making product-oriented improvements
3. Demonstrate value that justifies improvements
4. Make your new processes the way you do business
5. Recognize major barriers to change are primarily political and psychological
6. Change your culture to one that rewards risk-taking
7. If you don’t have the talent, buy it
8. Use numbers to overcome post-decision dissonance
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 19
Business Goal Alignment Techniques
• Five force analysis• Seven-S framework analysis• Value chain analysis• Normative forecasting• Scenario writing• Critical success factor analysis• Customer satisfaction surveys• Process benchmarking
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 20
Success is a Numbers Game
USC
C S E University of Southern CaliforniaCenter for Software Engineering
• 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 questionsMany more tough questions
Answer Basic Business-Related QuestionsAnswer Basic Business-Related Questions
October 2005 Copyright RCI, 2005 21
Business Cases Supply You with the Winning Numbers
• Business CaseBusiness 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 22
Business Versus Technical CasesFactors (5 is best) Java C/C++- Core language features 2 4- Degree of standardization & portability 3 4- Object-oriented support 3 5- Reuse facilities (library, browser, etc.) 3 4- Web programming support 5 2- Optimizing compilers available 4 5- Bindings available 5 5- Rich libraries available 4 4- Compiler support tools available 4 5- Inexpensive visual tools available 5 3- Oriented toward your products 5 3
Score 43 44
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 23
Business Versus Technical CasesFactors (5 is best) Java C++ - Popularity - improve resumes 5 5- Training opportunities available 5 4- Literature and books available 5 5- Consultants & subcontractors available 5 5 with language skills- Staff maintains competency in language/tools 2 4- Retooling and retraining costs 1 5- Transition costs associated with learning 1 5 curve (bring staff up to speed) ___ ___
Subtotal 24 33Combined Score 67 77
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 24
The Business Planning Process
USC
C S E University of Southern CaliforniaCenter for Software Engineering
1. Prepare white paper
2. Demonstratetechnical feasibility
3. Conduct market survey
4. Developbusiness plan
5. Preparebusiness case
6. Sell the idea anddevelop support base
7. Get ready to execute
GQM Results
Idea or proposal
Proof ofConcept Approval to
go-ahead
October 2005 Copyright RCI, 2005 25
Aligning with Goals - Your First Step Goal - successful technology transition
Q1 - ready for use? Q2 - benefits quantified? Q3 - costs of useunderstood?
M1 - availability of tools M1 - cost avoidance in $ M1 - startup costsM2 - availability of M2 - time-to-market delta M2 - operational training M3 - quality delta costsM3 - availability of M3 - opportunity methods costsM4 - availability of infrastructure
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Use the G-Q-M Paradigm
October 2005 Copyright RCI, 2005 26
Stepping Through the Process1. Prepare white paper
– State what you are trying to do crisply
2. Demonstrate technical feasibility
- Let’s you prove the idea’s value
- Provide management with early evidence that you can deliver what you promised them
3. 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 27
More on the Process4. 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
5. Prepare business case– Convince sponsor idea
makes both good technical and business sense and provides value
6. Sell the idea– Package for sales/champion
7. 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.)
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 28
Business Process Framework
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Business Planning Process
Tradeoff and Analysis Processes
Software Development Process
Analytical Methods
Models Guidelines for Decision-Making
Process The business planning process proceeds in parallel
Framework and interfaces with the software development process
“Principles, Rules and Tools for Business Case Development”
October 2005 Copyright RCI, 2005 29
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
October 2005 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
FW = P (1 + i)N PV = FW/(1 + i)N
Future WorthFuture Worth Present Value Present Value
October 2005 Copyright RCI, 2005 32
Use Other Available 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Analysis TechniquesAnalysis Techniques
Source: Boehm, SoftwareEngineering Economics
October 2005 Copyright RCI, 2005 33
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?
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 34
Doing a Cost/Benefit Analysis
USC
C S E University of Southern CaliforniaCenter for Software Engineering
• 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 Costs ____
Total ____ Total Benefits ____
Total ____
Cost/Benefit Ratio = PVPV (Total costs ($)$)/Total Benefits ($)$))
October 2005 Copyright RCI, 2005 35
Quantifying Avoidance: Software Dependability Opportunity Tree
DecreaseDefectRiskExposure
Continuous Improvement
DecreaseDefectImpact,Size (Loss)
DecreaseDefectProb (Loss)
Defect Prevention
Defect Detectionand Removal
Value/Risk - BasedDefect Reduction
Graceful Degradation
CI Methods and Metrics
Process, Product, People
Technology
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Source: Boehm
October 2005 Copyright RCI, 2005 36
- Loss due to unacceptable dependability
Time to Ship (Amount of Testing)
RiskExposure
(RE)
Many defects: high P(L)Critical defects: high S(L)
Few defects: low P(L)Minor defects: low S(L)
Quantifying Risk Exposure (RE) via a Profile: Time to Ship
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Source: Boehm
October 2005 Copyright RCI, 2005 37
- Loss due to unacceptable dependability- Loss due to market share erosion
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)
Many defects: high P(L)Critical defects: high S(L)
Few defects: low P(L)Minor defects: low S(L)
Example RE Profile: Time to Ship
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Source: Boehm
October 2005 Copyright RCI, 2005 38
Example RE Profile: Time to Ship
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)
SweetSpot
Many defects: high P(L)Critical defects: high S(L)
Few defects: low P(L)Minor defects: low S(L)
- Sum of Risk Exposures
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Source: Boehm
October 2005 Copyright RCI, 2005 39
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 40
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Software packagesSoftware packages
October 2005 Copyright RCI, 2005 41
Including Estimating Models like COCOMO II - Of Course
SizingModel
EstimatingModel
RiskModel
* Benchmark analysis * Parametric analysis* Comparative analysis * Trade studies* Life cycle cost analysis * “What-if” analysis
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 42
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 43
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Things to DoThings to Do Things Not to Do Things Not to Do
October 2005 Copyright RCI, 2005 44
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 45
Different Ways of Presenting the Data: Balanced Scorecard
Customer
To achieve our vision, how do we appear to our stakeholders?
Internal Process
To satisfy our goals, what processes must we excel at?
Financial
To succeed financially, how should we appear to our stakeholders?
Learning & Growth
To achieve our vision, how do we sustain our ability to change and improve?
Vision and StrategyObjectives
Measures
Targets
Initiatives
Objectives
Measures
Targets
Initiatives
Objectives
Measures
Targets
Initiatives
Objectives
Measures
Targets
Initiatives
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 46
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 47
Final Points Before We Adjourn
• 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 48
Chat Session - 10/19/2005• Scheduled for 8:30 to 9:50 am on 10/19/2005• Provide me your questions prior to end of the
week– My email is [email protected]
• I will sort them and develop answers over the weekend
• I will cover the case study next lecture• Hope this lecture has been stimulating
USC
C S E University of Southern CaliforniaCenter for Software Engineering
THANKS AND HAVE FUN
October 2005 Copyright RCI, 2005 49
The Role of Business Case Analysis in Software Engineering
Lecture #2
Donald J. Reifer
Guest Lecturer
USC Center for Software Engineering
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 50
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 51
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
October 2005 Copyright RCI, 2005 52
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
October 2005 Copyright RCI, 2005 53
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 54
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
October 2005 Copyright RCI, 2005 55
CMM 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 56
Software Improvement Strategy
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Strategy
Discipline theSoftware Process
StandardizeProducts
Professionalworkforce
Quicken use ofnew 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
October 2005 Copyright RCI, 2005 57
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 58
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 59
Process Group Organization
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Manager (New)
ProcessDeveloper (Vacant)
ProcessDeveloper (Vacant)
MetricsAnalyst(New)
ProjectLiaison
(Consultant)
ProjectLiaison
(Consultant)
CurriculumDeveloper
(Part-Timer)
CurriculumDeveloper
(Part-Timer)
October 2005 Copyright RCI, 2005 60
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 approach
COCOMO SEI Maturity Non-discounted Model ROI
October 2005 Copyright RCI, 2005 61
Recommended Process
USC
C S E University of Southern CaliforniaCenter for Software Engineering
1. Involve theStakeholders
2. Develop avision and
strategy
3. Define thework to beperformed
4. Buildpartnerships
5. Promote theresults
* Expectations* Measures of success
Visionstatement
* WBS dictionary* Game plan
Positivepublicrelations
Pilot results
October 2005 Copyright RCI, 2005 62
Work Breakdown Structure
USC
C S E University of Southern CaliforniaCenter for Software Engineering
• Process development
• Education & training
• Process roll-out/project support
• Process assessment
• Promotion & outreach
• Support environment
1.1 Write processes/practices1.2 Review processes/practices1.3 Improve process/practices2.1 Develop/update courseware2.2 Conduct courses3.1 Pilot processes/gather feedback3.2 Provide support to projects3.3 Deploy metrics/statistical controls3.4 Perform statistical analysis4.1 Conduct periodic assessments5.1 Promote results5.2 Publish newsletter, articles, and so on6.1 Establish web site6.2 Establish process asset library
October 2005 Copyright RCI, 2005 63
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
October 2005 Copyright RCI, 2005 64
Proposed Operational Concepts
USC
C S E University of Southern CaliforniaCenter for Software Engineering
• 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
October 2005 Copyright RCI, 2005 65
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 66
Accelerating Productivity from 10 to 20 Percent Annually
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Year 1 Year 2 Year 3 Year 4 Year 5Current productivity(SLOC/staff-month)(10% nominal gain)
100 110 121 133 146
Accelerated gain (20%) 120 144 173 208Additional number of
SLOCs that can begenerated via
acceleration assuming600 engineers
72,000 165,600 288,000 446,400
Cost avoidance($50/SLOC)
$3.6million
$8.3million
$14.4million
$22.3million
Cumulative costavoidance
$3.6million
$11.9million
$26.3million
$48.6million
Conservative estimate of savings is $4 million/year
October 2005 Copyright RCI, 2005 67
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 68
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
October 2005 Copyright RCI, 2005 69
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 70
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
PlusesPluses Minuses Minuses
October 2005 Copyright RCI, 2005 71
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 72
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 73
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
October 2005 Copyright RCI, 2005 74
Three Views of an Architecture
Technical Architecture- Information processing standards- Human-computer interface standards
System Architecture- Components and topology- Networks and connectivity- Capacity/performance
Operational Architecture - Information needs - User functions - Performance bounds
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 75
Radar Architecture Example
Platform
Posix kernel Multi-threading executive
Activity Managers
Measurement Functions
SensorManager
Libraries
Mathematical libraries
InputsInputs
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 76
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
October 2005 Copyright RCI, 2005 77
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
October 2005 Copyright RCI, 2005 78
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
October 2005 Copyright RCI, 2005 79
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Total Costs $800K Total Benefits $10 million
October 2005 Copyright RCI, 2005 80
Strategy Yields Positive Returns Early Error ReductionEarly Error Reduction• Cost avoidance = $1.2M/year• Increased customer satisfaction based on quality
Exploitation of COTSExploitation of COTS• Cost avoidance = $1M/year• Improved maintenance and license leverage with vendors
Productivity ImprovementProductivity Improvement• Cost avoidance = $4M/year• Improved capabilities & capacity
Systematic ReuseSystematic 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 81
Return-On-Investment Is HighTangibles
ROI = Annual Benefits Investment
ROI = $6.2M $2.4M ROI > 250% per year
Assumptions: cost avoidances on page 3realized with exception of reuse whichkicks 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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 82
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 83
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
October 2005 Copyright RCI, 2005 84
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
October 2005 Copyright RCI, 2005 85
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
USC
C S E University of Southern CaliforniaCenter for Software Engineering
GuidelinesGuidelines
October 2005 Copyright RCI, 2005 86
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
October 2005 Copyright RCI, 2005 87
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
October 2005 Copyright RCI, 2005 88
Parting Remarks
USC
C S E University of Southern CaliforniaCenter for Software Engineering
Its time for IBM to perform and then talk, instead of talk and then perform
Louis Gerstner Jr., CEO IBMLouis Gerstner Jr., CEO IBM
The chief business of the Americanpeople is business (not technology).
Calvin CoolidgeCalvin Coolidge PresidentPresident
By working faithfully 8 hours a day, you mayeventually get to be a boss and work 12 hours a day.
Robert Frost, PoetRobert Frost, Poet
All managementis a numbers game John Welch, Jr.,John Welch, Jr., CEO GECEO GE
Have fun, be successful DonDon