Winning with Software: An Executive Strategy

Description

"Every senior executive needs to read this book."

Watts Humphrey is the well-known author of methods and models widely used by organizations, teams, and individuals to improve the efficiency and effectiveness of software development. In Winning with Software, he shows corporate executives and senior managers why software is both a business problem and a business opportunity.

"This book is extremely well written and targets the right audience. I plan to buy a copy for each of my executives."

Humphrey, drawing on his own extensive executive and management experience, first demonstrates the critical importance of software to nearly every business, large and small. He then outlines seven steps needed to gain control of a software operation and transform it into a professional, businesslike engineering function. Failure to recognize the importance of software, and to take charge of its development process, runs the risk of damaging the entire business. By contrast, Humphrey relates the substantial benefits real organizations have obtained from such awareness and control, and he concludes with an analysis of the impressive financial returns the recommended transformations typically yield.

"This is a great book that will play a valuable role. It has excellent anecdotes that illustrate the points being made, as well as good examples depicting the problems faced by teams and managers. I look forward to sharing it with my colleagues."

Sample Content

Online Sample Chapter

Why Every Business Is a Software Business

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
humphreych1.pdf

Table of Contents

Preface.


 1. Every Business Is a Software Business.


 2. Why Projects Fail.


 3. Rational Management.


 4. Why Quality Pays.


 5. Leadership Goals.


 6. Changing Engineering Behavior.


 7. Building Motivated Teams.


 8. The Benefits of Teamwork.


 9. Next Steps.


Appendix A. The TSP Process.


Appendix B. Launching a TSP Project.


Appendix C. Reviewing a Project Plan.


Appendix D. The Quarterly Project Review.


Appendix E. The Standard-Stage Review.


Appendix F. Return on Investment


Index.


For Additional Information. 0201776391T09142001

Preface

When I mention software to senior executives, I get lots of reactions. Most are frustrated. They complain about missed commitments, quality problems, and unpleasant surprises. Others have been less closely involved. Software was a problem, but those problems have been handled. No one mentions the business opportunities of software. They think of software as a necessary evilsomething to be avoided if possible. While most executives would agree that the software part of their business is growing very quickly, they never think of it as an asset or an opportunity.

By using the methods described in this book, organizations have transformed their software groups. The first Boeing team cut test time by 94%; an air force group doubled productivity; a Teradyne project delivered a large defect-free product. These and other organizations are getting outstanding results. However, they all started with a management focus on the opportunities with software.

THREAT OR OPPORTUNITY

Software is a truly incredible technology. It has a zero production cost, can be distributed worldwide in seconds, does not wear out or deteriorate, and is the most economical and flexible way to implement almost any complex function. In just about any field of engineering or science, more than half a typical professionals time is now spent in using, developing, enhancing, or maintaining software. By any measure, software is big business.

To visualize the opportunities with software, consider the inverse: potential threats. Take manufacturing, for example. Suppose your leading competitor mastered a technology that cut manufacturing costs in half, eliminated distribution delays, and provided products that never wore out or deteriorated. If you did not quickly capitalize on that technology, you would almost certainly be in trouble. Conversely, think of the opportunities if your organization mastered this technology and your competitors did not. While software is precisely such a technology, few organizations see it as either an opportunity or a threat. The principal reason is that many executives dont think their organizations do much software work and, of those that do, few have enough software knowledge or experience to appreciate how it contributes to their business. Once they think the software problems are under control, they do their best to avoid the subject.

A growing number of executives have found that software is a powerful business asset. However, these same executives have also found that moving into the modern world of engineered software requires an organizational transformation. What is more, they have discovered that they must personally lead this transformation. It is not a simple change and, like all changes, this transformation involves more than just telling people what to do. The best way to explain what is involved is to tell the story of how the methods described in this book were created.

THE TRANSFORMATION JOURNEY

During my 27 years with IBM, one of my jobs was director of programming. I supervised 4,000 software professionals in 15 laboratories and 7 countries. In four years, we took this organization from the brink of chaos to a sound, businesslike operation. The first step was to establish effective engineering and management practices and to require that these practices be followed. To ensure that these practices were understood, we sent 1,000 managers to a one-week training course. The results were extraordinary. This organization had never before delivered a product on time. Once the managers were all trained and following a disciplined planning and commitment process, the organization did not miss a single commitment for the next two and a half years.

When I retired from IBM, in 1986, I looked at the software industry in general. It was obvious that software was a crucial technology, but it was also clear that the poor state of software engineering practice seriously constrained both the U.S. economy and society in general. I made what I called an "outrageous commitment." My commitment was to transform the world of software. The objective was to bring to the world in general the practices and principles that I had found so successful at IBM.

On my retirement from IBM, I joined the Software Engineering Institute (SEI) at Carnegie Mellon University and was made director of the software process program. The SEI had just been established by the U.S. Department of Defense to improve the state of software practice. This mission was completely consistent with my "outrageous commitment," which was to get all software professionals and their managers to plan and track their work, use the best technical methods, and measure and manage the quality of this work. I was convinced that if they did, the results would be extraordinary.

Together with a small team of like-minded SEI professionals, we soon developed the Capability Maturity Model (CMM) to guide organizations in adopting sound management practices. The CMM has been highly effective and is used by thousands of organizations throughout the world. The CMM is now an international standard, and it is used by many branches of the U.S. government to evaluate internal software work and to assess and oversee the work of their contractors.

Although the CMM effort was and continues to be highly successful, I soon saw problems. The CMM provides excellent management guidance, but its principal impact is on the managers and their technical staffs. The CMM does not directly affect the work of the engineers, and the engineers and their teams were still struggling. There is no question that better management helps, but I soon realized that until we changed the practices of the software professionals themselves, we could never achieve a truly expert software engineering capability. Therefore, the next challenge was to motivate engineering groups to do just that. I wanted them to know the best methods, but I also wanted them to actually practice these methods every day. The techniques I developed to do this are called the Personal Software Process (PSP) and the Team Software Process (TSP)SM. The development of these methods is described in Chapters 6 and 7.

The story of how your organization can capitalize on these methods is told in the rest of this book. These methods are producing extraordinary results for other organizations, and you can view this as either a threat or an opportunity. As an engineering manager at Teradyne told me, "With the TSP, were so far ahead of the competition that nobody will ever catch us."

It has been my experience that projects that use the TSP can double their productivity and improve product quality by an order of magnitude. The investment required is predominantly training and mentoring costs and these costs typically are recovered within 12 to 18 months. Once teams have been trained and acquire some experience, there is no significant overhead to the TSP process. However, executive leadership is required to get your people trained properly and to support them long enough to gain the experience to practice these methods consistently.

WHY YOU SHOULD READ THIS BOOK

This book is written for senior executives who want to improve the business performance of their software groups. When I use the word you, I am talking to CEOs, vice presidents, and division general managers. The message of the book is designed for executives who have profit responsibility and who directly control a substantial portion of their organizations resources. As a result, much of the material has a business slant and contains a minimum of technical jargon. However, I do delve a little more deeply into the technical material than many executives might expect.

I do this for three reasons. First, executives often are suspicious of impressive presentations and like to dig a little deeper to see if there is substance behind

Index

A
Accelerating
    schedules 54
    work 54
Acceptance test defects 198
Accuracy
    estimates 71
    schedules 93
Achievable goals 116
Action
    motivating 37
    plans 110
Activity, intellectual 66
Additional information 231
Aggressive
    challenge 85
    goals 35, 115
    schedule 87
Air Force Standard Systems Center 109
Aircraft software 4
Allied Signal 58, 61
Alternate plans 140, 141
Amdahl Corporation 49
Anticipating problems 39
Ashton Tate 8, 9, 10, 29
    example 8
Assessment 143
    checklist 143, 144
    plan 153
    quality plan 152, 153
    team plan 147
        cannot meet goal 146
        elements 148
        meets goal 146
        needs resources 146
Assignments
    full time 18
    multiple 18, 25
    part time 18
    simultaneous 18, 25
Assumptions
    ROI calculations 197
    TSP savings 199
Attitude, engineer 67
Austin, Robert D. 90
Australia 79
B
Balancing workload 56
Bangalore, India 30
Bartko, Peter 77, 86, 87
Basketball example 106
Behavior, changing 65
Believing in magic 23
Bell Telephone Laboratories 20
Benchmark 162
    comparison questions 195
    improvement 195
    teams 162
Bendix Brakes 42
Benefits
    disciplined methods 74
    predictability 91
    PSP course 7074
    teamwork 91
    TSP 92, 94, 197
Boeing 92, 200
Bonus plans 66
Brakes, defective 42
Breakeven time 101
BrokerNet 77, 87, 96
Building
    a house 54
    effective teamwork 18
    teams 18, 77, 79, 84
Bureaucracies 107
Business
    assessment 143
    hardware 5
    software 1, 3
Busy CEO 129
C
Capability Maturity Model (CMM) 65, 68, 91, 108, 199
    definition 65 (footnote)
    improvement 108
    level 5 91
    versus test time 200
Carnegie Mellon University 13, 70
Cats, herding 66
Causes of project failure 17, 27
Champion
    improvement 106, 111
    job responsibilities 106
Change
    resisting 107
    technology 1
Changes, requirements 19, 26
Changing
    behavior 65
    objectives 19, 26
    requirements 19, 26
Charts, defect 185
Checklist
    plan assessment 143, 144
    quarterly review 163, 164, 181, 182
CI105 48, 49
Citibank 4
CMM, see Capability Maturity Model
Coach, TSP 109, 202
    qualification 203
    training 203
Coaching support 75
Code Red worm 42
Code review 45
    defect removal time 45
    defects 188, 190, 192
    run chart 189
    time 192
Cohesive teams 124
Commitment 84, 117
    maintaining 88
    management 26
    quality 11
    team 84
Committed teams 85, 115
    building 84
    prerequisites for 85
Common
    stage reviews 161
    team plan 116
    team process 116
Communication, team leader 116
Comparison
    benchmark 195
    plan 151
Compile
    and test defects 73
    defects, guideline 192
    run chart 186
Compiling 72
Completion projections 170
Conceptual design 81, 147
Consequences of
    impossible dates 87
    software problems 5
Considerations, review 158, 180
Cooperation, team 115
Cost reduction steps 58
Costs 100
    cutting 58
    defect removal 100
    development 94
    minimum, TSP introduction 203
    poor quality 100
    quality 100
    reducing 58, 94
    savings, TSP 206
    savings, Teradyne 9
    testing 100
    TSP introduction 98, 205
COTS example 23, 26
Course, PSP 70, 120
Crash project 15
Creative professionals 67
Crises management 32
Culture, quality 12
Cutting
    costs 58
    cycle time 30
Cycle time
    cutting 30
    definition 30
    example 30
    improvement 92
D
Data 34
    defect 8, 190
    earned value, interpreting 171
    historical 148
    module 190
    personal 72
    productivity 148
    project 148
    PSP course 7074
    SEI 45
    sensitivity 180
    task time, interpreting 171
    Teradyne 94
    Xerox 43, 45, 193
Dates
    artificial 127
    impossible 87
Dbase IV 8
Dedication to quality 15, 26
Defect
    charts 185
    code review 189, 192
    compile 192
    compile and test 73
    cost to find and fix 201, 207
    costs 100
    data 8, 94, 185, 190
    data sensitivity 180
    data, Teradyne 94
    delivered 200
    density 193, 198
    design review 192
    fix time 43, 44, 188
    guidelines 192
    Magellan system test 179
    nature of 194
    per KLOC 200
    random nature 194
    ratio
        guidelines 192
        questions 191
    recording questions 181, 183
    reduced 95
    removal
        by phase 185
        compile and test 73
        methods 44
        profile 185
        strategies 45, 46
        time 43, 44
    removed, PSP course 73
    repair time 201, 207
    savings, TSP 206
    shipped 207
    system test 95, 198
    test 95, 198
    time to find and fix 43, 44, 188
    unit test guideline 192
Defective
    brakes 42
    modules 9, 35
Defined process 70
Defining responsibilities 54, 62
Definitions
    CMM 65 (footnote)
    cycle time 30
    earned value 36 (footnote)
    KLOC 43 (footnote)
    LOC 43 (footnote)
    quartile range 92
    run chart 186
    task time 58
    yield 178
Delivered defects 200
Deming, W. E. 12, 14
Density, defects 193, 198
Department of Defense, see U.S. Department of Defense
Design 70
    conceptual 81, 147
    practices 70
    review
        defects 192
        time 192
    standards 70
    time 192
Detailed
    design time 192
    plan 55, 81
Developing
    the PSP 68
    the TSP 77, 78
Development
    costs, reduced 94
    strategy 81
Director of programming, IBM 32
Disasters, software 42
Discipline 158
    benefits 74
    monitoring 38
    personal 74
Disciplined
    and motivated teams 75
    environment 63
    people 3, 10
    performance 75
    practices 11, 67
    teams 75
    work 15, 26
Discounted ROI 100, 208, 209
DoD, see U.S. Department of Defense
Duration, testing 193, 198
E
Earned value 36
    completion projections 170
    data, interpreting 171
    definition 36 (footnote)
    example 168
    questions 170
EBS 77, 86, 95
    results 86
Economics, TSP 206, 208, 209
Effort estimating error 72, 96, 198
Elements of
    plan assessment 148
    team motivation 159
Employee
    attitudes 67
    turnover 97
Engineer
    and quality 12
    attitudes 67
    behavior, changing 65
    evaluation 107
    goals 107
    motivation 15, 60
    performance review 107
    responsibilities 63
    salary 107
    semiconductor 12
    training 67, 118, 119, 203
Environment
    disciplined 63
    trusting 87
Error
    estimating 72, 96, 198
    schedule 93, 198
Essence of rational management 37
Estimates
    productivity 149
    size 149
Estimating 71
    accuracy 71
    error 72, 96
Evaluation
    quality plan 152
    risk assessment 154
    team plan 143, 147
Examples
    Allied Signal 58
    alternate plans 141
    Ashton Tate 8
    basketball 106
    Boeing 92
    BrokerNet 77
    building house 54
    busy CEO 129
    changing requirements 19
    CI105 48
    CMM 65
    compile run chart 186
    COTS 23
    cycle time 30
    defect removal profile 185
    director of programming 32
    disciplined people 10
    earned value 168
    EBS 77
    facts and data 33
    faster, better, cheaper 51
    flight test deadline 36
    growth of software 4
    Hill Air Force Base 91
    house construction 54, 56
    IBM
        CI105 47
        director of programming 32
        hardware business 5
        OS/2 7
        OS/360 32
        PC 6
        TSS/67 20, 25
    inadequate team preparation 120
    inappropriate staffing 18
    launch meetings 128
    missing executive 128
    module data 190
    motivated people 10
    motivation, house building 57
    needed resources 146
    opening launch meetings 128
    organization, ROI example 198
    part-time assignments 18
    plan
        assessment 143, 147
        comparison example 151
        presentation 140
    planning 33
    poor quality 22
    project plan 141
    quality 42
        CI105 48
        house building 56
        plan 153
    return on investment 99, 101
    ROI organization 198
    run chart 186, 189
    software growth 4
    software quality 42
    task hours 59, 168
    Teradyne team 80, 83, 94
    training 121
    TSP costs and savings 100, 101, 205, 208, 209
    TSS/67 20
    underemphasized need 129
    unrealistic schedules 15
    using facts and data 36
    virtual memory 19
    WEEK form 169
    weekly task hours 168
Executive
    oversight 110
    reviews 157
    role in
        launch 123, 125
        project failure 24
        teambuilding 133
    seminars, TSP 111, 120, 203
F
F-4, F-16, F-22 4
Facing facts 29
Facts
    and data 34, 36
    facing 29
    getting 33
    using 36
Failure
    executive role in 24
    project, causes of 15, 17
Faster, better, cheaper 51
Fear 84
Ferguson, Jack 14
Ferguson, Pat 76
Final launch meeting 130
Firestone tires 42
First review 163
Fix time, defects 43, 44, 188
Fixes, defect 43, 44, 188
Fixing software organizations 53
Flight test deadline 36
Ford Explorer 42
Form WEEK 169
Fortune 500 5
Four-hour house video 64
Full time assignments 18
Future products 1
G
Gates, Bill 6
GE Multix System 20, 25
General Motors 20, 25
Getting the facts 33
Goals 51
    achievable 116
    aggressive 35, 115
    engineer 107
    establishing 53
    improvement 180
    leadership 51, 107
    manager 111
    measurable 106
    quality 57
    realistic 35
    setting 37, 53, 62
    team 107
    tracking 62
Greed 84
Growth of software 4
Guidelines, ratios 192
H
Hardware business 5
Hayes, Will 76
Herding cats 66
High risk modules 189
Hill Air Force Base 91, 200
Historical data 148
Hours, task 148
    see also Task, time
House building 54
House-building video 64
How to motivate teams 84
Humphrey, Watts S. 50, 76, 122, 131
I
IBM 5, 7, 19, 25, 32, 47, 67
    CI105 example 48
    director of programming 32
    OS/2 7
    OS/360 example 32
    PC example 5
    TSS/67 20, 25
Impossible
    dates 87
    job 65
    schedules 87
    situations 30
Improvement
    benchmarked 195
    champion 106, 111
    goals 180
    resources 108
    responsibilities 65
    results, TSP 197
    TSP summary 197
Improving
    cycle time 92
    product quality 95, 97
    productivity 58
    task time 60
Inadequate preparation 120
Inappropriate staffing 18, 26
India 30
Ineffectiveness of testing 46
Information, additional 231
Initial stage reviews 161, 166
Inspections 44
Instructor, PSP 109
    training 119, 120
Intel 42
Intellectual work 66
Internet example 42
Interpreting
    earned value data 171
    task time data 171
Interruption time 61
Introduction
    costs, TSP 98, 205
    plan 111
    savings 206
    strategy 201, 204
    TSP 201
Investment
    breakeven 101
    return on, see Return on investment
ISO 108
J
Jet Propulsion Laboratory (JPL) 52, 179
Job, champion 106
Johnson, Jim 27
JPL, see Jet Propulsion Laboratory
K
Kaiser Electronics 97, 98
KLOC, definition 43 (footnote)
L
LAU9 136
Launch, TSP 79, 123, 124
    management meeting 82, 125, 128, 130, 135
    process 124
    products 135, 138, 139
    team 79
    TSP 123
Leader, team 202
Leadership
    goals 51
    communication 116
Life-threatening quality problems 41
Lincoln Laboratories 20
Lines of code (LOC) 43
    definition 43 (footnote)
    projections 173
Load balancing questions 172
LOC, see Lines of code
Long-range plan 111
Lotus 8
M
Magellan spacecraft 179
Magic, belief in 23
Maintaining commitment 88
Malcolm Baldrige Quality Award 68
Management
    commitment 26
    crisis 32
    goals 51, 107, 111
    meetings, launch 82, 125, 128, 130, 135
    participation in launch 133
    principles 2
    quality 12, 47
    rational 29, 31, 33, 35, 37
    responsibilities 54, 62, 107
    schedule 159
    software work 2, 12
    task time 61
    training, TSP 111, 203
    yield 178, 191
Market, time to 10
Mars
    Climate Observer 51
    Orbiter 42
    Polar Lander 52
McAndrews, Donald 102, 210
Measurable goals 106
Measures
    quality 12, 48, 180
    task time 60, 150
Measuring software quality 12, 48, 180
Memory, virtual 19
Mencken, H. L. 29
Methods, defect removal 44
Metrics, quality 48, 180
Michigan, University 21
Microsoft 6, 7, 8, 199
Military aircraft software 4
MIT 19
Module
    data 190
    defective 9, 35
    high risk 189
Monitoring
    discipline 38
    performance 39
Motivating action 37
Motivation 84
    building 75, 77, 79, 84
    commitment 84
    elements of 115, 159
    engineer 15, 60
    fear 84
    greed 84
    house-building example 57
    people 3, 10
    team 75, 77, 79, 84, 115, 159
        elements of 115, 159
        requirements for 84, 115
    ways to build 84
Multiple assignments 18
Musson, Robert 64, 103
Multix system, GE 20, 25
N
NASA 51, 52, 53
Nature of defects 194
Need for planning 55
Negotiating with teams 86
New Zealand 79
Next steps 105
Nikora, Allen P. 196
Nurturing teams 89
O
Oberg, James 64
Objectives
    opening meeting 126
    quality 181
    standard stage review 181
OS/2 7
OS/360 32
Outlier points 92
Outsourcing 2
Oversight, executive 110
Overview, TSP 115
Ownership 81
P
Panic 85
Part time assignments 18
Participation, management 133
Paulk, Mark C. 76
Pentium 42
People
    disciplined 3, 10
    motivated 3, 10
Performance
    monitoring 39
    reviews 107
    team 73
Personal data 72
Personal Software Process (PSP) 13, 68, 69, 77, 120
    course 70, 71
        benefits 70-74
        prerequisites 203
        principles 70
        results 70-74
    development of 68
    instructors 109
        training 119, 203
    productivity 74
    quality 72
    team performance 73
    training 119, 120, 203
    using 79
Phase
    ratio guidelines 192
    ratios, questions 191
    yield 178, 191, 192
        definition 178
Plan
    action 110
    alternate 141
    assessing 153
    assessment 143, 147, 153
        Checklist 143, 144
        examples 146
    bonus 66
    common team 116
    comparison 151
    detailed 55, 81
    evaluating 143, 147
        cannot meet goal 146
        meets goal 146
        needs resources 146
    precise 55
    presentation 140
    project 141
    quality 72, 81, 153
        evaluating 152
    requiring 37
    reviewing 133
    tracking 38
Planning 71
    example of 33
    how accelerates work 55
    need for 55
    questions 168
Policy, quality 105, 111
Poor quality
    example 22
    life threatening 41
    products 26
Practices
    disciplined 11, 67
    design 70
Precise plans 55
Predictability, quality work 47, 91
Preliminary yield 193
Preparation, team 118
    inadequate 120
Prerequisites, committed team 85
Presentation, plan 140
Principles
    software management 2
    PSP course 70
Priorities
    establishing 109
    quality 3
Problems
    anticipating 39
    software 5
    software quality 9, 41
Process
    common 116
    defined 70
    improvement responsibility 66
    review 163
    team 116
    teambuilding 63
    TSP 115
Productive time 58
Productivity 74, 201, 207
    data 148
    estimate 149
    improving 58
    PSP course 74
    results
        PSP 74
        TSP 207
Products
    future 1
    launch 138, 139
    poor quality 22, 26
    planned 138
    quality 11, 97
    uniqueness 7
Professionals, creative 67
Profile, defect-removal 185
Project
    crash 15
    failure 15
        common causes 17, 27
        executive role in 24
    reviews 157
Projections
    line of code 173
    project completion 170
Protecting the team 89
PSP, see Personal Software Process
Q
Quality
    and engineers 12
    as a testing problem 9
    commitment 11
    costs 100
    culture 12
    dedication to 15, 26
    discipline 158
    goals 57
    house building example 56
    improved 95
    life-threatening 41
    management 12, 22, 47
    measures, software 48, 180
    metrics 180
    objective 181
    plan 81, 153
        evaluating 152, 153
    policy 105, 111
    poor 22, 41
    priority 3
    problem 41
    products 11, 95
    PSP 72
    responsibility 47
    savings 100
    software 3
    standards 12
    testing problem 9
    top priority 3
    versus schedule 8
    why pays 41
    work 3, 11
Quarterly
    project review 157
    review checklist 163, 164, 181, 182
Quartile range 92, 197
Questions
    benchmark comparisons 195
    defect
        density 193
        ratios 191
        recording 183
    during launch 127
    earned value 170
    load balancing 172
    key for software management 12
    phase ratios 191
    planning 168
    review rates 187
    size recording 172
    task time 169
    team 127, 130
    time recording 172
    yield management 191, 192
R
Rates, code review 187
Rational management 29
    essence of 37
    first element 31
    fourth element 37
    second element 33
    third element 35
Ratios
    defect 192
    guidelines 192
    phase 192
Realistic goals 35
Recording
    defect data 181
    size data 172
    time data 172
Reducing
    costs 58
    turnover 97
Relaunch, TSP 116
Removal methods, defect 44
Repair time, defects 201
Requirements
    changing 19, 26
    for motivated teams 84, 115
Requiring
&nbs

Updates

Submit Errata