The Problem of Project Scope

   

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 18-1 provides a perspective of the "box" we can use to represent project scope.

Figure 18-1. Project scope

graphics/18fig01.gif

In Figure 18-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, Brooks [1975] 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 proportionate 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 18-1, are constant over the duration of the project.

  • Time, perhaps a "soft" boundary that is subject to change if the available resources are inadequate to achieve the desired functionality.

    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 gain the confidence of our customers, it is important that we not slip the schedule.

So, for purposes of scope analysis, we'll treat time as a fixed factor. The total functionality we can deliver is obviously limited by 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 system features is equal to the resources available during the scheduled time, the project has an achievable scope, 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 toward 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.

A Short Story on Project Scope

We once had a student who had recently moved into a new role as product manager for a new software product. Her background included many aspects of product development and product marketing, but she had no direct experience in software development. After hearing the responses to our question about scope, she appeared incredulous. She looked around the room and said, "Do you people really mean to tell me that you routinely sign up for approximately two times the amount of work that can reasonably be accomplished in the available time period? [1] What kind of profession is this? Are you people crazy?" The developers looked at one another sheepishly and by consensus answered, "Yup."

[1] Many students have commented that it is management that signed them up, often committing them before they volunteered!

What happens when a project proceeds with a 200 percent initial scope?

  • If the intended 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. An application with drastically reduced scope must be 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.

  • If some of the application features do depend on others, at deadline time nothing useful will work. 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 ."

   


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
EAN: N/A
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net