Introduction
The academic and popular business press is full of articles elaborating the notion of business success and failure (Barrett, Balloun, & Weinstein, 2005; Castaldo, 2007; Congden, 2005; Im & Workman, 2004; McFarlane, 2006). Indeed, numerous examples of business successes and failures abound, with a variety of suggested causes. For example, Lehman Brothers Holdings Inc went bankrupt in 2008.This is the largest bankruptcy in the history of the United States with $638 billion in assets listed and the largest failure of an investment bank. The bank has been undermined by bad debts and shares tumbled 94% this year, before it was delisted on September 17, 2008. Another example is the Delta Airlines Inc, which went bankrupt in September 2005. This United States airline is based in Atlanta, Georgia and operates extensive international and domestic flights. The company has been facing financial difficulties for a long time and ever since 2004, tried to stave off bankruptcy by restructuring the company with job cuts and expansion plans. However, in September 2005, it filed for bankruptcy for the first time in its 76-year history. The company cited high jet fuel prices and high labor costs as the two main factors. Boo.com, spent $188 million in just six months (The New York Times. June 2, 2000.) In an attempt to create a global online fashion store went bankrupt in May 2000 due to serious quality problems and poor service. More recently, the success of Internet icons Google and Yahoo has been attributed to a number of factors, including technical acumen and executive prowess.
Much of the research on the topic, however, has assumed that critical success factors are relatively consistent across various industries and types of organizations (Barrett, Balloun, & Weinstein, 2005).
A continuing stream of IT innovations from the Internet to the wireless application to digital phone are continuing to transform the business world. These innovations are enabling entrepreneurs and innovative traditional firms to create new products and services, develop new business models, destroy old business models, disrupt entire industries, build new business processes and transform the day-to-day conduct of business.
In view of the potentiality of IT, there have not been many success cases in applying IT in real business environments. Companies have many hurdles and issues with IP projects as shown by researchers. One instance one of the researchers in this field is Standish Group which found out from its 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.
info_it-projects-fail.gif
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.
For this article, a failure is defined as any software project with severe cost or schedule overruns, quality problems, or that suffers outright cancellation. Also worth noting is that most of the failure causes mentioned originate before the first line of code has been written. The failure causes are listed in no particular order.
Failure Example of Software Project
During the years of the study the success rates of software project improved, and failure rates reduced, the numbers still shows the sign of a problem. It is an apparent question to ask "why" when presented with data from the Standish data. Below are few of the case studies considered which will be analyzed to fetch the main reasons of failure of the software system.
Northumbria University developed accounting software to manage its day to day
business. The project could not come up with the desired results and failed to
meet the deadlines. The investigations showed that the basic project management
procedures were not followed. This case study is referenced in this essay at
different points where necessary. [1]
The United States Federal Bureau of Investigation had acknowledged their IT project on the Virtual Case File Technology had not met the bureau's requirements and hence the project failed and that they lost 170 million dollars and wasted 5 years of development period (Friden, 2005).
The Science Application International (SAI) was in charge to deliver the Virtual Case File project and it was expected they would aid the case file management by combining data from old system into the new system, including the Automated Case support system, and finally substituting them (National Research Council, 2004). From the finding of the Council they saw that the concerned people working on the project had no contingency plans and backup plans formalized. The changeover arrangement did not take into account the availability of the old system after moving to the new system (National Research Council, 2004). SAI mentioned that they handed over the first phase of the project ahead of timetable and under budget, but after the 11/9/2001 terrorist attacks on the USA, the requirements for the software changed more than one time (Gross, 2005). The SAI also discovered that FBI was still providing their requirements for the new system after 2 years since the project was started (Fine, Glenn, 2002). SAI also mentioned they had difficulty communicating with the FBI because many top IT managers were replaced (Gross, 2005).
In their findings the Council (2004) also established that the project did not take into account the requirements for the FBI mission. The example provides a good insight into the problems to successful implement large and complex IT projects. The above mentioned e.g. has shown that the problems are associated more to the staff than the technology itself (Tilmann and Weinberger, 2004), even though technology may increase complexity.
Thai subsidiary (SMTL) of a Hong Kong-based multinational company (SMHK) engaged in the manufacturing of electronic equipment. They implemented an integrated software package; which was a failure at the several factors. These factors were mostly management related. Such as a poor fit between the business process assumptions inscribed in the software and the business processes in SMTL, poor leadership at different levels, cultural differences, organizational environment, and poor human resource management.
St John's Hospital is a District General Hospital provides medical and nursing services, which includes both general surgery and medicine. All these services are supported by diagnostic imaging, laboratory, ambulance, pharmacy and therapy services, which are all on site. As the major hospital in a tourist area, it deals with many visitors in the holiday season, generating a large amount of non-booked admissions work.
Why IT projects fail?
The source of failure for a software project can be the software team, the client, the suppliers, and other stakeholders, but the most frequent reasons for software project collapsing are adjusting the IT with organizational cultures and the project management process itself (Tilmann and Weinberger, 2004).
The following list the fundamental reason for the failure of Software projects:
User involvement
The most common reason for software project failure is the lack of user involvement. On the other hand, it has been the primary contributor to software project success. A software project can fail even if delivered on budget and on time, if the software does not fulfill the requirements or expectation of the users. The software teams have become aware of this cause and pay more attention to it recently. Despite giving it more importance during development, user involvement hasn't decreased in importance; it's just that IT professionals have, in effect, solved this major problem.
Poor Planning
Due to the time constrains and pressure from senior management to deliver the software project soon, the IT managers are not given enough time to plan the development of software and many a times the project is implemented before it has been clearly understood and defined (New Zealand Management, 2003). IT projects establishes a relationship from the beginning to end of the project. According to Paul Hewitt, a consultant with the Software Technology Support Center (STSC), the customer and the software developers of this system had received most of their requirements from senior supervisors and so-called "users" who were not regularly using the existing system. In such cases, participants see planning as a time consuming method and hence believe that time can be spent better by doing something else rather than planning (Fichter, 2003). Due to all the above reasons the software project is doom to fail because the system was not adequate for its users and environment.
A primary causes for the FBI project to fail was due to poor planning. For instance, it was found that the source code was not provided at every stage to be tested (Gross, 2005). As stated above software projects have a start to finish relationship i.e. the start of the project is very interrelated to the end of the software project. Many actions can only begin once another activity has been completed and approved. There is always some kind of risk in all software projects. One of the main problems in project planning is not conducting an precise risk calculation (Armour, 2005). The critical path is very critical, since any variation from the timetable in this path could cause the whole software project to fail (Fichter, 2003). In software projects, software managers are not always aware of the risk involved when they come up with a plan because they have not planned the essential processes to calculate and report the risk (Armour, 2005). There is always new and unknown risks when old technologies are replace by new(Pinto and Kharbanda, 1996). For example in the case of the Virtual Case File project the objective was to get rid of the old system and place the new system on its place, and the managers did not take into consideration the old system will no more be available (National Research Council, 2004). Therefore not counting on the availability of the old system is a good example that risk calculations were not taken into consideration.
Vague Requirements
During the requirement stage were the software team interview and collect data to setup the objectives of the project, if the requirement gathering stage is partially clear due to a poor feedback from the users. The project goal becomes poor (Glaser, 2004). For example, the Bureau had decided to make the Virtual Case file system easier for its agents to analyse, communicate and organize data on criminal and terrorism cases. The Bureau left to the software project team to interpret the definition of "easy". It was not really understood by the concerned people how the file system would be used to make the analysis and communication of data easier.
One clear solution is that before any other work goes forward the software team should set up a rationally even requirements baseline. Requirements are bond to change even when a stable requirement is created. "You can't design a process that assumes [requirements] are stable," advises Humphrey. In virtually all projects, there will be some degree of "learning what the requirements really are while building the product," he said. If the system is developed keeping in mind that in future there might be some requirement changes, then in that case the project will not head for failure since the developers can add new requirements to its architectures and processes or if there are badly written documentation that agree on how and when requirements can be implemented, added and removed.
Objectives changing during the project
Most of the software project managers had the sensation that their IT project would keep on growing and never stop. For example, after 11/9/2001 terrorist attacks, the Virtual Case File software requirements changed several times (Gross, 2005). The FBI Software and related software 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).
If software project managers remain committed to the initial requirement there is a good chance the project will fail when the projects requirements keep changing. Software project managers not taking into consideration the project trade-offs will have problems to make decision on the goals of the system requirements.
Unrealistic time or resource estimates
Like most of the engineering activities, every software project has a minimum achievable schedule and cost. It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently beyond your reach. Fredrick Brooks summarized this law in The Mythical Man Month (Brooks Jr.) when he stated, "The bearing of a child takes nine months, no matter how many women are assigned." Trying to get around a project's natural minimum limits will backfire. This problem occurs any time someone "makes up a number and won't listen to anyone about how long other projects took," said Jones.
Another major dilemma in estimating schedule is to use linear approximation (Grossman, 2003). For example, if a farmer doubles the cows in a farm, he will double his milk production. The IT projects cannot be applied with such analogy and is beyond the capacity of such linear approximations (Grossman, 2003). For example if there is a large IT project having around 100 staff working on it. Applying linear approximation theory would conclude that increasing the staff by 200 would reduce the schedule and increase the expenditure to roughly the same degree. In real life situation, doubling the people produce a non-linear result (Grossman, 2005).
Stakeholder Conflicts
The lack of user participation and senior management support and are the two most difficult factors in managing IT projects according to the research companies and academic (Jenster and Hussy, 2005) .
The project software manager is the crossing point between the technology and business sides of the company (The Standish Group, 1999). With no senior management support software managers in the organization find it complex in aligning their projects with the business. If the senior management have issues with the project they have to be frank in their discussion with the software project manager. If not, than once the project starts having problems the senior management support will fade (Glaser, 2004).
The work environment of many staff's changes depending on the software project they are working and call them to contribute in design and implementation. With no user participation, nobody in the company feels devoted to the project. User taking part in a project requires time and endeavor, but the employee might be already involved in one project and might not find time to schedule on the new project. That is why senior management should make priority clear to the staff and support them.
Communication Breakdowns
If there is no proper communication channel among the participants there is danger of projects to fail. Problem to communicate are very common on large software projects. For example in the case of The Virtual Case File the communication with FBI was difficult because many top IT managers were replaced (Gross, 2005).
In most software projects, the whole project is not put on the shoulder of one person (Gross, 2005). For the reason that complex software projects very often engage in large amount of work and analysis, the project group members are busy and the senior management sees no progress. Most of the IT project managers believe that senior management will not see the progress irrespective of them talking to them about the progress of the project (Glaser, 2004).
Skills that Do Not Match the Job
There are many factors that make it difficult to indicate what type of experts will be considered necessary for e.g. the rapidly changing technology and knowledge and the challenge of international competition.
Most software projects involves of a various choice of talents. Many project teams are short of the skills they require (Fichter, 2003). It is difficult for technology based companies to find the experienced workers they need because sometimes few people in the labor market have the necessary skills.
Experienced technology staffs do not necessarily have all the skills required when working on a large project, therefore more skilled people are required with planning, communication and organising large projects (Glaser, 2004).
Conclusion
The factors of failure and successful project management have been documented for many years, they simply need greater attention. The above mentioned factors are not the only causes of failure many more factors can be added, but the existence of additional factors is not the point. As Jones noted, "There are myriad ways to fail. … There are only a very few ways to succeed." (Jones)
Project managers can use the following recommendations to reduce the possibility for a project to fail:
Provide time to plan before developing and implementing a project.
Involve users to participate in design and implementation of system.
At every critical stage of the project have a meeting with the project participants.
Avoid using linear approximation.
Make sure the software project has clear goals and objectives.
Set up the necessary method to analyze and report the risk.
Make sure the software team has the appropriate technology skills.
Take into consideration when there is a change in the requirement.
Make point to communicate regularly about the progress in the project, even if it seems invisible.
Get support of senior management when they have issues on the project.
The above mentioned recommendations, along with strong project management skills, can reduce the risk that an software project fails.
