eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
"Every senior executive needs to read this book."
--Robert Musson Vice President, Business Strategy Cenus Technologies
"An informative book for any business person (not just technologists) who has ever been associated or involved with a software development effort and thought 'there must be a better way!' Watts has provided that better way-- the PSP/TSP, and a great book."
--Roy Kinkaid, Head of Continuous Improvement and Software Quality Assurance, EBS Dealing Resources
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."
--Kevin J. Berk, Director, Process Improvement, Total Quality Systems
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."
--Steven Sliwa, President & CEO, Insitu Group Inc. and former President of Embry-Riddle University
"The logical approach, the high level explanations, and the application of real-life experiences make the book not only credible but easily understood. If a large number of CEOs don't at least try out the book's concepts, I will be greatly surprised."
--David Webb Software Engineering Project Manager, Hill Air Force Base
Product Details
| ISBN-13: | 9780768685107 |
|---|---|
| Publisher: | Pearson Education |
| Publication date: | 12/20/2001 |
| Series: | SEI Series in Software Engineering |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 256 |
| File size: | 3 MB |
About the Author
Known as “the father of software quality,” Watts S. Humphrey is the author of numerous influential books on the software-development process and software process improvement. Humphrey is a fellow of the Software Engineering Institute (SEI) at Carnegie Mellon University, where he founded the Software Process Program and provided the vision and early leadership for the original Capability Maturity Model (CMM). He also is the creator of the Personal Software Process (PSP) and Team Software Process (TSP). Recently, he was awarded the National Medal of Technology–the highest honor given by the president of the United States to America's leading innovators.
Read an Excerpt
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 evil—something 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 professional's 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 providedproducts 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 don't 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, we're 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 organization's 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 the story. There is plenty of substance to the PSP and TSP, and I have included enough to give you a feel for the subject. Second, software is a fascinating business and you may wish to explore some elements of the subject more deeply. Third, senior and mid-level managers can use this material to guide them in improving their organization's software capability. BOOK ORGANIZATION AND CONTENTS
In this book, I describe the software business. Whether or not you know it, you are in the software business and the performance of your software groups has a significant impact on business performance. I first describe the impact of software on your business and then review some of the most common software problems and their causes. Finally, I describe the transformation you must lead and the actions required to capitalize on the potential of software for your business.
At the end of the book, I include five appendices on installing the PSP and TSP methods and making these methods a standard part of everyday business. The sixth, and final, appendix offers a brief financial analysis of the return on investment you can expect from making these changes.—Watts S. Humphrey
Sarasota, Florida
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.
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 evil — something 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 manufacturing cost, can be distributed world-wide 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 professional's 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 while 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 don't 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 takes an organizational transformation. What is more, they discover that they must personally lead this transformation. This transformation is not a simple change and, like all changes, it 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 had 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. Now that 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.
At the time I retired from IBM in 1986, I looked at the software industry in general. It was obviously 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 likeminded 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.
While 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. 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)SM and the Team Software Process (TSP)SM. The development of these methods is described in Chapters 7 and 8.
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. You can view this as either a threat or an opportunity. As Bob Musson, an engineering manager at Teradyne, told me, "With the TSP, we're 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 are typically 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 properly trained and to support them for long enough to gain the experience to consistently practice these methods.
Who This Book Is For
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 organization's resources. As a result, much of the material has a business slant and there is a minimum of technical jargon. However, I do delve a little more deeply into the technical material than many executives might expect.
There are three reasons for doing this. First, executives are often suspicious of impressive presentations and like to dig a little deeper to see if there is substance behind the story. There is plenty of substance to the PSP and TSP and I have included enough to give you a feel for the subject. Second, software is a fascinating business and you may wish to explore some elements of the subject more deeply. Finally, senior and mid-level managers can use this material to guide them in improving their organization's software capability.
Book Organization and Contents
In this book, I describe the software business. Whether you know it or not, you are in the software business and the performance of your software groups has a significant impact on business performance. I first describe the business impact of software on your business and then review some of the most common software problems and their causes. Finally, I describe the transformation you must lead and the actions required to capitalize on the potential of software for your business.
At the end of the book, I include five appendices on installing the PSP and TSP methods and making these methods a standard part of everyday business. The final sixth appendix has a brief financial analysis of the return on investment you can expect from making these changes.
—Watts S. Humphrey
Sarasota, Florida