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.
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.
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.
My company has created a survival guide website at www.construx.com/. 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.