Read more stories about
Funding and Building your Business >>

MATR Sponsor:

MATR Supporters:

Why IT Projects Fail: Lack of User Involvement

August 8, 2002View for printing

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

Copyright 2002 Gerald Hoffman Company, Inc. ... tterID=4047
No reader comments so far. Be the first to comment by clicking the button below.

Reprinted under the Fair Use doctrine of international copyright law. Full copyright retained by the original publication. In accordance with Title 17 U.S.C. Section 107, this material is distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes.

E-mail this page to a friend!