As with any professional activity, meeting commitments in application development involves making realistic assessments of project resources, time lines, and objectives before the activity begins. For software development, these factors combine to create the "scope" of the project. Project scope is a function of:
The functionality that must be delivered to meet the user's needs
The resources available to the project
The time available in which to achieve the implementation
Figure 19-1 provides a perspective of the "box" we can use to represent project scope.
In Figure 19-1, the area of the box represents the achievable scope of the project. Project scope derives from the following elements:
Resources, consisting primarily of the labor from developers, testers, tech writers, quality assurance personnel, and others.
As early as the 1970s, Fred Brooks (1975) had demonstrated that adding resources to a software project in order to increase the work output is a risky proposition at best. Indeed, Brooks' law states that adding labor to a late software project makes it even later.
OK, if the time scale is long enough, work output can indeed go up, but it will not go up proportionally to the resources added, and the overall efficiency of the project thereby decreases. Adding resources may even slow a project because the need for training and supporting the new people decreases the productivity of those already on the project. As the competitive marketplace forces us to shorten our time lines, adding resources during a project becomes less and less practical. In addition, as development budgets are stretched and real years become Internet years, adding resources is simply not an option in many environments.
For the purpose of analyzing scope, let's assume that resources, on the y-axis of Figure 19-1, are constant over the duration of the project.
Time, perhaps here we have a "soft" boundary that is subject to change if the available resources are inadequate to achieve the desired functionality. For purposes of our scope analysis, time on the x-axis, is a fixed factor.
Certainly, history would demonstrate that delivering software late is typically "par for the course." On the other hand, many applications have hard, fixed deadlines. Examples include a new tax program to be delivered in time for tax season, a new-product introduction timed for a trade show, or a contractually fixed customer deadline. In addition, if as a profession we want to ensure our credibility and to gain the confidence of our customers, it is important that we not slip the schedule for a change.
The total functionality we can deliver is obviously limited to the available time (fixed) and the available resources (also fixed) we have to apply, so the achievable scope is the area of the box.
In this book, we have used the notion of "features" to represent the value-added functionality we must deliver to the user. If the effort required to implement the features required by the system is equal to the resources over the time we have available, the scope of the project is achievable, and we have no problem. Barring unforeseen circumstances, the software team will deliver on time without sacrificing quality.
However, experience has shown that there is often a poor match between these factors in the scope equation. Indeed, in requirements classes that we teach, we always ask: "At the start of the project, what amount of scope are you typically given by your management, customers, or stakeholders? " In response, only a few trainees have 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 tend towards the same conclusion: approximately 200 percent. This data correlates remarkably well with the Standish Group finding stated earlier, namely, that more than half of all projects will cost close to double their estimates. Perhaps we now understand why.
What happens when a project proceeds with a 200 percent initial scope?
If the features of the application were completely independent, which is unlikely, only half of them will be working when the deadline passes. The product is limping but provides only half of the intended utility. And it's not a holistic half. The features don't work together, and they don't produce any useful aggregate functionality. A drastically reduced-scope application is quickly patched together and shipped. Consequences include seriously unhappy customers whose expectations have not been met, marketing commitments that have been missed, and inaccurate manuals and promotional materials that must be quickly reworked. The entire team is frustrated and demotivated.
At deadline time, only 50 percent of each feature works. Moreover, since there are certainly interdependencies within those features, in this even more typical case, nothing useful works when the deadline passes. The deadline is missed badly. All commitments are missed; a new deadline is scheduled, and a new death march often begins. In the worst case, the entire team is fired, after working overtime for months on end; the final "phase" of this first attempt at the project, the phase called "promotion of the nonparticipants," is declared, and a new manager is added to the project.
What happens to software quality during either of these outcomes? The code, which is rushed to completion near the end, is poorly designed and bug-ridden; testing is reduced to an absolute minimum or skipped entirely; and documentation and help systems are eliminated. Customers take on both the testing and the quality assurance functions. Soon, the customers react to our extraordinary efforts as follows: "Although we were initially disappointed by how late you were (or how little is working compared to our expectations), now we are really unhappy because we just discovered that what you shipped us is junk."
Clearly, in order for the project team to have any hope of success, scope must be managed before and during the development effort. Given the typical scenario, however, the task is daunting: For if we truly begin the development effort with an expectation of 200 percent scope, it will be necessary to reduce the project scope by as much as a factor of 2 in order to have any chance of success.
The team's dilemma in addressing this problem leads to perhaps the toughest question faced by the team: How does one manage to reduce scope and keep the customers happy? Well, all is not lost. We'll cover ways of dealing with this issue in the next two chapters.
[1] Many students have commented that it is management that signed up, often committing them before they volunteered!