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.

I found 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

Moreover, broad 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.

I think we should really ask ourselves why these figures have not improved over the years while computing power and development environments have progressed tremendously.

There are many reasons for failure. However, and from the many discussions I 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!

Posted by Remi on Thursday, March 20th, 2008 at 7:20 AM.