For those of us in the IT industry who started our careers as classically trained engineers, there is one question that nags more than any other: How is it possible that the software industry accepts such high project failure rates?
The figures are well known: Depending on which study you look at, anywhere between 50% and 70% of IT projects don’t meet their goals. Imagine if that was the case for civil engineering projects – if 60% or 70% of bridges fell down, or roads collapsed in potholes within a few months, or dams broke. It’s a hard situation to imagine, because there is no way anybody would ever accept it, or anything even vaguely close to it. If only 10% of civil projects failed we’d treat it as a serious emergency.
Why the lower standards for IT projects? It’s not as if the stakes are low: Most of our economy, and the livelihoods of millions of people, depend on working IT systems.
Perhaps it’s been so bad for so long that people in the industry have just got used to it, the same way South Africans have got used to an annual “strike season” that would be regarded as a national emergency in many other countries.
Or perhaps it’s because the costs of IT project failures are easier to hide from than collapsed bridges. Lost productivity, missed opportunities and jobs never created don’t make good TV news images. Even when lives are lost, figuring out that it’s the IT system’s fault usually takes long enough that the focus has moved elsewhere by the time the facts are clear.
Whatever the case, there are no excuses – and in my own organisation we certainly strive to deliver projects that perform far, far better than industry standards.
Project management methodologies like agile development and scrum are a critical tool in achieving this goal. And the first rule of agile development is that it values individuals and interactions over processes and tools. Software is always ultimately designed to solve a problem in the way people interact with information: If you start any project without an understanding of this actual business problem, you will never recover from that failure.
Data, software, business process and people: These are the key ingredients of any IT system and if you break one link in the chain, you will fail. Miscommunication at the start leads to a fault that needs to be fixed, which highlights something else that needs to be fixed: And pretty soon you’re way over time.
With lateness, almost inevitably, comes increasing resistance. No matter how enthusiastically people have embraced the promise of a project, their acceptance is based on the value that project will deliver. The longer you take, the more that value is undermined, and the more likely you are to face resistance and rebellion at the end.
We all know more than one company that has paid millions to install a high-end system – then tried to cut costs at the implementation phase by cutting back on training or change management. The inevitable result is stagnation, leading to desperate measures like flying in expensive overseas consultants – and several years later, the project is limping along and has cost three times what it would have cost to do it properly in the first place.
This is the single biggest cause of project failure: Not data or software or inadequate specification, but failure to communicate. Any development methodology that addresses communication as a central issue is bound to help.
One of the biggest reasons to get this right is that nobody can afford to wait two years for a solution to a business problem anymore: Value depends on quick delivery.
Of course, being quick doesn’t help if you’re also slapdash: True agility requires discipline. By formally adopting the principles of the agile development methodology, we ensure we meet our own standards of project success.