Author: Al Neimat, Taimour

Abstract

The relevant lessons that can be derived from recognizing areas where IT projects are more likely to fail are also presented at the end of the paper.

1. Introduction

Business environments these days are characterized by complexity, and acceleration of everything from communication to production methods. IT has been one of the major drivers of this complexity and acceleration.

There are nearly limitless applications of IT in the service of business. IT improves productivity through streamlining of process and enhances efficiency and effectiveness of individual workers as well as groups through connectivity that it offers. IT also makes it possible for business to grow by access to new markets and new partners.

Considering those capabilities of IT, it can be disappointing to see the limited success that has been achieved in applying it in real business environments. Researches continually show that companies have difficulty with IT projects. One example is the Standish Group’s study of 30,000 IT application projects in US companies (The Standish Group International, 2001). The data on project outcomes are shown on figure 1-1.

The category definitions for the Standish Group research (The Standish Group International, 1999) are as follows:

• Successful projects were completed on time and on budget, with all the features and functions that initially specified.
• Failed projects were cancelled before completion or never implemented.
• Challenged projects were completed and operational, but over-budget, over the time estimate, and with fewer features.

The Standish Group research confirms that large projects are more likely to fail than small projects (The Standish Group International, 1999). That is likely because large projects tend to be more complex.

Although success rates increased, and failure rates decreased during the six years of the study, the numbers still indicate a problem. It is an obvious question to ask “why” when confronted with data such as the Standish data. Before answering this question, it is important to consider a failure example of an IT project.

2. Failure Example of IT Project

The best documented IT project failures are the ones involving public money. The most recent example is the Virtual Case File project for the United States Federal Bureau of Investigation (FBI).

The FBI had admitted the Virtual Case File Technology had failed to meet the bureau’s requirements and that:

• Five years of development and
• $US 170 million in cost

had been lost (Friden, 2005).

The Virtual Case File had been delivered by Science Application International and it was aimed at facilitating case file management by integrating data from older system, including the Automated Case support system, and eventually replacing them (National Research Council, 2004).

The National Research Council (2004) saw no evidence that backup and contingency plans had been formalized. The transition plan did not include the availability of the Automated Case Support system after the cutover to the Virtual Case File (National Research Council, 2004).

Science Application International Corporation said it delivered the first phase of the project ahead of schedule and under budget, but the requirements for the software changed more than one time after the September 11, 2001 terrorist attacks on the USA (Gross, 2005). The office of the inspector general found that FBI was still defining the requirements after two years since the start of the project (Fine, Glenn, 2002). Science Application International Corporation also said that the communication with FBI was difficult because of the high turn over of top IT managers (Gross, 2005).

National Research Council (2004) also found that the requirements for the FBI mission were not included in the Virtual Case File design.

The example of Virtual Case File gives a high level overview of the difficulties to successful completion of complex IT projects. The example has shown that the difficulties are related more to the people than the technology itself (Tilmann and Weinberger, 2004), even though technology may increase complexity.

3. Why IT projects fail?

The project team, the suppliers, the customers and other stakeholders can all provide a source of failure, but the most common reasons for project failure are rooted in the project management process itself and the aligning of IT with organizational cultures (Tilmann and Weinberger, 2004).

Based on a research carried out by the Coverdale Organization (Cushing, 2002), the respondents identified estimation mistakes, unclear project goals and objectives, and project objectives changing during the project as key factors in project failures.

The following list the primary causes for the failure of complex IT projects:

• Poor planning
• Unclear goals and objectives
• Objectives changing during the project
• Unrealistic time or resource estimates
• Lack of executive support and user involvement
• Failure to communicate and act as a team
• Inappropriate skills

The remainder of the paper elaborates on these causes.

3.1 Poor planning

Sometimes IT managers are not given the opportunity to plan because time pressure from senior management take over and most of the time the project is on it’s way before it has been clearly defined (New Zealand Management, 2003). In such cases, people see planning as a waste of time because they believe that time is better spent doing something rather than planning (Fichter, 2003).

Most large IT projects are planned these days, but that is not enough. Most projects have major milestones, and the problem is that the work continues throughout each milestone (Humphrey, 2005); implementing sometimes starts before plan completion and continues through most of the testing.

A fundamental reason the Virtual Case File software project fail was due to poor planning. It was found for example that very little code had been released to test (Gross, 2005). IT projects are full of start to finish relationship. Many activities can only start once another activity is completed and approved. The critical path is important, because any deviation from the schedule in this path could cause entire project failure (Fichter, 2003).

Detailed plans are not effective for managing IT work. The reason is that the managers do not know enough about the work to make detailed plans (Humphrey, 2005). Team members might make their own plan but most of them do not want to. They would rather implement the solution. Few of them have the skills and experience to make complete plans, and there is a big risk in trusting them in producing their own plans that will meet management objectives (Humphrey, 2005).

Every IT project involves some degree of risk. Not doing an explicit risk calculation is one of the major problems with project planning (Armour, 2005). In IT projects, project managers often do not know what level of risk they are taking when they make a plan because they have not set up the necessary processes to calculate and inform the risk (Armour, 2005). New technologies which replace old technologies imply new and unknown risks (Pinto and Kharbanda, 1996). The Virtual Case File project was aimed at replacing older systems, and the plan did not include the availability of those systems (National Research Council, 2004). Not including the availability of those systems is a proof that risk calculations were not set up probably in the Virtual Case File project.

3.2 Unclear goals and objectives

Sometimes the goal of a project may be only partially clear due to a poor requirement gathering in the definition stage of a project (Glaser, 2004). For example, the FBI had decided it should implement the Virtual Case file system to make it easier for agents to organize, analyze and communicate data on criminal and terrorism cases. It is not really clear how the Virtual Case file system would be used to ease the analysis and communication of data. The definition of “easy” was left up to the project participants to interpret.

The same will apply for an organization that has decided to implement a computerized customer relationship management system to improve the quality and efficiency of customer care. It is also not clear how the computerized customer relationship management system will be used to improve customer care. And again the definition of customer care improvement is left up to the project participants. In both examples, the scope and schedule of the project can not possibly be accurate because their objectives are unclear.

Defining clear requirements for a project can take time and lots of communication, but sometimes goals and objectives might be unclear because project sponsors lack the experience to describe what they really require (Fichter, 2003).

Many participants in the Jensen Group Study said goals were unclear in their projects simply because there are too many of them (The Jensen Group, 2000). Others said it was not the objective that was unclear, but the inability to provide direct and honest feedback on the progress (The Jensen Group, 2000).

Sue Young, CEO of AND Consulting in Colchester, stated in an interview with Computerworld magazine that the status for most IT projects is not reported in observable terms, but it is often put in subjective terms like “percent done” (Bert, 2003). Sue Young clarified that results can be coloured when reporting is done in subjective terms (Bert, 2003).

3.3 Objective Changes during project

Many project managers had the feeling that their IT project would never stop growing. For example, the requirements for the Virtual Case File software changed more than one time after the September 11, 2001 terrorist attacks (Gross, 2005). The Virtual Case File Software and similar IT projects suffer from two classical problems in project management:

• Scope creep
• Feature creep.

Scope creep refers to uncontrolled and unexpected changes in user expectations and requirements as a project progress, while feature creep refers to uncontrolled addition of features to a system with a wrong assumption that one small feature will add nothing to cost or schedule (Fichter, 2003).

Project managers not understanding project trade-offs will result in not making decisions regarding objectives on the basis of rational insight. Staying devoted to the initial requirement will result in failure when the requirement of a project changes more than one time.

3.4 Unrealistic time or resource estimate

Estimation mistakes of time or resource cause project related problems. One common problem during the creation of the Work Breakdown Structure is assuming that the time on task equals duration. The time on task is the time the task will take to complete without interruptions, whereas duration is the time the task actually take to complete including interruptions. Using the time on task to estimate schedule is one of the common mistakes made by project managers (Fichter, 2003).

Another common problem is using linear approximation when estimating schedule (Grossman, 2003). For example, if you doubled the cows in a farm, you double your production of milk. The IT projects are beyond the scope of such approximations (Grossman, 2003). Assume we have a large IT project using a team with a staff of one hundred people. Linear thinking would support the conclusion that increasing the people by 100 percent would decrease the schedule and increase the cost to approximately the same degree. In reality, doubling the staff produce a non-linear result (Grossman, 2005).

3.5 Lack of executive support and user involvement

The research companies and academic institution has focused on the lack of executive support and user involvement as two main difficulties in managing IT projects (Jenster and Hussy, 2005).

The project manager is the interface between the business and technology sides of the company (The Standish Group, 1999). Without executive support project managers in the organization find difficulty in aligning business with their projects. The executive management also needs to be straightforward if they have reservations about the project. Otherwise, once problems are encountered in the project their support will weaken (Glaser, 2004).

Most IT projects will change the work life of many users and require that they participate in design and implementation. Without user involvement nobody in the organization feels committed to the project. User involvement requires time and effort, but the staff might be already stretched and unable to find time for a new project on their schedule. That is why executive management support is important to make priority clear to the staff.

3.6 Failure to communicate and act as a team

Projects sometimes fail due to improper communication. Science Application International Corporation said that the communication with FBI was difficult because of the high turn over of top IT managers (Gross, 2005). Communication problems are common on large IT projects.

Because complex IT projects often involve large amount of analysis and work, the project teams are busy and the executive management sees no progress. IT project managers do not communicate progress regularly because they believe that progress will not be seen by the executive management (Glaser, 2004).

In many IT projects, there is no one person who has an overview of the whole project (Gross, 2005).

3.7 Inappropriate skills

The challenge of global competition, the rapid growth of knowledge, and the constant changes of technology make it hard to predict what kind of skilled people will be needed.

Most IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require (Fichter, 2003). It is also not easy for technology based organization to find the experienced people they need because sometimes few people in the labour market have the necessary skills.

The larger the project, the more need there is also for people with excellent planning, oversight, organization, and communications skills; experienced technology skilled people do not necessarily have these abilities (Glaser, 2004).

Conclusions

The past failure need not discourage project managers from future efforts. Past examples of IT project failures gives us the opportunity to point to the relevant lessons that can be derived from recognizing areas where IT projects is more likely to fail.

Project managers can position themselves to reduce the possibility for project failure by considering the following recommendations:

• Make sure to plan before starting the development or implementation.
• Pay attention to tasks in the critical path.
• Set up the necessary processes to calculate and inform the risk.
• Ensure that the IT project has clear objectives.
• Understand project trade-offs when making decisions regarding objectives change.
• Use the duration instead of the time on task to estimate schedule.
• Avoid using linear approximation when estimating time or resources.
• Get the support from the executive management and ask them to be open if they have any reservations about the project.
• Ensure and communicate regular about the progress, even if it seems invisible.
• Require that users participate in design and implementation of your project
• Make sure you have the appropriate planning, communication, and technology skills.

These recommendations, along with solid project management, can reduce the risk that an IT project fails.

References

Armour, P (2005) Project Portfolios: Organizational Management of Risk Communications of the ACM, Volume 48, Issue 3, page 17

Betts, M (2003) Why IT Project Fail [Online journal] Computerworld, Volume 37, Issue 34, Page 44. Available from Academic Search Premier at http://www.ebscohost.com [Accessed July 21, 2005]

Fichter, Darlene (2003) Why Web Projects Fail [Online Journal] Online, Volume 27, Issue 4, page 43. Available from computer source database at http://www.ebscohost.com [Accessed July 25, 2005]

Fine, Glenn (2002) Federal Bureau of Investigation’s Management of IT Investments: OIG findings and recommendations, Report No. 03-09 U.S. Department of Justice, Office of the inspector general. Available from: http://www.usdoj.gov/oig/reports/FBI/a0309/findings.htm [Accessed July 31, 2005]

Friden, Terry (2005) Report: FBI wasted millions on Virtual Case File [Online] CNN Washington Bureau. Available from: http://www.cnn.com/2005/US/02/03/fbi.computers/ [Accessed July 31, 2005]

Glaser, J (2004) Management’s role in IT project failures Healthcare Financial Management, October

Grossman, Ira (2003) Why so many IT project fail, and how to find success Financial Executive, Volume 19, Issue 3, page 28

Gross, Grant (2005) FBI trying to salvage $170 million software package [Online] IDG News Service. Available from: http://www.computerworld.com/printthis/2005/0,4814,98980,00.html [Accessed July 31, 2005]

Humphrey, W (2005) Why Big Software Project Fail: The 12 Key Questions The Journal of Defense Software Engineering, March Issue

Jenster, P and Hussey, D (2005) Create a common culture between IT and business people to reduce project failures Computer Weekly, March 22

National Research Council (2004) A Review of the FBI’s Trilogy Information Technology Modernization Program Computer Science and Telecommunication Board, National Academies Press, Washington D.C.

Pinto, J.K., and Kharbanda, O.P. (1996) How to fail in project management – without really trying Business Horizons, Volume 39, Issue 4, July-August.

Tilmann, George and Weinberger, Joshua (2004) Technology never fails, but project can [Online journal] Baseline, Volume 1, Issue 26, page 28.

The Jensen Group (2000) Changing how we work – the search for a simpler way [Online] Northern Ilinois University College of Business.

The Standish Group International (1999) CHAOS: A Recipe for Success The Standish Group International

The Standish Group International (2001) Extreme CHAOS The Standish Group International

When IT Projects Fail [Online Journal] New Zealand Management (March 2003), Volume 50, Issue 2, page 18. Available from Business Source Premier Database

Author

Taimour Al Neimat has been working with Microsoft products for over five years, and has been an MCT, MCSA on the Windows 2000, MCSA on the Windows Server 2003, MCSE on the Windows 2000, MCSE on the Windows Server 2003, CCNA, CWNA, and Project+.

He has also worked as a trainer and as a consultant engineer on numerous large network projects, and he is currently an Infrastructure Specialist for a bank in the Middle East. He is also enrolled in a Master’s Program at University of Sunderland, majoring in Information Technology Management.

taimour@hbtf.com.jo

Copyright Project Perfect