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 in paperback or Kindle formats or from O'Reilly in Ebook format.


Survival Crib Notes 

This book’s key guidelines are presented in combination with key guidelines from one of the world’s most effective software development organizations. The end of the chapter provides pointers to additional reading and other resources.

This chapter summarizes the elements needed for software project success. It distills the main messages of this book into a few pages.

The first section overviews the approach used by one of NASA’s software development organizations. The second describes resources you should consider adding to your personal software survival kit.

NASA’s Success Checklist

The Software Engineering Laboratory at NASA’s Goddard Space Flight Center has been on the cutting edge of software development practices for almost 20 years. The Software Engineering Laboratory (SEL) is one of the most competent, most successful software development organizations in the world. In 1994, in recognition of the extraordinary productivity and software quality it has achieved, the SEL became the first organization to win the IEEE’s award for software process achievement.

If you think that NASA’s software needs to be ultra-reliable and their lessons don’t apply to your organization, think again. The SEL has achieved productivity comparable to the average MIS or IT system, at the same time achieving quality levels that are at least 10 to 20 times better. To put it a little differently, the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects.

The SEL’s Recommended Approach to Software Development crystallizes the lessons the SEL has learned over 20 years into a set of 9 Dos and 8 Don’ts for software project success, which are presented here.

NASA SEL’s Dos for Software Success

Here are nine elements of a successful project.

Create and follow a Software Development Plan.
At the beginning of the project, prepare a Software Development Plan that describes the project’s vision, defines the team structure, and defines the development methods. The plan should include estimates, major milestones, and other measures that will be used to track progress. The SDP should be a living document, which is updated at the end of each major phase or stage.

Empower project personnel.
Tap into the project’s human potential by aligning the development team on a project vision, providing them with a productive environment to work in, and clearly assigning responsibilities and the authority needed to carry out their responsibilities.

Minimize the bureaucracy.
Establish the minimum amount of process overhead needed to satisfy the project’s objectives. Be sure that there is a good reason for required meetings and paperwork. As NASA says, "More meetings plus more documentation plus more management does not equal more success."

Define the requirements baseline and manage changes to it.
Stabilize requirements as early as possible. Keep a detailed list of potentially volatile requirements or undefined requirements, and prioritize the list by estimated cost and schedule impact. Try to resolve these items during architecture or, at latest, during detailed design.

Take periodic snapshots of project health and progress, and replan when necessary.
Regularly compare the project’s progress against the project plan. Also compare the project’s progress against past similar projects. The project plan should be based on experience from past similar projects. If there is a significant deviation from the project plan, replan. Carefully consider reducing the scope of the work when replanning, and try not to be unrealistically optimistic.

Reestimate system size, effort, and schedules periodically.
Each new phase of the project provides new information about the system being built. Do not insist on maintaining the original estimates, but plan on refining the estimates at the completion of each major milestone. Estimation is an inexact science, and there is nothing wrong with finding that the development team underestimated the project’s size or overestimated their own productivity. What is wrong is not to plan to periodically check an estimate’s accuracy and correct it as the project progresses.

Define and manage phase transitions.
Some projects lose time in the transition from requirements development to architecture, architecture to stage planning, end of one stage to beginning of the next, and so on. Begin preliminary work on the next phase a few weeks before completing the current phase so that the project team as a whole can make an efficient transition to the next phase.

Foster a team spirit.
Even when a project includes people from different organizations or companies, emphasize the common vision that every person on the project is working toward. Define each person’s individual responsibilities clearly, but emphasize the whole-project context within which those responsibilities exist. Be sure to communicate status, risks, and other management issues throughout the project in the same way.

No individual is a success who hurts the team and no individual is a failure who helps it.

Start the project with a small senior staff.
Begin the project with a small group of experienced senior people who will provide leadership throughout the project. Be sure they establish a vision, define the software concept, develop an approach to the project, and are generally in alignment with each other before junior staff are brought on board.

NASA SEL’s Don’ts for Software Success

Here are eight things that successful projects do not do.

Don’t let team members work in an unsystematic way.
Efficient development of high-quality software is not a touchy-feelly, unmanageable process. It is a creative process, but one that benefits from reasoned application of defined principles, practices, methods, and techniques. Insist that the team use systematic development practices.

Don’t set unreasonable goals.
It is worse to set unreasonable goals than to set no goals at all. If the team doesn’t believe in the goals, they will merely put in their time, punch the clock, and go home. If they are rushed, they will make mistakes upstream that cost fortunes to correct downstream. Set reasonable, moderately challenging goals, and the team will stretch to meet them without damaging project efficiency.

Don’t implement changes without assessing their impacts and obtaining approval of the change board.
Estimate the impacts of each change—even important, small changes that the project can absorb without rescheduling. The project needs a record of how it changed over time, in both major and minor ways. Even if a particular change does not have a large impact, small changes add up over time and will eventually cause cost and schedule overruns if not controlled.

Don’t "gold-plate."
Implement only what is required. Developers, managers, and customers often think of small, easy changes that seem to make the software better. These changes often have much more far-reaching impacts than anticipated by the specific developer who will implement the change. Do not let additional complexity creep into the project through gold-plating.

Don’t overstaff, especially early in the project.
Start the project with a small senior team. Bring additional people onto the project only when there is meaningful work for them to do. This guideline does allow for some early use of junior personnel. During requirements and early architecture, relatively junior staff members can review documents, investigate capabilities of tools and code libraries, and perform many other tasks that require good technical skills but not guru level standing.

Don’t assume that a schedule slip in the middle of a phase will be made up later.
One common mistake is to assume that productivity will improve as the project progresses from the beginning of a phase to the end. Productivity might improve slightly, but there isn’t enough time within any particular phase to make up time. More generally, do not assume that a schedule slip at any point in the project can be made up later. If the project doesn’t catch up soon after a slip is detected, you can safely assume that it won’t be possible to catch up.

Don’t relax standards in order to cuts costs or shorten a schedule.
Relaxing standards tends to introduce errors into the project, and optimum project cost and schedule both depend on eliminating errors. Relaxing standards can also have a demotivational effect. Most developers are quality oriented, and a relaxation of standards sends the message that the customer or upper management doesn’t care about quality.

Don’t assume that a large amount of documentation ensures success.
Different projects require different kinds of documentation support. Determine the amount and kind of documentation required based on the project size, schedule, and expected lifetime of the system. Avoid U.S. Department of Defense style documentation in which a 25,000 line of code program could easily require 5000–10,000 pages of paperwork, and a 100,000 line of code program could require as much as 40,000 pages of paperwork.

Other Survival Resources

This book is a software survival guide. You might think of it as the first aid kit you carry in your backpack or car. Just as hospitals are medically better equipped than the back of your car, the universe of other software development resources will provide you with many more survival tools than this short guide presents.

Books

Here are some books that provide especially good insights mixed with practical advice.

Recommended Approach to Software Development, Revision 3, Document SEL-81-305, Greenbelt, Maryland: NASA Goddard Space Flight Center, NASA, 1992.
The Software Engineering Laboratory’s Recommended Approach is probably the most practical overview of how to run a software project that I have read. It is intended for use specifically with flight dynamics projects, but many of its recommendations are much more broadly applicable. The book describes entry criteria and exit criteria for each project phase, and gives cogent summaries of the development team, management team, and various tiger team activities within each phase. The book is worth reading solely for the sense it projects that software projects are not mysterious, hard-to-control entities, but merely extremely complex entities that can be controlled through diligent application of lessons learned from previous projects. You can obtain a single copy for free by emailing NASA SEL from http://sel.gsfc.nasa.gov/doc-st/orderdoc.htm. You can also download the document from the SEL’s website at http://sel.gsfc.nasa.gov/.

Manager’s Handbook for Software Development, Revision 1, Document SEL-84-101, Greenbelt, Maryland: NASA Goddard Space Flight Center, NASA, 1990.
The SEL’s Manager’s Handbook is almost as useful as the Recommended Approach. It is shorter, and the guidelines it presents are focused specifically on software project management topics. You can order it or download it in the same ways as the Recommended Approach

Fergus O’Connell. How to Run Successful Projects II: The Silver Bullet. London: Prentice Hall International (UK) Limited, 1996.
O’Connell’s book provides a well-written, end-to-end examination of what is needed to run a successful software project. It covers the same ground as the book you’re reading now and is quite compatible with it, but there is surprisingly little overlap. Whereas this book provides a big picture technical framework for a project, O’Connell’s book focuses on the many specific activities a project manager must perform. It includes many example project forms and planning materials. If, in reading this book you’ve asked yourself, "This all sounds good, but what do I do?" then O’Connell’s book is the right book for you.

Tom Gilb. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, 1988.
Gilb’s book puts the "engineering" into software engineering management by taking a quantitative, risk-oriented approach to conducting a software project. It is based on Gilb’s considerable experience as an internationally renowned software project management consultant. This is not the book to read to learn the conventional wisdom about software project success—it takes its own path too often for that. But I think that in the vast majority of cases in which it doesn’t follow the conventional wisdom, it is because Gilb is right and the conventional wisdom is wrong.

Lawrence H. Putnam and Ware Myers. Industrial Strength Software: Effective Management Using Measurement, Washington: IEEE Computer Society Press, 1997.
Putnam and Myers have created an excellent reference that describes how to use software measurement to manage all aspects of software development. In contrast to Gilb’s book, Putnam and Myers’s book focuses less on specific projects and more on organizational capability. Chapter 21, "Shining Shadow Loses its Luster," is a special gem—dramatically illustrating the power of quantitative approaches to software project management.

Tom DeMarco and Timothy Lister. Peopleware: Productive Projects and Teams. New York: Dorset House, 1987.
Peopleware drives home the message that programming is first and foremost something done by people and only secondarily something that happens to involve computers. It’s entertaining reading, providing memorable stories about software teams that worked and teams that didn’t.

Alan M. Davis. 201 Principles of Software Development, New York: McGraw-Hill, 1995.
201 Principles provides an easy-to-read introduction to the critical issues in software development. Davis’s book prepares you to recognize key issues when other books discuss them and when they crop up on your own projects.

Steve McConnell. Rapid Development. Redmond, WA: Microsoft Press, 1996.
If you’ve liked this book, you will probably also like what I have to say in Rapid Development. It contains general, but still practical, discussions of classic mistakes, risk management, lifecycle planning, scheduling, motivation, teamwork, and many other topics related to rapid software development.

Internet Resources

My company has created a survival guide website at http://www.construx.com/survivalguide/. It includes examples of many of the sample documents and forms this book recommends such as the Software Development Plan, User Interface Style Guide, estimation procedure, release signoff form, and many more. It contains links to software development resources on other websites including current links to source code control tools, time accounting tools, estimation software, and defect tracking tools. It contains electronic versions of this book’s Survival Checks and a spreadsheet version of Chapter 2’s Software Project Survival Test.

Email me at stevemcc@construx.com.