IEEE Software, Vol. 15, No. 3, May/June 1998
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
its 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 arent
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 ProjectsCause and Effect," Software World, vol. 26, no. 3,
1995). This survey suggests that these companies hadnt 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 arent 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 projects 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 costrather than the
initial blue-sky, wishful-thinking costis considered?
Work During the Feasibility Study
During the feasibility study, the project team should create the
- Clear commitment from the projects 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
- 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
If the project team cant prepare these materials for the
feasibility study, you shouldnt hold the review meeting because you wont have
enough information to determine the projects 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
The amount of calendar time required to create these materials depends
mostly on how much work is needed to identify the softwares requirements. If end
users know exactly what software they want built, this period might take only 10 percent
of the softwares 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 projects vision
- 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
- 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
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
projects 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 projects success. These activities are often abbreviated or ignored,
and the damaging consequences of such neglect dont 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
Editor: Steve McConnell, Construx Software, 11820 Northup
#E200, Bellevue, WA 98005.
E-mail: firstname.lastname@example.org - WWW: http://www.construx.com/stevemcc/