Why IT Projects Fail: Lack of User Involvement

One of the main reasons IT projects fail is that
users do not participate in the system development process to
the extent that they should.

You have seen the numbers put out by consultants. Some 50
percent to 75 percent of all IT projects fail to meet the three
success criteria: on time, within budget and with full functionality. One reason, although by
no means the only one, is the lack of participation in the project by those who will use the
system when it is finished.

Let’s look at the level of user involvement in a typical IT project for a new application system
in terms of the phases in the system development life cycle.

User requirements specification: Users should do most of the work with guidance on
costs and technical issues from IT.
Functional design: Users should lead this effort with some participation by IT.
Technical design: IT should lead this phase with some input from users as technical
considerations suggest or require change in functional design.
Coding: No user participation required.
Testing: Users must design the test cases, provide the test data and analyze the test
results. This is a larger effort than most people realize.
Training and documentation: While IT must do the technical documentation, user
documentation of system functionality is best done by users.
Implementation: The users must work in parallel with IT to install the inevitable new
business processes as they train the ultimate users of the system.

The issue of lack of user involvement comes up in almost every seminar I lead (100 plus and
counting). In the absence of reliable data on this topic (there is one bit of data, which I will
discuss below), I have conducted informal two-question polls of between 100 and 200 CIOs
over the past several years.

I set the stage this way: “Think about a typical application development project that is now
under way or that you have recently completed, and answer the two questions below.
Express your answer as the ratio of user work days to IT work days.” Here are the
questions and the range of answers I usually receive:

How much user time should the project have had (as a percentage of IT time)? Answers
typically range from 25 percent to 50 percent.
How much user time did the project actually get? Answers typically range from 0 percent
(“They told me to do it and then disappeared until it was done.”) to 15 percent.

In no case has any CIO said that any project received as much user time as it required. The
gap is usually closed by IT people doing the users’ work. This guarantees project failure:

To the extent that IT people specify user requirements and functional design, the new
system and its associated business processes reflect IT’s view about how the business
should be run. This is a bad idea.
If the users do not take the lead in the testing, the wrong things will be tested using the
wrong data – a guarantee of a difficult implementation and needless maintenance costs.
When IT people write user documentation, it is often unintelligible to the users; when the
users can understand it, it often does not tell them what they need to know.

The overall effect of this transfer of work from users to IT is to degrade performance with
respect to all of the key criteria of success:

Projects are late because IT has not allocated people to do the work that users should be
doing, delaying the IT work they should be doing.
Projects are over budget for the same reason.
System functionally is compromised because the IT people do not know as much about
business needs and business processes as the users know.

Depending on the nature of the project, my analysis tells me that user work time in an
application development project should be from 25 percent to 100 percent of IT time.

If this strikes you as too high, consider our collective experience with comprehensive ERP
systems a few years ago. These systems were so large that they required dedicated task
forces of users to support their development.

In some cases, there were more users on the task force than IT people. For the first time,
companies were confronted with the magnitude of user support required for major
application system development and deployment. What’s a manager to do?

If you are the CEO or COO, do not authorize any project unless the user commits in
advance to providing 50 percent of the work days budgeted for IT participation.
If you are the CIO, refuse to start a project without the user’s commitment to adequate
user participation.

Dr. Gerald Hoffman is a consultant, educator, author and all-around nice guy. With
expertise in the management of information technology, he works to help organizations
garner value from their information technology investments. An adjunct professor at
Northwestern University, Hoffman has worked with numerous companies on their
information technology management issues and has participated on a number of boards.
Feel free to visit his Web site or e-mail him at [email protected].

Copyright 2002 Gerald Hoffman Company, Inc.

http://eprairie.com/news/viewnews.asp?newsletterID=4047