Information System Management
ISSN: 0739-9014 (Print) (Online) Journal homepage: https://www.tandfonline.com/loi/uism19
Why Systems Development Projects Fail
Stephen P. Keider
To cite this article: Stephen P. Keider (1984) Why Systems Development Projects Fail,
Information System Management, 1:3, 33-38, DOI: 10.1080/07399019408963043
To link to this article: https://doi.org/10.1080/07399019408963043
Published online: 30 May 2007.
Submit your article to this journal
Article views: 160
View related articles
Citing articles: 1 View citing articles
Full Terms & Conditions of access and use can be found at
https://www.tandfonline.com/action/journalInformation?journalCode=uism20
Why Systems
Development Projects
Fail
Stephen P. Keider
Most systems projects fail because such basic management principles as planning and
control are violated. This article discusses the management and mismanagement of projects,
pointing out signs of impending project failure. Measures the project manager can take to
minimize the risks of failure are also included.
A successful project is one that produces a usereffective system on time and within budget. It is
critical to realize, however, that targeted dates,
costs, and specifications are subject to change
as a project progresses. These factors should
not be changed unilaterally, however, because
the proposal to build an information system is,
in essence, a contract between MIS and the use r ( ~ )As
. with any contract, both parties must
agree to change the scope of the agreement.
thus meet the scheduled target date, budget,
and specifications.
.
Change the specifications and retain the original target date and budget.
Change the specifications in conjunction with
the user and, if the change dictates, modify
the target date and budget.
The first alternative will lead to production
of the wrong system. The second alternative is
system the user determines that the original de- problematic because the target date and/or
sign specifications must be radically changed for budget will probably be overrun. The last alterthe system to function properly, the project native, however, could foster a success.fu1
leader can do one of several things:
project, even though the original targets are not
Continue to build the original system and achieved. Thus, failure results not when target
figures are changed, but when they are
changed unilaterally. Failure to realize that a
schedule or budget change should usually acStephen P. Keider is vice-president of administration and company a specifications change is a major facplanning, Computer Task Group Inc. Buffalo.
tor contributing to project failure.
If during the development of a complex
JOURNfIL OF INK)RNATICfl SYSTEMS MANffiCMCllT
Criteria for Project Success
complishing these objectives. Too often,
The term on time implies that a date (i.e., the however, a system is initiated and system obtarget date for implementing the new system) jectives specified by MIS without the concurrence of the user. When this occurs, there is
must be met. Bringing a project in on time reusually little communication between MIS and
quires meeting a series of milestone dates. Bethe
user community, and the resultant system
cause missed deadlines have a cascading effect
leaves the user frustrated.
throughout a project, it is virtually impossible to
miss every milestone date yet still meet the
Developing Time and Cost Estimates.
project completion date. Some aspect of the
Several key estimates must be made in the
project-probably the cost, quality, or user project life cycle. One is part of the feasibility
satisfaction-will suffer.
study, another should be developed when the
User effectiveness is the most difficult suc- work plan is written, and others should accomcess criterion to measure. It is, nonetheless, the pany the status reports. New estimates should
only lasting measure of success. In attempting be developed whenever specifications change.
to assess user effectiveness, the following areas
The reader may question the need to reesshould be considered:
timate a project for the work plan when this esEconomic effectiveness. If the system saves timate immediately follows the feasibility study.
more-both
tangible and intangible However, between completion of the feasibility
savings-than it costs to run, it is economi- study and formulation of the work plan, several
cally effective. This implies, of course, that a things could happen: the scope of the project
measure of performance (cost justification) may be redefined, the availability of resources
exists for the system to be developed. In ad- may change, the cost of equipment and/or
dition, intangible benefits can be quantified; personnel may increase and, in general, more
"more control," for example, can usually be thought may be given to the new system. Alrelated to some standard in the targeted though it is difficult to comprehend that a
project could progress through feasibility, imindustry.
plementation, and modification with no
0 Technical effectiveness. If the state of data changes in estimated time or budget, it happens
processing technology enhances (rather all the time!
than inhibits) the use of a new system, it can
be considered technically effective. For ex- Development of the Work Plan. A project
ample, distributed data processing and vari- work plan is a written definition of who is to do
ous computer utilities are currently possible what, when, and how. When the work plan is
because the telecommunications technology written, the project leader is assigned, the team
assembled (or planned), tasks defined, mileexists to support the concepts.
stones established, and reporting procedures
Operational effectiveness. If the users can. clarified. Without these activities, there can be
understand and work with the system, it can no project management.
be considered operationally effective. If the
system, however, is designed for MIS rather User Acceptance of Functional Specifics-.
than user personnel, operational effective- tions. This is the most crucial fault line in the
ness will probably be minimal.
project life cycle. Because the user ultimately
determines the success or failure of any system,
Life Cycle "Fault Lines"
the user should be heavilv involved in the deThe project life cycle includes numerous dis- velopment of system design documents. Orcrete tasks. Six of these are crucial to the suc- ganizations have found that the most successful
cess of a project; if a project is going to fail, it is systems are developed with a high degree of
highly probable that it will do so because one of user interaction during the design phase. It is
extremely important that all screens, reports,
these tasks is mismanaged.
and manual procedures be clearly defined and
Defining System Objectives. In a success- understood by the user before system design
ful project, the user agrees with the system ob- and coding begins. The most important single
jectives, and management is committed to ac- reason for project failure is that this task usually
d
Why Systems Development Projects Fail
coincides with project completion, as opposed
to early in the life cycle.
world, government, economy, and technology
are continually changing, often causing user
needs to change. The key to success is to ideritify required changes early a n d adjust the
schedule and budget accordingly. It is an insult
to a user's intelligence to report that a project is
98 percent complete one week and the next
week report that a 300 percent overrun and sixmonth slippage will occur.
System Testing. System tests usually include
unit testing, string testing, and a limited system
testing. Recognizing the difficulty of testing all
system variations (especially an online system),
the manager should consider a testing methodology and automated testing tools. Inadequate
system testing can cause user dissatisfaction
and a considerably prolonged and costly main- Overemphasis on How a System Will B e
tenance period. It can also create a system with Built. If the project manager describes how
so many "fixes" that maintenance is virtually the system will be built by emphasizing such facimpossible, and a total system rewrite is the tors as the equipment, operating system, data
base, and communications monitor, the project
only practical alternative.
could be destined for failure. If the emphasis,
System Turnover. The turnover of a new however, is on the organization of the project
system should not come as a surprise to the us- team, communication with the user, and the
e r ( ~ )Rather,
.
implementation should be carried nature of the application, the project is a good
out in phases (i.e., a formal announcement and candidate for success.
some user training should occur before the new
Premature Programming. If programming
system is completely ready).
begins before the final design specifications are
agreed upon, either the wrong system will be
Early Danger Signs
built or much of the c o d e will have to be
Projects that fail usually start to fail very early. rewritten.
Numerous signs, however, can alert manageStaff Reassignments. Plans for personnel
ment to this possibility.
turnover or reassignment should always be
Inadequate Status Reporting. W h e n made, particularly in a large project. Turnovtrr
project managers are "too busy" to review in the DP industry exceeds 30 percent. If there
projects with their managers, or if vague, un- is no contingency in the estimate for turnover,
quantifiable status reports are submitted, a po- the schedule and budget should be adjusted to
tential problem exists. This also applies to re- reflect turnover as it occurs.
ports that estimate work t o be completed,
without summarizing what work has been ac- Monolithic Achievement. When a project
complished and what remains to be done.
manager begins to refer to the system not as a
set of programs but as a monument that people
Isolationism. Every MIS department has rewill revere through the ages, the project is desusable techniques and information that can
tined to fail. This kind of reference emphasizes
help in building new systems. Successful project
such aspects as the generality of the system, the
managers seek this information, talk with peocomplexity of the system, the all-encompassing
ple from whom they can learn, frequently comnature of the system, the custom-built data base
municate with their managers, a n d use the
handler, and communications interface. In inmost helpful tools and methods available. They
formation systems, where the professional is olare available to users and to members of the
ten married to the industry rather than the comMIS department throughout the project. Unsuc- pany,
this kind of attitude can seriously
cessful project managers, on the other hand,
threaten the success of project.
are "phantoms": they are usually unavailable
and, in general, isolated from those with whom
Excuses for Failure
they should be working.
A critique of unsuccessful projects uncovers
Lack of Schedule Changes. The system some commonly cited excuses for failure:
project that undergoes no schedule changes
"The specifications changed. " Regardless of
until it is 95 percent complete will probably althe degree of project complexity, all projec:t
ways be 95 percent complete. The business
-
specifications change to some degree. What
the project manager is really implying is:
the importance of making the system
work.
The front-end analysis was inadequate.
For lack of a valid reason for the project
falling behind schedule except for poor
management, the project manager scapegoats the vendor.
The project estimate was incorrect.
The work plan was incomplete or nonexistent.
The user never had the opportunity to review the functional specifications.
The actual impact of budget or schedule
changes was never anticipated.
0 "The users did not know what they wanted." This is a classic excuse; it is an attempt
to justify poor project implementation. What
actually might have happened was:
The users were never asked what was
needed.
MIS decided to do the project because it
was of interest to them.
Communications between MIS and the
user were inadequate throughout the
project.
0 "Lack o f machine time hampered development." With the abundance of computer
power available and the accessibility of terminals and minicomputers for development,
this excuse is becoming less plausible. What
is often the case is:
The project manager did not plan well for
test time and was caught in the machine
crunch at year-end closing, or
\
"We built a Cadiflacand all they wanted was.
a Vofkswagen." .This is a common excuse
often applied to the first-time user or to the
user who is attempting to operate the system
with inadequately trained staff. What is really implied is that the project manager:
Never asked the user what was needed.
Was more interested in what was learned
and implemented than with the usability
of the system by the user.
Believes that the company exists to serve
MIS, not vice versa.
0 "We were given a poor estimate." This is a
good excuse when all else fails; however, it
is good only once during the project life cycle. When it is used, it should be met with
the response, "Well, what is your estimate?"
This invalidates the excuse for the next time.
What this excuse might really mean is:
The project manager did not estimate or
plan the project.
The project manager did not track or
manage the project; otherwise, he or she
could have identified a n inaccurate
estimate.
The project manager failed to look for
such avenues as scheduling night shift or
weekends and using a service bureau to
address this problem.
"The slippage is the result o f a high turnover
rate." Obviously, staff turnover will affect a
project. What the project manager is implying, however,. is a n uncertainty over
whether:
0 "The vendor slipped on equipment and soft-
This is a poor project because people are
leaving, or
ware delivery." This was an excellent excuse in lg65 when CPU and Operating system architectures were in their infancy. The
current reality, however, is more likely one
of the following:
.The project manager presumed the vendor's promised date would be the
delivery date.
In the excitement of working with a new
machine, the project manager overlooked
people are leaving
project.
because this is a poor
Why Projects Really Fail
During the preparation of this article, 100 MIS
professionals were questioned; 67 were MIS
managers and 33.were programmers, designers, and analysts. They were all asked which
Why Systems Development Projects Fail
single reason c a u s e d t h e most failures in
projects in which they had participated and to
respond candidly without assigning blame or
defending their own failures. (They were not
given a structured questionnaire.) The results of
the survey are as follows:
No. of
Reason for Failure
Responses
Lack of project plan
Inadequate definition of the project
scope
Lack of communication with the
end user(s)
lnsufficient personnel resources and
associated training
Lack of communication within the
project team
Inaccurate estimate
Miscellaneous
23
22
14
11
8
late data in the reports provided to get the information they did need.
The lack of meaningful reviews can result
from the lack of a project plan: it is difficult to
review something without a standard to measure against. In a poorly managed project, the
reviews, if they exist at all, are meaningless.
They consist of clich6s and subjective information and stress form rather than substance.
Lack of anticipation is also a problem. A
competent project manager will anticipate potential problems and address them before they
become critical. Many projects that fail are led
by project managers who have not learned this
skill.
Lack of courage in this context is similar to
lack of anticipation. Even when a project is going well, at some point a dramatic change may
Although some projects fail because of technol- be necessary to ensure continued success. The
ogy or design problems, all of the above rea- change could entail replacing a team member,
sons are within the control of the project changing the project s c o p e , changing the
equipment configuration, o r changing the
manager.
schedule or budget. Regardless of the nature of
Further discussions and post-project re- the change, the competent project manager will
views of numerous unsuccessful projects re- anticipate it and have the courage to implement
it. Many projects doomed to failure progress
vealed some common reasons for failure.
from planning through implementation because
Lack of a project plan caused team mem- no one had the courage to ask "Why are we
bers to be unclear about their responsibilities. doing this?" .
The lack of milestones created a casual attitude
The NIH syndrome, or the "not invented
toward completion of the project. Work was ofhere"
attitude, is almost unique to the MIS inten redone because it had not followed a logical
dustry
and is a costly attitude. The belief that
progression, and time was lost as project memsoftware.components
that are not developed in
bers awaited new task assignments. In addition,
house
are
not
good
enough
frequently resi~lts
the priority of project tasks did not correspond
in
reinvention
of
the
wheel.
This
attitude also
to the importance of the function but rather to
(i.e.,
unsucleads
to
excessive
maintenance
when the task occurred in the project: portions
cessful,
costly
systems).
done early were overdesigned; those done late
were done perfunctorily. Furthermore, probLack of a change control mechanism is a
lems and conflicts were difficult to resolve be- shortcoming in development methodology. A
cause no one was assigned to a project manag- procedure for modifying of systems specificaer role.
tions must be addressed and communicated to
the user as part of the project plan.
In adequate definition of project scope
Lack of skilled resources and/or training
caused gaps in new systems and excessive
maintenance requirements. Systems were diffi- for analysts, designers, or programmers on a
cult to maintain because they were not de- project will usually have one of two effects: the
signed and built, but rather grew without real project will be a complete failure, or the project
planning. Systems tests were lengthy because will miss time and cost targets while the personevery time a report was submitted to the user nel acquire a new set of skills. Many training
for approval, changes were required. In addi- aids are available to MIS personnel. Failure oction, many of the functions implemented were curs not because the MIS personnel are unnot needed, yet users had to manually manipu- skilled but because nothing is done to improve
8
14
'
JOURIWL Of INK3RMATION SYSTEMS MANffi€N€NT
the level of expertise. At a minimum, the impact of this lack should be considered in developing project schedules and budgets.
Conclusion
This article has addressed reasons for project
failure; the presentation would be incomplete,
however, if recommendations for preventing
failure were not addressed. Although hundreds
of tools and techniques can assist the project
manager, only a handful can make the difference between project success and failure.
Prepare a written project plan-This should
address not only the scope of the project but
how the system is to be built.
project control procedures, and regular
reporting.
Review projects regularly and in depthProject reviews should be both written and
oral and, by nature, quantitative (e.g., there
are X programs; they require Y hours and 2
people; completion is scheduled for N date;
S dollars should be budgeted.
Cause change through courageousdecisions.
Maintain perspective-Not all projects require the same degree of planning, reporting, and control.
Have third-party reviews-It is sometimes
difficult for MIS professionals to admit ignorance or failure to their manager, peers, or
subordinates. Consider the use of an outside
organization to review project status.
Organize properly-Select the project team
based not on who is available but on who is
Although some projects fail because of
the best talent available to perform each task. technological or design problems, most of the
Delegate-The job of the project manager is reasons for project failure indicate a lack of
primarily to manage; execution of activities basic understanding of project management.
Project management should include planning
should be delegated to the project team.
(first and foremost) organizing, delegating, deciAnticipate problems-Anticipate both the sion making, executing, reporting, and controlling. Furthermore, projects do not fail; ~ e o p l e
short- and long-range effects of decisions.
(usually project managers) fail, and the failure is
Select a methodology for systems most often caused by ignoring the ABCs of
development-This should at least include good management-Anticipation, Brains, and
standards, documentation, conventions, Courage.