Software Project Secrets: Why Software Projects Fail (Expert's Voice) (Hardcover)

~ (Author)
Key Phrases: enterprise application frameworks, reflective improvement, agile methodologies, Extreme Programming, Rational Unified Process, Make Them Succeed (more...)

Editorial Reviews

Product Description

<p><i>Software Project Secrets: Why Software Projects Fail</i> offers a new path to success in the software industry. This book reaches out to managers, developers, and customers who use industry-standard methodologies, but whose projects still struggle to succeed.</p>

<p>Author George Stepanek analyzes the project management methodology itself, a critical factor that has thus far been overlooked. He explains why it creates problems for software development projects and begins by describing 12 ways in which software projects are different from other kinds of projects. He also analyzes the "Project Management Body of Knowledge" to discover 10 hidden assumptions that are invalid in the context of software projects.</p>

About the Author

George Stepanek is a senior software developer and team leader for Unisys New Zealand. He earned a master's degree from the University of Cambridge and certification as an architect in J2EE and Microsoft's .NET.

Product Details

• Hardcover: 192 pages
• Publisher: Apress (September 1, 2005)
• Language: English
• ISBN-10: 1590595505
• ISBN-13: 978-1590595503
• Product Dimensions: 9.1 x 6 x 0.8 inches
• Shipping Weight: 1 pounds (View shipping rates and policies)
• Average Customer Review: 4.5 out of 5 stars  See all reviews (6 customer reviews)
• Amazon.com Sales Rank: #830,294 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

7 of 7 people found the following review helpful:

5.0 out of 5 stars Fix What's Broken in Your Software Development Project!, January 9, 2006

By	D-MAG.org Reviewer (Lexington, KY USA) - See all my reviews

I work for a software company as a Senior Technical Writer, so when I reviewed this book, I expected it to hit close to home. It did.

In the second of two software development firms I have worked with, I realized that the issues which George Stepanek brings out in his book were the same challenges for each company. All parties involved had their own agendas but none of them followed the same methodologies for getting things done, or they found their methodologies did not exact work with Software Development projects.

This is especially true when it comes between the Software Developers and the Project Managers. The Project Managers tend to see only their schedules and not the challenges of the Developers, such as time, code requirements and adequate staffing. I think sometimes the Developers live, eat and sleep at the office to try to get the software to GA (General Availability).

At the end of a development project, many times you look back and try to figure out what went wrong, or what steps to avoid for next time. I think it is wonderful that Stepanek details the key factors which cause a project to fail. Many Project Managers look at the specifics of a software development project only to find they can't quite figure out the difference between this type of project and the others. Fortunately, for the reader the author identifies twelve facts that make software development so different from other projects. With these facts, clearly in hand, Project Managers and Developers can come closer together to make the project a success. Unique to this book as well, Stepanek also identifies ten wrong assumptions (in his analysis of the "Project Management Body of Knowledge") that are made by managers and how to avoid them.

Stepanek also takes a look at three modern project management methods. This is a topic that many books on Software Development and Project Management fail to address. He details what parts of each methodology works to solve some of the issues of software development projects. Almost more importantly, Stepanek identifies the areas in which these tried-and-true methodologies fail to solve the unique problems of software development projects.

Going one step further, the author discusses seven different techniques that can be used by Project Managers to ensure that the projects come in on time and on budget. This should be music to Project Managers' ears!

One thing I do like is the illustration of a point or an example. Stepanek includes a case study at the end of the book which shows what challenges can appear and how to cope with them successfully.

This book should be required reading and a great supplement for the Project Managers, Product Managers, Software Developers and even customer who have been trained to use the methodologies commonly used in the industry, but still have project that fail or are difficult to manage to completion.

1 of 1 people found the following review helpful:

4.0 out of 5 stars Software Project Secrets: Why Software Projects Fail, April 27, 2008

By	P. Newman (Silicon Valley, CA USA) - See all my reviews (REAL NAME)

When I first read this book about two years ago, I wasn't that impressed. I thought author George Stepanek spent too much time explaining things that seemed obvious, and was indecisive in the recommendations he made. Having a few more years experience under my belt, I have a better sense for author was getting at and more of an appreciation for the book.

The first section of the book runs down 12 challenges of software development that make it unique from a project management perspective. This section is mostly valuable for novices, but objective enough to be worth reading for veterans as well. The author makes a particulary good point in that software development is research and that you're inevitably doing something new each time. However I find the real value in this section is that it allows the reader to objectively judge the processes introduced later in the book.

The approaches that Stepanek advocates are all clearly in the Agile realm. The three methodologies discussed are Crystal, Rational Unified Process, and Extreme Programming. This is probably the only book I've ever read on software development process that doesn't advocate one methodology over another. Stepanek recognizes that different approaches apply to different situations, and this is one of the book's biggest strengths. If you're unfamiliar with any of these three approaches, this is a good book to start with.

Stepanek brings things together with a pair of case studies, which he uses to contrast the traditional waterfall approach to the more modern Agile methodologies. The Agile case study is of more interest; Stepanek blends techniques from different methodologies and shows how they can be used in conjunction to solve different problems. The case study is somewhat limited in scope, but it provides concrete examples of using the techniques described earlier in the book. By blending techniques from different methodologies, the author avoids a "one size fits all" recommendation, which I've found other books prone to.

The one thing to be aware of when reading this book is that its content is better suited to developing internal applications rather than external production applications. The thinking is more geared toward an environment where budget and schedule are more important than things like user experience and performance. If you're contributing to an internal software project in any role, I'd recommend giving this book a read.

1 of 1 people found the following review helpful:

4.0 out of 5 stars Good and easy read, January 3, 2007

By	Jon M. Quigley (Greensboro, NC) - See all my reviews (REAL NAME)

The book compares software project management from a number of "agile development" perspectives to the PMI model for project management. The book illustrates assumption made in the PMI methodology, and provides a counter point or rebuttal to those assumptions. Thus the book suggests the PMI model is not entirely applicable for software project management. While this book challenges some of the PMI methods, it provides alternative approaches to achieving project success. I liked the book, and appreciated the examples, even when I did not fully agree with some of the assertions.