Opinion

Bring discipline to software development

Poor management processes cause high project failure rate

It was 18 months ago that Nicholas Carr created uproar in the IT industry with the publication of an article in Harvard Business Review entitled IT Doesn't Matter. Carr foresaw a progressive commoditisation of IT that would ultimately do away with the need for companies to develop their own applications.

In the long run, Carr may or may not be proved right, but in the meantime, companies such as Dell and Wal-Mart have quietly developed and deployed custom-made software that has destroyed the competition.

Michael Dell has made no secret of the fact that the company's most powerful competitive weapon is its proprietary supply chain management software. Likewise, Wal-Mart owes its success to an advanced inventory control system. In both cases, the code that runs these systems is a closely guarded secret.

The fact is that IT does matter and always will do. Great companies will work hard to add value to packaged software to build competitive advantage, while others will buy off-the-shelf merely to achieve parity.

But before software developers the world over breathe a collective sigh of relief, safe in the knowledge that their skills will always be in demand, they should be mindful of one sobering fact. Analyst reports have found that, on average, an astonishing 80% of software projects fail. Failure in this context is defined as the project not meeting the original expectations of the business.

IT is still extremely difficult to get right; IT departments swallow billions of pounds of capital expenditure, yet remain largely a financial and management black hole. A Standish Group report, released this year, found that 30% of software projects are cancelled, 44% are too expensive, 60% are not considered a success and 90% are delivered late.

Although software is a competitive weapon for some firms, it is more of a business enabler for the majority. So what is going wrong here and what can business analysts, developers and testers do to improve the situation?

In most cases, projects do not fail because of flaws in the IT itself. The tools exist to help craft first-class software at breakneck speed. The real problem with software development lies with people failing to communicate and processes not being integrated to match business objectives.

Failure is the result of a communication breakdown, firstly among the different roles of those responsible for implementing technology in the IT department, and secondly with the people that define and set the project's parameters in the business.

Unfortunately, most chief information officers have no way to quickly establish which IT projects add the most value to the business. In addition, when developers are set to work on a project, they often work on the tasks that are easiest to do first and leave the difficult, and invariably the highest value pieces until the end. This means that if a project's budget is cut, or the deadline is brought forward, the business is left with an application devoid of all the high-value features that it was originally designed to deliver.

Software development needs to evolve from being a "black art" to more of a managed business process. Despite the billions invested in software, its development is not scrutinised as any other business processes.

There is no reason why the disciplines that were applied to manufacturing processes with enterprise resource planning cannot be applied to software development. When this happens, the full value that software can deliver to the business will be realised and the IT department will surely win the respect it deserves.

Laurent Séraphin is director of software development at Borland

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in October 2004

 

COMMENTS powered by Disqus  //  Commenting policy