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 expectedbudget 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 aproject 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 teamprepares 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—Causeand 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 termconjures 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 technicallyfeasible 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—ratherthan 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 scheduleestimates
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
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...