Software Project Secrets: Why Software Projects Fail
Your boss has asked you to oversee the development of a new billing system, and you’ve brought together a capable project manager and a group of handpicked developers. They’ve chosen state-of-the-art technologies and tools to build the system. The business analyst has talked at length with the ac...
Đã lưu trong:
| Tác giả chính: | |
|---|---|
| Định dạng: | Sách |
| Ngôn ngữ: | English |
| Được phát hành: |
Apress
2013
|
| Những chủ đề: | |
| Truy cập trực tuyến: | https://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/34769 |
| Các nhãn: |
Thêm thẻ
Không có thẻ, Là người đầu tiên thẻ bản ghi này!
|
| Thư viện lưu trữ: | Thư viện Trường Đại học Đà Lạt |
|---|
| id |
oai:scholar.dlu.edu.vn:DLU123456789-34769 |
|---|---|
| record_format |
dspace |
| spelling |
oai:scholar.dlu.edu.vn:DLU123456789-347692014-01-20T01:41:30Z Software Project Secrets: Why Software Projects Fail Stepanek, George Software Computer Your boss has asked you to oversee the development of a new billing system, and you’ve brought together a capable project manager and a group of handpicked developers. They’ve chosen state-of-the-art technologies and tools to build the system. The business analyst has talked at length with the accounting manager, and has written up a detailed set of requirements. The project has everything it needs to be a success—doesn’t it? Apparently not. Six months later the project is already late and over budget. The developers have been working overtime for weeks, and one has already quit, but despite this the software never seems to get any closer to completion. Part of the problem is that the accounting team keeps claiming that the software doesn’t do what they need, and they have pushed through a steady stream of “essential” change requests, not to mention a flood of bug reports. Your boss will be furious when she hears about this. So what went wrong? Whatever it is, it must be something that most companies get wrong. According to Standish Group [2001] research, only 28 percent of software projects in 2000 succeeded outright (see Figure 1-1). Some 23 percent were canceled, and the remainder were substantially late (by 63 percent on average), over budget (by 45 percent), lacking features (by 33 percent), or, very often, all of those issues combined. At New Zealand’s Ministry of Justice, the new $42 million Case Management System was $8 million over budget and over a year late when it was rolled out in 2003. Of the 27 benefits expected from the system, only 16 have been realized. Instead of boosting productivity, the system has actually increased the time needed to manage court cases by doubling the amount of data entry. A postimplementation review identified over 1,400 outstanding issues. But “the only challenges faced by the developers were those common to large and complex systems” [Bell 2004]. ABOUT THE AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii ABOUT THE TECHNICAL REVIEWER . . . . . . . . . . . . . . . . . . . . . . xv ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii PART I WHY SOFTWARE PROJECTS FAIL . . . CHAPTER 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 3 CHAPTER 2 WHY SOFTWARE IS DIFFERENT . . . . . . . . . . . . . . . . 7 CHAPTER 3 PROJECT MANAGEMENT ASSUMPTIONS . . . . . . . . . . 23 CHAPTER 4 CASE STUDY:THE BILLING SYSTEM PROJECT . . . . . . . . 51 PART I I . . . AND HOW TO MAKE THEM SUCCEED CHAPTER 5 THE NEW AGILE METHODOLOGIES . . . . . . . . . . . . . 65 CHAPTER 6 BUDGETING AGILE PROJECTS . . . . . . . . . . . . . . . . . 97 CHAPTER 7 CASE STUDY:THE BILLING SYSTEM REVISITED . . . . . . 115 CHAPTER 8 AFTERWORD . . . . . . . . . . . . . . . . . . . . . . . . . . 131 APPENDIX:THE AGILE MANIFESTO . . . . . . . . . . . . . . . . . . . . . . . 133 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 2013-07-18T07:58:31Z 2013-07-18T07:58:31Z 2005 Book 1-59059-550-5 https://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/34769 en application/pdf Apress |
| institution |
Thư viện Trường Đại học Đà Lạt |
| collection |
Thư viện số |
| language |
English |
| topic |
Software Computer |
| spellingShingle |
Software Computer Stepanek, George Software Project Secrets: Why Software Projects Fail |
| description |
Your boss has asked you to oversee the development of a new billing system,
and you’ve brought together a capable project manager and a group of handpicked
developers. They’ve chosen state-of-the-art technologies and tools to
build the system. The business analyst has talked at length with the accounting
manager, and has written up a detailed set of requirements. The project has everything it needs to be a success—doesn’t it?
Apparently not. Six months later the project is already late and over budget. The developers have been working overtime for weeks, and one has already quit, but despite this the software never seems to get any closer to completion. Part of the problem is that the accounting team keeps claiming
that the software doesn’t do what they need, and they have pushed through a steady stream of “essential” change requests, not to mention a flood of bug reports. Your boss will be furious when she hears about this.
So what went wrong? Whatever it is, it must be something that most companies get wrong.
According to Standish Group [2001] research, only 28 percent of software projects in 2000 succeeded outright (see Figure 1-1). Some 23 percent were canceled, and the remainder were substantially late (by 63 percent on average), over budget (by 45 percent), lacking features (by 33 percent), or, very
often, all of those issues combined.
At New Zealand’s Ministry of Justice, the new $42 million Case Management System was $8 million over budget and over a year late when it was rolled out in 2003. Of the 27 benefits expected from the system, only 16
have been realized. Instead of boosting productivity, the system has actually
increased the time needed to manage court cases by doubling the amount of data entry. A postimplementation review identified over 1,400 outstanding issues. But “the only challenges faced by the developers were those common to large and complex systems” [Bell 2004]. |
| format |
Book |
| author |
Stepanek, George |
| author_facet |
Stepanek, George |
| author_sort |
Stepanek, George |
| title |
Software Project Secrets: Why Software Projects Fail |
| title_short |
Software Project Secrets: Why Software Projects Fail |
| title_full |
Software Project Secrets: Why Software Projects Fail |
| title_fullStr |
Software Project Secrets: Why Software Projects Fail |
| title_full_unstemmed |
Software Project Secrets: Why Software Projects Fail |
| title_sort |
software project secrets: why software projects fail |
| publisher |
Apress |
| publishDate |
2013 |
| url |
https://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/34769 |
| _version_ |
1819832047902916608 |