In his article for webpronews.com, Dr. Gerald M. Hoffman highlights that there are three key points for an IT project to suceed.
Those three criterias are:
1. it must be completed on time,
2. it must be completed within budget, and
3. it must provide the full functionality originally promised.
The IT profession has been conducting IT projects for over thirty years. Yet about 75% of all IT projects fail to meet one or more of these criteria. Why? The reasons IT projects fail are listed below, more or less in the order of frequency of occurrence:
1. Inadequate or inaccurate specifications
2. Changing specifications
3. Insufficient user support
4. Bad estimates of required resources
5. Technical failure
6. Bad management of the project
At first glance it seems that if in IT project fails, it is the fault of the IT department and the IT people. Without question this is true some of the time. Technical failure is clearly an IT failure most of the time. (Sometimes IT is forced to use questionable technology by the rational demands of the competitive environment, or by irrational demands by users to have the best and latest.) Bad project management is also an IT failure much of the time. The IT community is aware of these failings and is making substantial progress in correcting them.
But there is more here than meets the eye. IT cannot do it alone. Substantial participation by users is essential to the success of every IT project.
Let's look at the role of users in a typical IT project in terms of the specific tasks that need to be done in each phase of development.
· User requirements specification - Users should do most of the work, with guidance about 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 create 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 new business processes required by every new system, even as they train the ultimate users of the system.
There is almost no reliable data on how much user time is or should be involved in these activities, but we in the IT community know that the requirements are large. In an attempt to understand the issue, I have conducted over 100 informal surveys of IT professionals in the course of my teaching in the Northwestern University's Communications Systems Strategy and Management program and in various other professional programs and industry seminars.
The survey consists of just two questions. I set the stage this way: "Think about a typical IT application development project that is now under way or that you have recently completed, and answer these two questions. 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: 1. How much user time should the project have had, as a percentage of IT time? Answers typically range from 25% to 50%.
2. How much user time did the project actually get? Answers typically range from 0% ("They told me to do it, and then disappeared until it was done.") to 15%.
My analysis tells me that user work time in an application development project should be from 25% to 100% of IT time, depending on the nature of the project.
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 many 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.
In no case has any CIO (of over 200 I have surveyed) ever 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. · Users often change requirements during the project, as they begin to understand the ramifications of the new system, or as business needs change. · 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. Changing requirements magnify the problem. · Projects are over budget for the same reasons. · System functionally is compromised because the IT people do not know as much about business needs and business processes as the users know.
What's a manager to do? · If you the CEO or COO, do not authorize any project unless the user commits in advance to providing 50% 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.
The biggest IT failure is failure to get the users do their jobs.
Courtesy : http://www.webpronews.com/it/itmanagement/wpn-18-20050512HowtoMakeYourITProjectaSuccess.html
