Some Reasons Why Our IT Projects Continue To Fail


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 below.

Figure 1-1: Project outcomes history (1994-2000)

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.

TCS have a white paper available on their WEB site called Evolving IT from ‘Running the Business’ to ‘Changing the Business’. The first part of the document is loaded with some very interesting facts on software development success and failures. It’s amazing to see that the overall quality and reliability of the end-result software has not really improved while the tooling (computers, networks, development environments, etc.) has improved so dramatically. In fact, the actual percentages are only slightly better than they were 10 years ago! Here is an excerpt of their paper.

For a number of reasons, business-critical software and services projects, whether done in house or outsourced, fail far too often. They take too long. They cost too much. They are riddled with defects and don’t accomplish the business goals for which they were designed. An August 2007 study by Dynamic Markets Limited of 800 IT managers across eight countries shows that:

  • 62 percent of organizations experienced IT projects that failed to meet their schedules
  • 49 percent suffered budget overruns
  • 47 percent had higher-than-expected maintenance costs, and
  • 41 percent failed to deliver the expected business value and ROI

Industry consensus indicates that more than one-quarter of all software and services projects are canceled before completion, and of those that are completed, up to 80 percent of budgets are consumed fixing self-inflicted problems. According to Gartner Research, “The lack of testing and QA standards, as well as a lack of consistency, often lead to business disruption, which can be costly.” Gartner also reports that “testing consumes 25% to 50% of the average application life cycle and often is viewed as adding no business value.” Failure of software and services projects is so widespread and so commonplace that 43 percent of IT managers say their business managers and Boards of Directors. Quite understandably, only 11 percent of business organizations consider technology a “strategic weapon,” according to a recent study by Info-Tech Research Group.

There are many reasons for failure. However, and from the many discussions We have with our project managers and clients, I believe that estimates for the coding times are now relatively accurate, something that was not necessarily true 10 years ago. The purpose of this post is to highlight 2 areas that are still underestimated, causing projects to fall behind schedule:

  1. When doing estimates, project managers rarely account any extra time between design and development, an omission that costs dear. Transferring know-how between designers and developers should not be underestimated. When using traditional methods like waterfall, this transition time enables to account for the many adjustments required between design and development, a significant time overhead. Agile-like methods, because of their empirical nature, require extra-time too, to compensate for the (many) requirements churn that happens during sprint time.
  2. The second reason is that QA is still not understood properly, and too often reduced to bare testing. When we provide our clients with our estimates, they usually try to have the time allocated to QA reduced significantly; and the less technical background the people negotiating possess, the higher time reduction they want.

Writing an application can be done relatively rapidly, when seasoned developers are involved. However, making the application fit corporate quality standards can sometimes be a much bigger challenge than the writing of the application itself. If no time has been accounted between design and coding, and if QA times are significantly lower than coding times, expect bad surprises!

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 (We will study more about this key factors in future posts).

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

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. Have a nice day ahead, plenty of success at your projects.

Advertisements

5 thoughts on “Some Reasons Why Our IT Projects Continue To Fail

  1. Pingback: Mastering the Basics of Project Management: The Complete Series (until now) | Nelson Biagio Jr

  2. Pingback: Mastering the Basics of Project Management: The Complete Series [Updated on March 11th, 2013] | Nelson Biagio Jr

  3. Pingback: Mastering the Basics of Project Management: The Complete Series [Updated on March 13th, 2013] | Nelson Biagio Jr

  4. Pingback: Mastering the Basics of Project Management: The Complete Series [Updated on March 18th, 2013] | Nelson Biagio Jr

  5. Pingback: Mastering the Basics of Project Management: The Complete Series [Updated on March 25th, 2013] | Nelson Biagio Jr

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s