Software Project Survival Guide: How to Be Sure Your First Important Project Isn't Your Last. Redmond, Wa.: Microsoft Press, 288 pages, 1997. Retail price: $24.99. ISBN: 1-57231-621-7. Available from Microsoft Press 1-800-MS-PRESS (1-800-677-7377). Buy SPSG from Amazon.com.

Preliminary Survival Briefing 

This book explains how to prevent your project from suffering these consequences—whether you’re a senior manager, executive, software client, user representative, or project leader. Software projects fail for one of two general reasons: the project team lacks the knowledge of how to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively. This book cannot do much about the lack of resolve, but it does contain much of the knowledge needed to conduct a software project successfully.

The factors that make a software project successful are not especially technical. Software projects are sometimes viewed as mysterious entities that survive or perish based on the developers’ success in chanting magic technical incantations. When asked why they delivered a component two weeks late, developers say things like, "I had to implement a 32-bit thunking layer to interface with our OCX interface." Faced with explanations like that, it is no wonder that people without detailed technical expertise feel powerless to influence a software project’s success.

The message of this book is that software projects survive not because of detailed technical considerations like "thunking layers," but for much more mundane reasons. Software projects succeed or fail based on how carefully they are planned and how deliberately they are executed. The vast majority of software projects can be run in a deterministic way that virtually assures success. If a project’s stakeholders understand the major issues that determine project success, they can ensure that their project reaches a successful conclusion. The person who keeps a software project headed in the right direction can be a technical manager or individual software developer—it can also be a top manager, client, investor, end-user representative, or any other concerned party.

Who Should Read This Book

This book is for anyone who has a stake in a software project’s outcome.

Top Managers, Executives, Clients, Investors, and End-User Representatives

Non-software people are commonly given responsibility for overseeing the development of a software product. Some of these people have backgrounds in sales, accounting, finance, law, or some other field. These people might not have any formal authority to direct the project, but they will still be held accountable for seeing that the project goes smoothly. At a minimum, these people are expected to sound an alarm if the project begins to go awry.

If you’re in this group, this book will provide you with a short, easily readable description of what a successful project looks like. It will give you many ways to tell in advance whether the project is headed for failure or success. It will also describe how to tell when no news is good news, when good news is bad news, or when good news really is good news.

Project Managers

Many software project managers are thrust into management positions without any training specific to managing software projects. If you’re in this group, this book will help you master the key technical-management skills of requirements management, software project planning, project tracking, quality assurance, and change control.

Technical Leaders, Professional Developers, and Self-Taught Programmers

If you’re an expert in technical details, you might not have had much exposure to the big-picture issues that project leaders need to focus on. In that case, you can think of this book as an annotated project plan. By providing an overview of a successful software project, this book will help you make the transition from expert technician to effective project leader. You can use the plan described in this book as a starting point that you can tailor to the needs of your specific projects.

Kinds of Projects That Can Use This Book

The plan described in this book will work for business systems, broad-distribution shrink-wrap software, vertical market systems, scientific systems, and similar programs. It is designed for use on desktop client/server projects using modern development practices such as object-oriented design and programming. It can easily be adapted for projects using traditional development practices and mainframe computers. The plan has been designed with project team sizes of 3-25 team members and schedules of 3-18 months in mind. These are considered to be medium-size projects. If your project is smaller, you can scale back some of this book’s recommended practices. (Throughout the book, I point out places you can do that.)

This book is primarily intended for projects that are currently in the planning stages. If you’re at the beginning of the project, you can use this book’s approach as the basis for your project plan. If you’re in the middle of a project, the Survival Test in Chapter 2 and the Survival Checks at the end of each chapter will help you determine your project’s chance of success.

By itself, this book’s plan is not formal or rigorous enough to support life-critical or safety-critical systems. It is appropriate for commercial applications and business software, and it is a marked improvement over many of the plans currently in use on multi-million-dollar projects.

A Note to Advanced Technical Readers

This book describes one effective way to conduct a software project. It is not the only effective way to run a project, and for any specific project it might not be the optimum way. The extremely knowledgeable technical leader will usually be able to come up with a better, fuller, more customized development plan than the generic one described here. But the plan described here will work much better than a plan that has been hastily thrown together or no plan at all, and "no plan at all" is the most common alternative.

The plan described in this book has been crafted to address the most common weaknesses that software projects face. It is loosely based on the "key process areas" identified by the Software Engineering Institute (SEI) in Level 2 of the SEI Capability Maturity Model. The SEI has identified these key processes as the critical factors that enable organizations to meet their schedule, budget, quality, and other targets. About 85 percent of all organizations perform below Level 2, and this plan will support dramatic improvements in those organizations.

The Software Engineering Institute has defined the key process areas of Level 2 as follows:

• Project planning
• Requirements management
• Project tracking and oversight
• Configuration management
• Quality assurance
• Subcontract management

This book does not address the area of subcontract management, but it addresses the other areas.

This Book’s Foundation

In writing this book, I have kept three primary references at my elbow that have been invaluable resources. In addition to the many other resources I’ve drawn from, I’ve tried to condense the contents from these three references and present them in the most useful way that I can.

The first reference is the Software Engineering Institute’s Key Practices of the Capability Maturity Model, Version 1.1. This book is a gold-mine of hard-won industry experience in prioritizing implementation of new development practices. At almost 500 pages it is somewhat long, and even at that length the information is still dense. It is not a tutorial and so is not intended for the novice reader. But for someone who has a basic understanding of the practices it describes, the summary and structure it provides is a godsend. This book is available free on the Internet at http://www.sei.cmu.edu/ or from the National Technical Information Service (NTIS) branch of the U.S. Department of Commerce in Springfield, Virginia.

The second reference is NASA Software Engineering Laboratory’s (SEL’s) Recommended Approach to Software Development, Revision 3. The SEL was the first organization to receive the IEEE Computer Society’s "Process Achievement Award." Many keys to the success of their process are described in their Recommended Approach. Whereas the SEI’s document describes a set of practices without showing how to apply them to a specific project. The two volumes together form a complementary set. For those of us who sometimes wonder where our tax dollars are going, the steady streams of state-of-the-art software practices coming from the SEI and NASA’s SEL are encouraging. This book is also available free on the Internet at http://sel.gsfc.nasa.gov/.

The final "book" at my elbow has been my own experience. I am writing not as an academician who wants to create a perfect theoretical framework, but as a practitioner who wants to create a practical reference that will aid me in my work and my clients in theirs. The information drawn together here will make it easier for me to plan and conduct my next project and easier to explain its critical success factors to my clients. I hope it does the same for you.

Steve McConnell
Bellevue, Washington
August 1997