For those in the IT industry who started their 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 users 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, people would treat it as a serious emergency.
Why the lower standards for IT projects? It’s not as if the stakes are low; most of the 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 any organisation employees should 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 users start any project without an understanding of this actual business problem, they will never recover from that failure.
Data, software, business process and people: these are the key ingredients of any IT system and if users break one link in the chain, they will fail. Miscommunication at the start leads to a fault that needs to be fixed, which highlights something else that needs to be fixed. Pretty soon, project implementers are 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 they take, the more that value is undermined, and the more likely they are to face resistance and rebellion at the end.
Users 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 users are also slapdash. True agility requires discipline. By formally adopting the principles of the agile development methodology, users ensure they meet their own standards of project success.