copyright rci, 20051 the role of business case analysis in software engineering lecture #1 based on...

89
Copyright RCI, 2005 1 The Role of Business Case Analysis in Software Engineering Lecture #1 Based on Donald J. Reifer’s lecture Supannika Koolmanojwong USC C S E U niversity ofSouthern C alifornia C enterforSoftw are Engineering

Upload: gerald-dunton

Post on 16-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

Copyright RCI, 2005 1

The Role of Business Case Analysis in Software Engineering

Lecture #1

Based on Donald J. Reifer’s lecture

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Supannika Koolmanojwong

Copyright RCI, 2005 2

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 cheaper

Other silver bullets

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

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

Copyright RCI, 2005 6

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

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?

7

8

Technology Adoption Life Cycle Model

Stage in Life Cycle Organizations’ Characteristics

Innovators Risk takersDevelop new technologyPush the envelope

Early adopters Trend settersAdvance technologyWill take high risks when justified

Early majority InnovatorsTake moderate risks

Late majority FollowersExploit technologyTake limited risks

Laggards CriticsUse proven technologyRisk averse

Copyright RCI, 2005 9

Copyright RCI, 2005 10

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 13

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 15

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

Copyright RCI, 2005 16

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

Copyright RCI, 2005 17

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 questions

Answer Basic Business-Related 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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 19

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

Copyright RCI, 2005 20

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

Copyright RCI, 2005 21

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

Copyright RCI, 2005 22

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

Copyright RCI, 2005 23

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

Copyright RCI, 2005 24

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

Copyright RCI, 2005 25

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”

Assume you are moving towards java, but no one knows java

You need to improve their skillsWhat are the choices do we have here?

Copyright RCI, 2005 26

Let say you are thinking about running a seminar.

How can you make a business case on this?

Copyright RCI, 2005 27

Copyright RCI, 2005 28

Nine Business Case Principles1. Decisions should be made

relative to alternatives

2. If possible, use money as the common denominator

3. Sunk costs are irrelevant (Engineering Econ 101)

4. Investment decisions should recognize the time value of money

5. Separable decisions must be considered separately

6. Decisions should consider both quantitative and qualitative factors

7. The risks associated with the decision should be quantified if possible

8. The timing associated with making decisions is critical

9. Decision processes should be periodically assessed and continuously improved

USC

C S E University of Southern CaliforniaCenter for Software Engineering

1. Do nothing, learn by themselves2. On-the-job training3. Bring in seminar / hands-on

training How can a training seminar save costs / save time / improve quality ? Calculate that in $$

thinking about running a seminar.

What happened in the past, stay in the past. Already ran a java seminar last year ? it does not matter. New staff$10 today = $8 next yearSave in the bank, %6 interestAny better option ?If you need select a training firm, use different criteria, don’t mix them up.

Copyright RCI, 2005 29

Nine Business Case Principles6. Decisions should consider

both quantitative and qualitative factors

7. The risks associated with the decision should be quantified if possible

8. The timing associated with making decisions is critical

9. Decision processes should be periodically assessed and continuously improved

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Training seminar might improve image and morale.

What if no trainer available , any back up plan ? What is the extra cost?

thinking about running a seminar.

Time your decision carefully. Any budget cycle ?Propose when there is money available.

Keep your eyes open, look for possible improvement.

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

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 Worth Present Value

Present Value Calculation for Training Example

Year Training Cost Benefits Net Benefits 1/(1+i)N Present Value

1 $25K $35K $10K 0.9259 $9259

2 $25K $35K $10K 0.8573 $8753

3 $25K $35K $10K 0.7938 $7938

4 $25K $35K $10K 0.7350 $7350

$40K $33120

Copyright RCI, 2005 32

• 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

Then calculate ROI

• ROI = net benefit / investment• = $40,000 / $100,000 = 40% or 10% annually

Copyright RCI, 2005 33

Year Training Cost Benefits Net Benefits 1/(1+i)N Present Value

1 $25K $35K $10K 0.9259 $9259

2 $25K $35K $10K 0.8573 $8753

3 $25K $35K $10K 0.7938 $7938

4 $25K $35K $10K 0.7350 $7350

$40K $33120

Good choice ? 10% annually for manager – may not be a good ideaPut in the bank, no risks – get 8% What can we do ?

Copyright RCI, 2005 34

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 Techniques

Source: Boehm, SoftwareEngineering Economics

Balanced Score Card

35http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx

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

Breakeven Analysis

36http://www.biztoolspro.com/functions/BreakevenAnalysis.htm

Payback Analysis

To determine the number of periods required to recover one’s investmentPayment 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 37

Year Training Cost Benefits Net Benefits 1/(1+i)N Present Value

1 $25K $35K $10K 0.9259 $9259

2 $25K $35K $10K 0.8573 $8753

3 $25K $35K $10K 0.7938 $7938

4 $25K $35K $10K 0.7350 $7350

$40K $33120

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?

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 39

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 = PV (Total costs ($)/Total Benefits ($))

Copyright RCI, 2005 40

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

Copyright RCI, 2005 41

- 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

Copyright RCI, 2005 42

- 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

Copyright RCI, 2005 43

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 45

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 packages

Copyright RCI, 2005 46

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 48

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 Do Things Not to Do

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 53

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

Copyright RCI, 2005 54

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 56

The Software

CMMI

- 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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 58

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 61

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)

Copyright RCI, 2005 62

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

Copyright RCI, 2005 63

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

Copyright RCI, 2005 64

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

Copyright RCI, 2005 65

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

Copyright RCI, 2005 66

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 68

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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:

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 72

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

Pluses Minuses

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 76

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

Copyright RCI, 2005 77

Radar Architecture Example

Platform

Posix kernel Multi-threading executive

Activity Managers

Measurement Functions

SensorManager

Libraries

Mathematical libraries

Inputs

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 78

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

Copyright RCI, 2005 79

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

Copyright RCI, 2005 80

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

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

Copyright RCI, 2005 82

Strategy Yields Positive Returns Early Error Reduction• Cost avoidance = $1.2M/year• Increased customer satisfaction based on quality

Exploitation of COTS• Cost avoidance = $1M/year• Improved maintenance and license leverage with vendors

Productivity Improvement• Cost avoidance = $4M/year• Improved capabilities & capacity

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 83

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

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 87

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

Guidelines

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

USC

C S E University of Southern CaliforniaCenter for Software Engineering

Copyright RCI, 2005 89

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