If you do a good job of specifying a lean product, you might think you have your feature set under control. Most projects aren't that lucky. For many years, the holy grail of requirements management has been to collect a set of requirements—scrubbed, minimally specified, or otherwise—encase them in permafrost, and then build a complete product design, implementation, documentation, and quality assurance atop them. Unfortunately for developers and their ulcers, projects that have successfully frozen their requirements have proven to be almost as hard to find as the Holy Grail itself. A typical project experiences about a 25-percent change in requirements during development (Boehm 1981, Jones 1994).
Mid-project changes arise from many sources. End-users want changes because they need additional functionality or different functionality or because they gain a better understanding of the system as it's being built.
Marketers want changes because they see the market as feature-driven. Software reviews contain long lists of features and check marks. If new products with new features come out during a product's development, marketers naturally want their products to stack up well against the competition, and they want the new features added to their product.
Developers want changes because they have a great emotional and intellectual investment in all of the system's details. If they're building the second version of a system, they want to correct the first version's deficiencies, whether such changes are required or not. Each developer has an area of special interest. It doesn't matter whether a user interface that's 100 percent compliant with user-interface standards is required, or whether lightning-fast response time, perfectly commented code, or a fully normalized database are specified: developers will do whatever work is needed to satisfy their special interests.
All these groups—end-users, marketers, and developers—will try to put their favorite features into the requirements spec even if they didn't make it during the formal requirements-specification activity. Users sometimes try to end-run the requirements process and coax specific developers into implementing their favorite features. Marketers build a marketing case and insist later that their favorite features be added. Developers implement unrequired features on their own time or when the boss is looking the other way.
CROSS-REFERENCE
For tips on resisting pressure, including pressure to add requirements, see Beating Schedule Pressure, Beating Schedule Pressure.
All in all, projects tend to experience about a 1-percent change in requirements per month. On average, the longer your project takes, the more your product will change before it's complete (Jones 1994). A few factors can make that figure considerably worse.
Shrink-wrap products are particularly susceptible to "killer-app syndrome." The development group at Company A sets developing "the best application in its class" as its design goal. The group designs an application that meets that criteria and then begins to implement it. A few weeks before the software is scheduled to ship, Company B's application enters the market. Their application has some features that Company A never thought of and others that are superior to Company A's. The development group at Company A decides to slide its schedule a few months so that it can redesign its application and truly clobber Company B. It works until a few weeks before its revised ship date, and then Company C releases its software, which is again superior in some areas. The cycle begins again.
It's difficult to resist setting ambitious goals for a project: "We want to develop a world-class product in the shortest possible time at the lowest possible cost." Because it isn't possible to meet that entire set of goals or because the goals are unclear, the most likely result is meeting none of the goals. If developers can't meet the project's goals, they will meet their own goals instead, and you will lose much of your influence over the project's outcome.
To illustrate the way in which clear goals can have a significant effect on a development schedule, consider the design and construction of a charting program. There is a tiny part of the charting program that deals with "polymarkers"—squares, circles, triangles, and stars that designate specific points on a graph. Figure 14-4 shows an example. Suppose that the specification is silent on the question of whether to provide the user with the ability to control the polymarkers' sizes. In such a case, the developer who implements the polymarkers can provide such control in any of many ways:
Do not provide any control at all.
Set up the source code to be modified in one place for the whole set of polymarkers (that is, sizes of all polymarkers are set by a single named constant or preprocessor macro).
Set up the source code to be modified in one place, on a polymarker-by-polymarker basis, for a fixed number of polymarkers (that is, size of each polymarker—square, triangle, and so on—is set by its own named constant or preprocessor macro).
Set up the source code to be modified in one place, on a polymarker-by-polymarker basis, for a dynamic number of polymarkers (for example, you might later want to add cross-hairs, diamonds, and bull's-eyes to the original set of polymarkers).
Allow for modification of an external file that the program reads at startup, one setting for the whole set of polymarkers (for example, an .ini file or other external file).
Allow for modification of an external file that the program reads at startup, different settings for each polymarker, for a fixed number of polymarkers.
Allow for modification of an external file that the program reads at startup, different settings for each polymarker, for a dynamic number of polymarkers.
Allow for interactive, end-user modification of a single polymarker- size specification.
Allow for interactive, end-user modification of polymarker-size specifications, with one setting per polymarker, for a fixed number of polymarkers.
Allow for interactive, end-user modification of polymarker-size specifications, with one setting per polymarker, for a dynamic number of polymarkers.
These options represent huge differences in design and implementation times. At the low end, a fixed number of polymarkers have their sizes hard-coded into the program. This requires only that polymarkers be represented in an array of fixed size. The amount of work required to implement that beyond the base work required to implement polymarkers would be negligible, probably on the order of a few minutes.
At the high end, a variable maximum number of polymarkers have their sizes set at runtime, interactively, by the user. That calls for dynamically allocated data, a flexible dialog box, persistent storage of the polymarker sizes set by the user, extra source-code files put under version control, extra test cases, and documentation of all the above in paper documents and online help. The amount of work required to implement this would probably be measured in weeks.
The amazing thing about this example is that it represents weeks of potential difference in schedule arising from a single, trivial characteristic of a charting program—the size of the polymarkers. We haven't even gotten to the possibility that polymarkers might also be allowed to have different outline colors, outline thicknesses, fill colors, orderings, and so on. Even worse, this seemingly trivial issue is likely to interact with other seemingly trivial issues in combination, meaning that you multiply their difficulties together rather than merely add them.
The point of this is that the devil really is in the details, and implementation time can vary tremendously based on how developers interpret seemingly trivial details. No specification can hope to cover every one of these trivial details.
Without any guidelines to the contrary, developers will pursue flexible approaches that tend more toward option #10 than #1. Most conscientious developers will intentionally try to design some flexibility into their code, and as the example illustrates, the amount of flexibility that a good developer will put into code can vary tremendously. As my friend and colleague Hank Meuret says, the programmer ideal is to be able to change one compiler switch and compile a program as a spreadsheet instead of a word processor. When you multiply the tendency to choose flexibility rather than development speed across dozens of developers and hundreds of detailed decisions on a project, it's easy to see why some programs are vastly larger than expected and take vastly longer than expected to complete. Some studies have found up to 10-to-1 differences in the sizes of programs written to the same specification (DeMarco and Lister 1989).
If you were to proceed through implementation with the assumption that whenever you encountered an ambiguity in the specification you would tend toward the #1 end of the set of options rather than toward the #10 end, you could easily implement your whole program an order of magnitude faster than someone who took the opposite approach. If you want to leverage your product's feature set to achieve maximum development speed, you must make it clear that you want your team to tend toward #1. You must make it clear that development speed is the top design-and-implementation goal, and you must not confuse that goal by piling many other goals on top of it.
CROSS-REFERENCE
For more on goal setting, see Goal setting in Using the Top Five Motivation Factors.
People are far too casual about the effects that late changes in a project have. They underestimate the ripple effects that changes have on the project's design, code, testing, documentation, customer support, training, configuration management, personnel assignments, management and staff communications, planning and tracking, and ultimately on the schedule, budget, and product quality (Boehm 1989). When all these factors are considered, changes typically cost anywhere from 50 to 200 times less if you make them at requirements time than if you wait until construction or maintenance (Boehm and Papaccio 1988).
As I said at the beginning of the chapter, several studies have found that feature creep is the most common source of cost and schedule overruns. A study at ITT produced some interesting results in this area (Vosburgh et al. 1984). It found that projects that experienced enough change to need their specifications to be rewritten were significantly less productive than projects that didn't need to rewrite their specs. Figure 14-5 illustrates the difference.
Figure 14-5. Findings for "Changes Require Specification to Be Rewritten" factor (Vosburgh et al. 1984). Controlling changes can produce dramatic improvements in productivity, but that control does not by itself guarantee success.
As you can see in Figure 14-5, both the average and maximum productivities were higher when changes were controlled, and this study suggests that it is hardly ever possible to achieve high productivity unless you control changes. At the bottom ends of the ranges, some projects had the same low productivity regardless of whether they did a good job of controlling changes. As with other effective development practices, controlling changes is not by itself sufficient to guarantee high productivity. Even when you do a good job of controlling changes, there are other ways to torpedo a project.
CROSS-REFERENCE
For details on this point, see Effect of Mistakes on a Development Schedule, Effect of Mistakes on a Development Schedule.
Requirements that don't change are great. If you can develop software to an unchanging set of requirements, you can plan with almost 100-percent accuracy. You can design and code without wasting time to make late changes inefficiently. You can use any of the unstable-requirements practices and any of the stable-requirements practices too. The whole universe of speed-oriented development practices is open to you. Such projects are a joy to work on and a joy to manage. You can reach project completion faster and more economically than you can in any other circumstances.
That's nice work if you can get it. When you do need some flexibility, however, pretending that no changes are allowable or desirable is just a way to lose control of the change process. Here are some circumstances in which it is unwise to try to stop changes altogether.
When your customers don't know what they want. Refusing to allow changes assumes that your customers know what they want at requirements time. It assumes that you can truly know requirements at the outset, before design and coding begin. On most projects, that's not possible. Part of the software developer's job is to help customers figure out what they want, and customers often can't figure out what they want until they have working software in their hands. You can use the various incremental development practices to respond to this need.
When you want to be responsive to your customer. Even when you think your customers know what they want, you might want to keep the software flexible to keep your options open. If you follow a frozen-requirements plan, you might deliver the product on time, but you might seem unresponsive, and that can be just as bad as late delivery. If you're a contract software developer, you might need to stay flexible to stay competitive. If you're an in-house developer, your company's well-being might depend on your providing that flexibility.
In-house development organizations are especially susceptible to being unresponsive to their users. They quit looking at their users as true customers because they have an exclusive engagement. Friction results over time, and then the developers use the requirements specification as a weapon to force their users to behave. No one likes working in the face of a steady stream of arbitrary changes, but there are more constructive ways to respond than beating the users on the head with a requirements document. Developers who do that are finding with increasing frequency that their engagements aren't as exclusive as they had once thought (Yourdon 1992).
When the market is changing rapidly. In the 1960s and earlier, when business needs changed more slowly than they do today, it might have been wise to plan a product in detail two years before you released it. Today, the most successful products are often those that had the most change implemented the latest in the development cycle. Rather than automatically trying to eliminate requirements changes, the software developer's job today is to strike a balance between chaos and rigidity—rejecting low-priority changes and accepting changes that represent prudent responses to changing market conditions.
When you want to give latitude to the developers. One big change associated with the PC revolution has been that project sponsors are more willing to leave large parts of the specification to the developers' discretion (for the reasons described in the Minimal Specification section early in this chapter). If you want to leave part of the product concept to the developers, you can't freeze the product concept as soon as requirements specification is complete; you have to leave at least part of it open for the developers to interpret.
How stable your requirements are has a huge impact on how you go about software development, and particularly on what you need to do to develop rapidly. If your requirements are stable, you develop one way. If they are unstable, you develop another way. From a rapid-development point of view, one of the worst mistakes you can make is to think your requirements are stable when they aren't.
If your project doesn't have stable requirements, it isn't sufficient any more to throw up your hands and shout "Yikes! We don't have stable requirements!"—and proceed the same as you would have if you did have stable requirements. You can take certain steps to compensate for unstable requirements, and you must take those steps if you want to develop rapidly.
Because stopping changes altogether is rarely in a project's best interest, the question for most projects turns to how to manage change most effectively. Any change-management plan should aim for several goals:
Allow changes that help to produce the best possible product in the time available. Disallow all other changes.
Allow all parties that would be affected by a proposed change to assess the schedule, resource, and product impacts of the change.
Notify parties on the periphery of the project of each proposed change, its assessed impact, and whether it was accepted or rejected.
Provide an audit trail of decisions related to the product content.
The change process should be structured to perform these jobs as efficiently as possible. Here are some options for accomplishing that objective.
One change-control strategy is to try to minimize the number of changes needed. Customer-oriented requirements-gathering practices do a better job of eliciting the real requirements than traditional practices. For example, one study found that the combination of JAD and prototyping can drop creeping requirements to below 5 percent (Jones 1994). Prototyping helps to minimize changes because it strikes at what is often the root of the problem—the fact that customers don't know what they want until they see it. Throwaway prototypes are generally the most effective in this regard and provide the most resistance to requirements creep (Jones 1994).
CROSS-REFERENCE
For more on customer-oriented requirements practices, see Chapter 10, Chapter 10. For details on throwaway prototypes, see Chapter 38, Chapter 38.
In most cases, it's not the developer's or technical lead's job to say "No" to changes. But you can use the change-analysis process to screen out superfluous changes. Rather than saying "No" to each change, you provide cost and schedule impacts. Explain that you have to adjust the schedule for the time spent analyzing new feature requests. That explanation will screen out most of the frivolous change requests.
You can also screen out changes by making it harder to submit a change request. You can insist on a complete written specification of the change, a business-case analysis, a sample of the inputs and outputs that will be affected, and so on.
John Boddie tells the story of being called to the main office for an emergency schedule meeting on a rush project. When he and his team arrived, his boss asked "Is everything on schedule for delivery on the 18th?" Boddie said it was. Then the boss asked, "So we'll have the product on the 18th?" Boddie said, "No, you'll have to wait until the 19th because this meeting has taken a day from our schedule" (Boddie 1987).
In the last few weeks of a project, you might say that the minimum schedule slide for any feature change is an entire day or more. You could even say that the minimum slide for considering a feature change is an entire day or more. This is appropriate since late-project changes tend to impact all aspects of the project, often in ways that are hard to predict without careful analysis.
You would probably want to make it a little easier to get defect-related change requests accepted. But even minor defects can have far-reaching consequences, so, depending on the kind of program and the stage of the project, you might not.
One great help in saying "No" to changing the current product is being able to say "Yes" to putting those changes into some future product. Create a list of future enhancements. People should understand that features won't necessarily make it into version 2 just because they didn't make it into version 1, but you don't need to emphasize that point. What you do need to emphasize is that you're listening to people's concerns and plan to address them at the appropriate time. On a rapid-development project, the appropriate time is often "Next project."
A useful adjunct to the version-2 strategy is to create a "multi-release technology plan," which maps out a multi-year strategy for your product. That helps people to relax and see that the feature they want will be more appropriate for some later release (McCarthy 1995a).
One of the keys to users and customers agreeing to the version-2 approach is that they have some assurance that there will in fact be a version 2. If they fear that the current version will be the last version ever built, they'll try harder to put all their pet features into it. Short release cycles help to build the user's confidence that their favorite feature will eventually make it into the product. The incremental development approaches of evolutionary delivery, evolutionary prototyping, and staged delivery can help.
Formal change-control boards have proven effective against creeping requirements for large projects (Jones 1994). They can also be effective for small projects.
Structure. The change board typically consists of representatives from each party that has a stake in the product's development. Concerned parties typically include development, QA, user documentation, customer support, marketing, and management. Each party should own the area it has control over. Development should own the development schedule, and user documentation should own the user-documentation schedule. In some organizations, marketing owns the product spec; in other organizations, development or management does.
Change analysis. The change board's function is to analyze each proposed change. The change should be analyzed from each corner of the classic trade-off triangle: How will the change affect the product's schedule, cost, and features? It should also be analyzed from the point of view of each organization affected: How will it affect development, documentation, customer support, quality assurance, and marketing? If the feature request is not worth the time it takes to analyze it, then it isn't worth the time it will take to implement it, and the change board should reject the proposed change out of hand. You can also apply the preceding section's change-analysis suggestions to change boards.
Triage. In addition to analyzing each change, the change board has to accept or reject each one. Some organizations refer to this part of the change board's job as "triage," a term from emergency medicine that refers to the activity of sorting injured people into groups so that the people who will most benefit from medical treatment receive it first.
"Triage" has some connotations that are particularly appropriate to the operation of a software change board. Triage connotes that you are allocating a scarce resource and that there is not enough of the resource to go around. That's true in software. There will never be enough time or money to add every feature that everyone wants. Triage also connotes that some people will not receive aid even though they desperately need it. In software, some changes that seem as though they are desperately needed will not make it into the next release of the software. Some features will not be implemented, and some low-priority defects will not be corrected. Finally, triage also connotes that you are doing something life-critical. And when you're prioritizing change requests on a rapid-development project, you are definitely performing a job that is critical to the life of your project.
Bundling. The change board can also group small changes so that developers can handle them in bundles. A series of uncoordinated small changes can be maddeningly distracting to developers in the late stages of a project. Each one requires the overhead of a code review, documentation update, testing, checking files in and out of version control, and so on. Developers appreciate being able to handle small changes in groups rather than one at a time.
The bureaucracy issue. Change boards have been stigmatized as being overly bureaucratic. Part of the bad rap comes from ineffective change boards. Some change boards interpret their charter narrowly as saying "No" rather than as being responsible to produce the best possible product in the time available. But the fact that some change boards have been poorly conducted does not mean that the idea is flawed.
The other part of the bad rap comes from the fact that the change board's job is unpopular! If the team has done a respectable job of specifying the product, a properly functioning change board will say "No" to more feature requests than it says "Yes" to. To the people who have been told "No," that will make it seem overly bureaucratic. It might well be that the organization that complains the most about a change board is the organization that most needs to be protected from uncontrolled changes.
An effective change board guarantees that you will understand the consequences of each change before you make it. As with many other aspects of speed-oriented development practices, a change board is valuable because it helps you to make decisions with your eyes fully open to the development-speed consequences.