IN THE REQUIREMENTS COLLEGE program that I teach, I always ask the participants—experienced analysts, project managers, product managers, applications developers, testers and quality assurance personnel—some key questions about the most significant ongoing challenges they face. Without fail, they report that managing project scope is among their most challenging issues.
The Problem of Project Scope. Fortunately, a number of useful techniques for managing scope exist. In particular, engaging customers in scope management can be one of the most effective techniques for solving this pervasive software development problem. Given the definition of project scope in Exhibit 1, the question I ask is, “At the start of application development, what amount of scope are you given by your management, customers, or stakeholders?”
In response, only one Requirements College attendee has ever answered “under 100 percent.” The others have responded with numbers that vary from 125 percent to 500 percent. The median and the average for each session is the same: approximately 200 percent. This data correlates remarkably well with the 1994 Chaos Report by the Standish Group, which discussed why projects fail. This study found that “53 percent of the projects will cost 189 percent of estimates.”
What happens when a project proceeds with a 200 percent initial scope? Two major outcomes are possible: Only half of the committed work may be accomplished, with the consequence that customers are dissatisfied, marketing and product launch promises are missed, manuals and promotional materials are inaccurate and must be reworked, and the entire team is frustrated and demotivated. Or, at deadline time, only 50 percent of each feature works. The consequences are that nothing useful works at the time the deadline passes. The deadline is missed badly. In the worst case, the entire team is fired (after working 50 percent overtime) and the nonparticipants get their ill-deserved promotions.
Exhibit 1. Project scope is the relationship between the functionality that must be delivered and the project's resources and corresponding deadlines. A scope of over 100 percent will greatly affect the quality, cost and schedule of the development project.
Exhibit 2. The baseline is an itemized set of features or requirements to be delivered in a specific version of the application. A realistic baseline is Step 1 in scope management.
The Toughest Question. Clearly, scope must be managed before and during the application development effort. However, given the facts above, the task is daunting. For the average project to have any hope of success it will be necessary to reduce its scope by a factor of two.
This leads to perhaps the toughest question faced by application developers: “How does one manage to reduce scope and keep the customer happy?”
Engaging Customers to Manage Their Project Scope. Reducing project scope to at least within shouting distance of available resources and time has the potential to create an adversarial relationship between the application development community and our customers, whose needs we must meet. But it doesn't have to be that way. We can actively engage our customers in managing their requirements, and their project scope, to assure quality and timeliness of the software outcomes.
This conclusion is based on two critical insights: (1) It is in our customer's best financial interests to meet its external commitments to its marketplace. Therefore, delivering a high-quality, and if necessary, a scope-reduced application, on time and on budget is the highest overall benefit that we developers can provide. (2) The application, its key features, and the business needs that it fulfills all belong to the customer, rather than the application development team.
Developing the Baseline. The first step in scope management is to create a requirements baseline. A requirements baseline is simply an itemized set of requirements or features that is intended to be delivered in a specific version of the application, as in Exhibit 2.
Establishing the baseline for the project is a requirements elicitation effort. We must understand the features and specifications that are necessary for the application to meet our customer's needs. Techniques for requirements elicitation can include interviewing, questionnaires, requirements workshops, story-boards, role playing, use cases, quality function deployment, and prototyping.
The choice of technique will vary based on the nature of the application, the skill and sophistication of the development team, and the customer. The result is the set of items that must be delivered to satisfy the customer. An additional benefit of the process is that we show customers that it is important to us to understand their needs, that we are deeply committed to the application, and that we manage the development process in a professional manner.
An effective elicitation process will determine not only what the application must do, but will also establish relative priorities of the features. Techniques for “triaging” the feature set include cumulative voting, wherein the stakeholders are allotted a certain number of virtual dollars with which they can “buy” those features that are most crucial to success, or ranking priorities in categories such as critical, relevant, important or useful (see Exhibit 3). In the latter case, the process must permit only an equal number of votes of each priority type or the result will quickly tend toward everything being critical.
Reducing Scope. The next step is the trickiest. If, as we expect, the features add up to 200 percent scope, then we must chop the baseline in half or more. Communicating this to customers requires both negotiation skills and a total commitment to the schedule. The guiding principle in these negotiations should be “underpromise and overdeliver.” With scope negotiated to an achievable level, and with development focused almost exclusively on the customer's “must haves,” the team will establish credibility by meeting schedules with quality, and occasionally with utility, that could not be committed to before.
Manageable Threats. Failure to provide sufficient margin for error, feature creep, and extreme work cultures in which even attempting to negotiate scope is considered career limiting are difficult but manageable threats to project success. Successful development managers create margin for error in estimating effort and allow for time to incorporate legitimate change during the development cycle. Effective managers also resist feature creep, which author Gerald Weinberg notes can increase scope by as much as 50 percent after the start of a project (“Just Say No! Improving the Requirements Process,” American Programmer, Oct., 1995). Even hostile political environments can be mitigated by focusing the development effort on the customer's critical priorities. At deadline time, at least the most important features will be working reliably.
Exhibit 3. Customer benefit, project risk, and level of effort can be prioritized by feature so that the elements of the product that are most critical to the customer can be surfaced.
Change Happens. Even in the best of scope managed processes, change is inevitable. The reasons for change may be because we failed to ask the right people the right questions at the right time; the problem being solved or our understanding of the problem being solved changed; the users or customers changed their minds or their perceptions; the external environment changed; or we failed to create a process to help manage change.
While the potential for change in even a well-managed process can be discouraging, the point is to simply “get over it” and move on with a process for managing change. This process engages the customer in helping control change, or supporting the necessary change with an increased budget or an officially changed project timeline.
One mechanism for controlling change may be as simple as a Change Control Board (CCB). A Change Control Board is a committee of team members responsible for analyzing and approving appropriate change before it is incorporated into the project baseline. Alternately, the baseline is owned by a project champion who will defend the application, and its associated schedule and budget, against unnecessary change. Either technique creates what Weinberg calls an “official channel,” through which all change is funneled to assure project success. The response of the project team to a request for change is a professional “can do attitude,” followed by a similarly professional request for funding, schedule extension, or elimination of some element of the project baseline that is of less importance than the new item.
Of course, your customer should chair the CCB or help the project champion evaluate change proposals. After all, it's their feature, their budget, and their schedule. Our job is to help them make the trade-offs inherent in all projects. By so doing, we move the problem of managing scope to their doorstep, rather than our own.
WE CANNOT EXPECT that this process will make the scope challenge go away any more than any other single process will solve the problems of the application development world. However, the steps outlined above can be expected to have a material effect on the scope of the problem, allowing application developers to focus on critical subsets and to incrementally deliver high-quality systems that meet or exceed the expectations of the user. Further, engaging the customer in helping solve the scope management problem increases commitment on the part of both parties, and fosters improved communication and trust between the customer and application development teams. The result will be higher-quality applications, on time and on budget. 
I Dean Leffingwel is a vice president of Rational Software Corporation and is general manager of the Requirements Management business unit, formed when Rational acquired Requisite, Inc., of which Leffingwell was co-founder. He is an author and frequent speaker on requirements management and software quality.
