Variable Scope
When the requirements for a software development project are allowed to vary, your best strategy is to work in short, time-boxed iterations delivering working software on a regular basis. Working software provides concrete feedback to your stakeholders, enabling them to determine whether what you have built meets their needs, and if not, to direct you accordingly. A common agile strategy—found in methods such as Extreme Programming (XP), Scrum, and Agile Modeling—is to work on requirements in priority order as defined by your stakeholders and to allow stakeholders to change the requirements as the project progresses. Working in priority order enables you to maximize the return on investment (ROI) as defined by your stakeholders yet remain flexible enough to build software that meets their actual needs. Figure 2 shows the OpenUP's (www.eclipse.org/epf) strategy for treating all work items, including requirements, in this manner. It adopts Agile Modeling's strategy of "Model a Bit Ahead" when you have complex work items to address in the near team, enabling you to increase your team's velocity by paving the ground ahead of it.
A common problem with allowing requirements to change throughout a project is that stakeholders will try to motivate you to do more than you actually can in an iteration, putting you at risk. If you actually have the time to implement the feature then by all means do so, but if not then either ask them to wait until a coming iteration or to remove an equivalent amount of work from the current iteration. An analogy that I like to use is a shopping cart. If you have $50 to spend and you've already filled up your shopping cart with $50 of stuff, to add a $4 bag of cookies into your cart you need to remove at least $4 worth of existing food. Stakeholders understand this comparison, and once they see that you deliver working software each iteration, they quickly recognize that they eventually will get the functionality that they want.
The implications of fixing the scope early in a project can prove to be quite dire. People are not very good at defining what they want up front, so no matter how good your business analysts are, it's incredibly unlikely that you'll write an accurate, detailed requirements specification at the beginning of the project. Even if you could get the requirements right, they're going to change anyway based on changes in the marketplace, decisions by senior management, regulatory changes, and so on. The earlier your requirements are "firmed up," the greater the risk of building something that your stakeholders don't actually want. My April 2007 newsletter entitled The Dire Consequences of Fixed-Price IT Projects (6) explored these problems in greater detail.
