PPT - Center for Software Engineering

advertisement

USC

C S E

University of Southern California

Center for Software Engineering

The Role of Business Case

Analysis in Software Engineering

Lecture #1

Supannika Koolmanojwong

Based on Donald J. Reifer’s lecture

Copyright RCI, 2005 1

Copyright RCI, 2005 2

USC

C S E

University of Southern California

Center for Software Engineering

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 3

USC

C S E

University of Southern California

Center for Software Engineering

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 4

USC

C S E

University of Southern California

Center for Software Engineering

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 5

USC

C S E

University of Southern California

Center for Software Engineering

Justifying Improvement

Initiatives to Address Change

Reduce Avoid/Cut

Time to Market Cost

Improve

Customer

Satisfaction Productivity

Increase

Quality

Improve

There needs to be some compelling business reason for making an improvement, else it won’t be approved

Copyright RCI, 2005 6

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

Innovators

Early adopters

Early majority

Late majority

Laggards

Organizations’ Characteristics

Risk takers

Develop new technology

Push the envelope

Trend setters

Advance technology

Will take high risks when justified

Innovators

Take moderate risks

Followers

Exploit technology

Take limited risks

Critics

Use proven technology

Risk averse

Copyright RCI, 2005 9

USC

C S E

University of Southern California

Center for Software Engineering

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

Copyright RCI, 2005 10

USC

C S E

University of Southern California

Center for Software Engineering

Challenges Associated with

Making Organizational Changes

• Lack of incentives • Reward system must be altered

• “Good of the firm” versus “Good of the project”

• Infrastructure shortfalls

• Few meaningful metrics

• Limited cash available

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

USC

C S E

University of Southern California

Center for Software Engineering

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 12

USC

C S E

University of Southern California

Center for Software Engineering

Overcoming Resistance to Change

• Organizations fight changes for many reasons

MIDDLE

MANAGEMENT

BARRIERS

ISLAND

CULTURE

WHY CHANGE-

WE’RE SUCCESSFUL

CUSTOMER

INCENTIVES

HACKER

MENTALITY

IGNORANCE

IS BLISS

NEVER

ENOUGH $$

NEVER

ENOUGH TIME

NOT INVENTED

HERE (NIH)

Copyright RCI, 2005

MIDDLE

MANAGEMENT

BARRIERS

13

USC

C S E

University of Southern California

Center for Software Engineering

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 14

USC

C S E

University of Southern California

Center for Software Engineering

Changing Corporate Cultures

Entrepreneurial Culture

• Seeks opportunity for improvement

• Action-oriented and willing to take risks

• Team-oriented

• Rewards innovation

• Learns from failure

• Creative, imaginative, pliant and flexible

Old-Fashioned Culture

• Prefers the status quo

• Avoids change and risk

• Territorial by nature

• Rewards followers, not innovators

• Penalizes failure

• Persistent, authoritative and rigid

Copyright RCI, 2005 15

USC

C S E

University of Southern California

Center for Software Engineering

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

5. Recognize major barriers to change are primarily political and psychological

6. Change your culture to one that rewards risktaking

7. If you don’t have the talent, buy it

4. Make your new processes the way you do business

8. Use numbers to overcome post-decision dissonance

Copyright RCI, 2005 16

USC

C S E

University of Southern California

Center for Software Engineering

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 17

USC

C S E

University of Southern California

Center for Software Engineering

Business Cases Supply You with the Winning Numbers

• Business Case = the materials prepared for decisionmakers 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 18

USC

C S E

University of Southern California

Center for Software Engineering

Business Versus Technical Cases

Factors (5 is best)

Core language features

Java

2

- Degree of standardization & portability 3

- Object-oriented support 3

- Reuse facilities (library, browser, etc.) 3

- Web programming support

- Optimizing compilers available

- Bindings available

- Rich libraries available

5

4

5

4

- Compiler support tools available

- Inexpensive visual tools available

- Oriented toward your products

Score

4

5

5

43

Copyright RCI, 2005

3

44

5

3

5

4

2

5

C/C++

4

4

5

4

19

USC

C S E

University of Southern California

Center for Software Engineering

Business Versus Technical Cases

Factors (5 is best)

- Popularity - improve resumes

- Training opportunities available

- Literature and books available

- Consultants & subcontractors available

Java C++

5 5

5

5

5

4

5

5 with language skills

- Staff maintains competency in language/tools

- Retooling and retraining costs

- Transition costs associated with learning

2

1

1

4

5

5 curve (bring staff up to speed)

Subtotal

___ ___

24 33

Combined Score 67 77

Copyright RCI, 2005 20

USC

C S E

University of Southern California

Center for Software Engineering

The Business Planning Process

1. Prepare white paper

GQM Results

Idea or proposal

7. Get ready to execute

2. Demonstrate technical feasibility

6. Sell the idea and develop support base

Proof of

Concept

3. Conduct market survey

5. Prepare business case

4. Develop business plan

Copyright RCI, 2005

Approval to go-ahead

21

USC

C S E

University of Southern California

Center for Software Engineering

Aligning with Goals - Your First Step

Goal - successful technology transition

Q1 - ready for use?

Q2 - benefits quantified?

M1 - availability of tools M1 - cost avoidance in $

M2 - availability of M2 - time-to-market delta training

M3 - availability of

M3 - quality delta methods

M4 - availability of infrastructure

Use the G-Q-M

Paradigm

Copyright RCI, 2005

Q3 - costs of use understood?

M1 - startup costs

M2 - operational costs

M3 - opportunity costs

22

USC

C S E

University of Southern California

Center for Software Engineering

Stepping Through the Process

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

Copyright RCI, 2005 23

USC

C S E

University of Southern California

Center for Software Engineering

More on the Process

4. 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 colocate team and for conducting demos

– Prepare your operational concepts (support, etc.)

Copyright RCI, 2005 24

USC

C S E

University of Southern California

Center for Software Engineering

Business Process Framework

Process

Framework

The business planning process proceeds in parallel and interfaces with the software development process

Business Planning Process

Tradeoff and Analysis Processes

Software Development Process

Analytical

Methods

Models Guidelines for

Decision-Making

“Principles, Rules and Tools for Business Case Development”

Copyright RCI, 2005 25

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 26

Let say you are thinking about running a seminar.

How can you make a business case on this?

Copyright RCI, 2005 27

USC

C S E

University of Southern California

Center for Software Engineering thinking about running a seminar.

Nine Business Case Principles

1.

Decisions should be made relative to alternatives

2.

If possible, use money as the common denominator

6.

Decisions should consider qualitative factors

7.

The risks associated with

3.

Sunk costs are irrelevant

4.

(Engineering Econ 101)

Investment decisions should recognize the time value of money

5.

Separable decisions must be considered separately quantified if possible

Already ran a java seminar last year ?

8.

The timing associated with making decisions is critical

Any better option ?

9.

Decision processes should different criteria, don’t mix them up. be periodically assessed and continuously improved

Copyright RCI, 2005 28

USC

C S E

University of Southern California

Center for Software Engineering thinking about running a seminar.

Nine Business Case Principles

6.

Decisions should consider both quantitative and qualitative factors

7.

The risks associated with the decision should be quantified if possible

8.

The timing associated with making decisions is critical

9.

Decision processes should be periodically assessed and continuously improved

Copyright RCI, 2005

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.

29

USC

C S E

University of Southern California

Center for Software Engineering

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 30

USC

C S E

University of Southern California

Center for Software Engineering

Use Engineering Economics as its Analytical Basis

FW = P (1 + i) N PV = FW/(1 + i) N

Future Worth

• Takes cost of money into account

– A

$$ today is worth more than tomorrow due to inflation

• Takes compounding into account

Present Value

• Normalizes future expenditures using current year dollars as a basis for comparison

• Lets you establish a minimum attractive rate of return

Copyright RCI, 2005 31

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

2

3

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

1 $25K $35K $10K 0.9259

4

$25K

$25K

$25K

$35K

$35K

$35K

$10K

$10K

$10K

$40K

0.8573

0.7938

0.7350

Present Value

$9259

$8753

$7938

$7350

$33120

Copyright RCI, 2005 32

Then calculate ROI

2

3

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

1 $25K $35K $10K 0.9259

$9259

4

$25K

$25K

$25K

$35K

$35K

$35K

$10K

$10K

$10K

$40K

0.8573

0.7938

0.7350

$8753

$7938

$7350

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

USC

C S E

University of Southern California

Center for Software Engineering

Use Other Available Techniques

Source: Boehm, Software

Engineering Economics

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

Copyright RCI, 2005 34

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 http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx

35

Breakeven Analysis

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

36

Payback Analysis

2

3

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

1 $25K $35K $10K 0.9259

$9259

4

$25K

$25K

$25K

$35K

$35K

$35K

$10K

$10K

$10K

$40K

0.8573

0.7938

0.7350

$8753

$7938

$7350

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

USC

C S E

University of Southern California

Center for Software Engineering

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 38

USC

C S E

University of Southern California

Center for Software Engineering

Doing a Cost/Benefit Analysis

Cost/Benefit Ratio = PV (Total costs ($)/Total Benefits ($))

• Non-recurring costs

– Course acquisition ____

– Course conduct

____

Total ____

• Recurring costs

– Course maintenance ____

– Continuing education ____

Total ____

Total Costs ____

Copyright RCI, 2005

• Tangible savings

– Cost avoidance ____

– Cost savings ____

Total ____

• Intangible savings

– Reduced turnover ____

– Less risk exposure____

Total ____

Total Benefits ____

39

USC

C S E

University of Southern California

Center for Software Engineering

Quantifying Avoidance: Software

Dependability Opportunity Tree

Defect Prevention

Decrease

Defect

Prob (Loss)

Defect Detection and Removal

Decrease

Defect

Risk

Exposure

Decrease

Defect

Impact,

Size (Loss)

Value/Risk - Based

Defect Reduction

Graceful Degradation

Source: Boehm

Continuous

Improvement

Copyright RCI, 2005

CI Methods and Metrics

Process, Product, People

Technology

40

USC

C S E

University of Southern California

Center for Software Engineering

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 41

USC

C S E

University of Southern California

Center for Software Engineering

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)

Copyright RCI, 2005

Source: Boehm

42

USC

C S E

University of Southern California

Center for Software Engineering

Example RE Profile: Time to Ship

Sum of Risk Exposures

Many defects: high P(L)

Critical defects: high S(L)

Many rivals: high P(L)

Strong rivals: high S(L)

RE Sweet

Spot

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)

Copyright RCI, 2005

Source: Boehm

43

USC

C S E

University of Southern California

Center for Software Engineering

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 44

USC

C S E

University of Southern California

Center for Software Engineering

Many Supportive Tools

Software packages

• 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

Copyright RCI, 2005 45

USC

C S E

University of Southern California

Center for Software Engineering

Including Estimating Models like

COCOMO II - Of Course

Sizing

Model

Estimating

Model

Risk

Model

* Benchmark analysis * Parametric analysis

* Comparative analysis * Trade studies

* Life cycle cost analysis * “What-if” analysis

Copyright RCI, 2005 46

USC

C S E

University of Southern California

Center for Software Engineering

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 47

USC

C S E

University of Southern California

Center for Software Engineering

Emphasize Cost Avoidance

Things 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

Things Not to Do

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

USC

C S E

University of Southern California

Center for Software Engineering

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 49

USC

C S E

University of Southern California

Center for Software Engineering

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 50

USC

C S E

University of Southern California

Center for Software Engineering

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 51

USC

C S E

University of Southern California

Center for Software Engineering

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 52

USC

C S E

University of Southern California

Center for Software Engineering

Your home

Organizational Structure

Senior Management

Aerospace firm

QA Group

Process Group

Senior Staff

Engineering Manufacturing Field Support Program Mgmt

* Systems

* Software

* Fabrication

* Assembly

* Digital design * Production

Project A

* Field service

* Training

* Test & evaluation

Copyright RCI, 2005

Line of Business

Management

* Fund functional groups

* Coordinate

* Facilitate

53

USC

C S E

University of Southern California

Center for Software Engineering

History of Process Improvement

Maturity Level

5

4

Level 3 a customer requirement

3

Process budget axed

Acquisition falls through

Aim- Reach

Level 4 in 2 years

Firm positioned to be acquired

Seniors get serious about process

2

1

Reach Level 3 corporate goal

Process group reformed

1985 1987 1989 1991 1993 1995 1997 1999 Now

Copyright RCI, 2005 54

USC

C S E

University of Southern California

Center for Software Engineering

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 55

2

4

5

Defect prevention

- Technology change management

- Process change management

Quantitative process management

- Software quality management

3

Organization process focus

- Organization process definition

- Training program

- Integrated software management

- Software product engineering

- Inter-group coordination

- Peer reviews

Requirements management

- Software project planning

- Software project tracking and oversight

- Software subcontract management

- Software qualify assurance

- Software configuration management

The

Software

CMMI

Contains:

- 5 Maturity Levels

- 18 Key Process Areas

- 318 Key Practices

Copyright RCI, 2005 56

USC

C S E

University of Southern California

Center for Software Engineering

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 57

USC

C S E

University of Southern California

Center for Software Engineering

Software Improvement Strategy

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 58

USC

C S E

University of Southern California

Center for Software Engineering

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 59

USC

C S E

University of Southern California

Center for Software Engineering

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 60

USC

C S E

University of Southern California

Center for Software Engineering

Process Group Organization

Manager

(New)

Process

Developer

(Vacant)

Process

Developer

(Vacant)

Metrics

Analyst

(New)

Project

Liaison

(Consultant)

Project

Liaison

(Consultant)

Curriculum

Developer

(Part-Timer)

Curriculum

Developer

(Part-Timer)

Copyright RCI, 2005 61

USC

C S E

University of Southern California

Center for Software Engineering

Start - Why Focus on Process?

Why (Goal): Increase Productivity and Meet Customer Requirements

Questions: Measured What how? option?

Why this option?

Metrics:

Models:

SLOC/hour Do Process Other ROI

Nil improvement approach

COCOMO SEI Maturity Non-discounted

Model ROI

Copyright RCI, 2005 62

USC

C S E

University of Southern California

Center for Software Engineering

Recommended Process

1. Involve the

Stakeholders

* Expectations

* Measures of success

Pilot results

2. Develop a vision and strategy

Positive public relations

5. Promote the results

4. Build partnerships

Vision statement

3. Define the work to be performed

Copyright RCI, 2005

* WBS dictionary

* Game plan

63

USC

C S E

University of Southern California

Center for Software Engineering

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 64

USC

C S E

University of Southern California

Center for Software Engineering

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 newsletter, work with clients and attend conferences

• Support environment

– $350K for web site development

Copyright RCI, 2005 65

USC

C S E

University of Southern California

Center for Software Engineering

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 66

USC

C S E

University of Southern California

Center for Software Engineering

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 67

USC

C S E

University of Southern California

Center for Software Engineering

Accelerating Productivity from

10 to 20 Percent Annually

Year 1

100

Year 2

110

Year 3

121

Year 4

133 Current productivity

(SLOC/staff-month)

(10% nominal gain)

Accelerated gain (20%)

Additional number of

SLOCs that can be generated via acceleration assuming

600 engineers

Cost avoidance

($50/SLOC)

Cumulative cost avoidance

120

72,000

$3.6

million

$3.6

million

144

165,600

$8.3

million

$11.9

million

173

288,000

$14.4

million

$26.3

million

Year 5

146

208

446,400

$22.3

million

$48.6

million

Conservative estimate of savings is $4 million/year

Copyright RCI, 2005 68

USC

C S E

University of Southern California

Center for Software Engineering

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 69

USC

C S E

University of Southern California

Center for Software Engineering

Early Error Detection/Correction

• Benefit of achieving Level 4 is a reduction in errors by a factor of between 20 and 25%

– Majority caught early in requirements and design phases

• Cost avoidance associated with early defect removal is

$20/defect

• For the 12 major programs in your firm, you compute cost avoidance is 1.2 million calculated as follows:

(12 jobs/year)(10 defects 1 /KSLOC)(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 70

USC

C S E

University of Southern California

Center for Software Engineering

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 71

USC

C S E

University of Southern California

Center for Software Engineering

COTS Pluses and Minuses

Pluses

• 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

Minuses

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

USC

C S E

University of Southern California

Center for Software Engineering

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 73

USC

C S E

University of Southern California

Center for Software Engineering

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 74

USC

C S E

University of Southern California

Center for Software Engineering

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 75

USC

C S E

University of Southern California

Center for Software Engineering

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 76

USC

C S E

University of Southern California

Center for Software Engineering

Radar Architecture Example

Mathematical libraries

Activity

Managers

Measurement

Functions

Sensor

Manager

Libraries

Posix kernel Multi-threading executive

Inputs

Platform

Copyright RCI, 2005 77

USC

C S E

University of Southern California

Center for Software Engineering

Reuse-Based Development Paradigm

Purchased products

Domain Model

Domain

Analysis

Products for sale

Domain

Design

Asset

Development

Scope

Assets

Domain Engineering

Requirements Architecture

Software Reuse Library

Assets

Requirements Software Integration Operations &

Analysis Development & Test Maintenance

Applications Engineering

Copyright RCI, 2005

Project-specific deliverables

78

USC

C S E

University of Southern California

Center for Software Engineering

COCOMO II Reuse Model

ESLOC = ASLOC [AA + AAF(1 + 0.02(SU)(UNFM))] AAF < 0.5

100

ESLOC = ASLOC [AA + AAF + (SU)(UNFM)]

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

Copyright RCI, 2005

AAF > 0.5

79

USC

C S E

University of Southern California

Center for Software Engineering

The Impact of Reuse

Application

Real-time executive

Scheduler

Real-time data acquisition

Sensor data processing

Data analysis and alarms

TOTAL

Without Reuse

10,000

25,000

50,000

50,000

25,000

160,000

With Reuse

500

500

10,000

21,000

10,000

42,000

Nominal Development Time (months)

Nominal Effort (staff-months)

Shortest Development Time (months)

Shortest Development Time Effort

Without Reuse

30

845.3

22.5

1208.7

With Reuse

23.4

383.7

17.6

548.7

Conservative estimate of savings is $10 million/year

Copyright RCI, 2005 80

USC

C S E

University of Southern California

Center for Software Engineering

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

Total Costs $800K Total Benefits $10 million

Copyright RCI, 2005 81

USC

C S E

University of Southern California

Center for Software Engineering

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 82

USC

C S E

University of Southern California

Center for Software Engineering

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 83

USC

C S E

University of Southern California

Center for Software Engineering

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 84

USC

C S E

University of Southern California

Center for Software Engineering

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 85

USC

C S E

University of Southern California

Center for Software Engineering

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 86

USC

C S E

University of Southern California

Center for Software Engineering

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 87

USC

C S E

University of Southern California

Center for Software Engineering

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 88

USC

C S E

University of Southern California

Center for Software Engineering

Lots of Available Web Resources

Topic

Engineering economics and business cases

Computer economics and business cases

Software economics and business cases

Addison-Wesley site for this book

Web Resources www.isye.gatech.edu

(Georgia Institute of Technology)

The WWW virtual library of industrial engineering with information on academic programs, conferences, courses, publications which emphasize their engineering economics core expertise area 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 forecasts www.hbsp.harvard.edu

(Harvard Business School)

Access to case studies on E-Commerce and the Internet, change management, entrepreneurship and new technology 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) efforts www.software.org

(Software Productivity Consortium)

Practical measurement techniques including controlled access to their guidebooks, case studies and lessons learned reports www.aw.com/softwarebusinesscases

Updates to this book, student exercises and pointers to additional useful information

Copyright RCI, 2005 89

Download