Steve McConnell Text Banner
 

 

Best Practices
IEEE Software, Vol. 15, No. 3, May/June 1998

Feasibility Studies

When is a cancelled project bad? After surveying about 8000 IT projects, the Standish Group reported that about 30 percent of all projects were cancelled ("Charting the Seas of Information Technology," Dennis, MA: The Standish Group, 1994). Capers Jones reports that the average canceled project in the U.S. is about a year behind schedule and 200 percent of its expected budget by the time it’s cancelled (Assessment and Control of Software Risks, Englewood Cliffs, N.J.: Yourdon Press, 1994). Jones estimates that work on cancelled projects makes up as much as 15 percent of total U.S. software efforts, amounting to as much as $14 billion per year in 1993 dollars.

In spite of these grim statistics, canceling a project is, in itself, neither good nor bad. Canceling a project later than necessary is bad. The trick is to perform the minimum amount of work necessary early in a project to determine that the project should be cancelled.

Press Cancel to Exit or OK to Continue

How do you cancel a project early? The standard means is by conducting a feasibility study early in the project to determine whether the full-scale project is workable. The project team prepares a set of feasibility study materials. The culmination of the feasibility study is a feasibility review, at which the project team, customer, or upper management make a go/no go decision about the rest of the project. The feasibility review usually involves a review meeting, but sometimes the project team simply distributes a packet of feasibility study materials for individual examination. The information needed to support the feasibility review can usually be developed by the time the project is 10-20 percent complete.

Feasibility studies are a time-tested practice, but they aren’t used very much. A KPMG survey found that 84 percent of companies that had had runaway projects proposed to use feasibility studies as one means of preventing future problems ("Runaway Projects—Cause and Effect," Software World, vol. 26, no. 3, 1995). This survey suggests that these companies hadn’t performed feasibility analyses in their runaway projects. (If they had performed them in the past, why would they expect performing them in the future to make any difference?)

One of the reasons feasibility studies aren’t used very often might be the "feasibility study" term itself. That term conjures up questions of technical feasibility, and for those of us working in mainstream languages on mainstream computers, questions of technical feasibility never really enter our minds. If we know our project is technically feasible, the thinking goes, why would we need to conduct a feasibility study?

For a few projects, technical feasibility is a significant concern: Is it technically feasible to build a Star Wars missile defense system? Is it technically feasible to build a natural language English-to-French translator? For most projects, however, feasibility depends on non-technical issues: Are the project’s cost and schedule assumptions realistic? Does the project have an effective executive sponsor? Does the company have a business case for the software when the real cost—rather than the initial blue-sky, wishful-thinking cost—is considered?

Work During the Feasibility Study

During the feasibility study, the project team should create the following materials:

  • Clear commitment from the project’s key decision maker or executive sponsor
  • Vision statement for the project
  • Business case for the software
  • Original effort and schedule targets
  • Current effort and schedule estimates
  • List of top risks to the project and plans to manage each risk
  • Detailed user interface prototype, if the system has a significant user interface element
  • Requirements specification
  • Software quality assurance plan
  • Detailed software development plan

Creation of each of these materials addresses one or more significant project hazards. Poor requirements, lack of effective executive sponsorship, and inadequate planning were all cited as major causes of project failure by the Standish Group survey.

If the project team can’t prepare these materials for the feasibility study, you shouldn’t hold the review meeting because you won’t have enough information to determine the project’s viability. If the project team tries to create these materials and repeatedly fails to do so, you should assume that the project is somehow being prevented from preparing for success and faces a great risk of cancellation downstream.

The amount of calendar time required to create these materials depends mostly on how much work is needed to identify the software’s requirements. If end users know exactly what software they want built, this period might take only 10 percent of the software’s total development schedule. In more typical cases, it might take 10 to 20 percent of the total development schedule. On some projects, the hardest part of the software development job is helping the end users figure out what they want built, and so occasionally this part of the project can take 25 percent of the total development schedule or more. The initial funding request and plans for the Feasibility Review should take this variability into account.

Agenda of the Feasibility Review

The feasibility review should focus on the following questions:

  • Is the product concept viable?
  • Will it be possible to develop a product that matches the project’s vision statement?
  • What are the current estimated cost of and schedule for completing the project?
  • How big is the gap between the original cost and schedule targets and current estimates?
  • Is the business case for the software justified when the current cost and schedule estimates are considered?
  • Have the major risks to the project been identified, and can they be surmounted?
  • Is the requirements specification complete and stable enough to support remaining development work?
  • Have users and developers been able to agree on a detailed user interface prototype? If not, are the requirements really stable?
  • Is the software development plan complete and adequate to support further development work?

The work done during the first 10-20 percent of the project should be sufficient to answer these questions, which will give the client or top management enough information to decide whether to fund the rest of the project.

Major Benefits of the Feasibility Study

Breaking a software project into a feasibility study phase and a main development phase helps software organizations in at least three ways.

First, some people view any canceled project as a failure, but a project canceled at the 10-20 percent complete point should be considered a clear success. Canceling one project that ultimately goes nowhere after it is 10-20 percent instead of 80-90 percent complete (or as Jones points out, 200 percent complete) can pay for the exploratory phases of a lot of other projects.

Second, a feasibility study sets up a project manager to make more accurate funding requests than average. The project manager first requests funding for the feasibility study phase, during which the first 10-20 percent of the project is completed. After the feasibility study materials have been reviewed and the people holding the project’s purse strings have made a "go" decision, the manager requests funding for the remainder of the project. At this point there will still be a large potential variation in project cost, but the exploratory work will reduce the cost variation from a factor of 4 either way to more like ± 50 percent (Barry Boehm, et al, "Cost Models for Future Software Life Cycle Processes: COCOMO 2.0," Annals of Software Engineering, Special Volume on Software Process and Product Measurement, J.D. Arthur and S.M. Henry Eds., Amsterdam: J.C. Baltzer AG, Science Publishers, 1995).

Finally, requiring the project manager to complete 10-20 percent of a project before requesting funding for the rest of it forces a focus on upstream activities that are critical to a project’s success. These activities are often abbreviated or ignored, and the damaging consequences of such neglect don’t otherwise become apparent until late in the project. If the project team is required to complete the most important upstream work before proceeding with downstream work, overall project risk can be substantially reduced.

Editor: Steve McConnell, Construx Software, 11820 Northup Way #E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com - WWW: http://www.construx.com/stevemcc/

Email me at stevemcc@construx.com.