Why are there still expensive IT failures?

The cost of an IT failure can be devastating. From lost customers to destroyed reputation and damaged revenue stream, organisations simply cannot afford to deliver a solution that fails to meet customer needs. Yet despite technology innovation and a shift towards agile and DevOps, problems still occur. So what has to change?

The great benefit of DevOps is the chance to get close to the consumer; to innovate; and to fail fast. It takes organisations away from long drawn out, ‘in a box’ projects, that risk everything on one release. But alone it isn’t enough – clearly. Organisations need to embrace a completely different culture if consumer expectations are to be met successfully, again and again.

On its own, DevOps does little more than increase the transparency of a project: if the project isn’t working, the problem should become apparent far earlier in the process as a result of early release dates. Early warning does, of course, avoid the huge expensive failure – and provides a chance to remediate, and refocus development on core functionality. But it will not change the probability that customers will love what is being developed unless it is used as an enabler, if it underpins the process of releasing cheaply and more often.

To truly change the prospects of IT projects, development has to be driven by a far more frequent and interactive approach to the end consumer – from weekly update and feedback to cohort testing. And that requires not only a cultural shift in the development/consumer interaction model – from recruiting consumers to iterating and user prototyping and continually testing – but also a development model that can be achieved at a price point that enables very frequent release.

Continuous Improvement

Continuous delivery is about structuring a project to enable additional features to be added without incurring unacceptable cost – not just creating the software but also managing the cost of the release, including manual testing, deploying and updating guides, regression testing, and so on. If the cost of delivering a release is too high, the only option is to fall back on the batch release model, limiting the opportunity to leverage the consumer learning from each release and increasing the risk every time.

The extension of the continuous development process beyond coding to include testing is key: it has to be largely automated to afford the desired fast and frequent release. Where is the value of a simple, one step release model if the process of integration testing and documentation testing requires multiple steps, often across multiple departments and business partners? Consideration of this aspect is fundamental to support the continuous development process – for example through the adoption of well-defined APIs that can support automated testing.

Conclusion

The adoption of continuous delivery is not binary – there are many steps on the road towards this approach, and each step will deliver ROI. The key is to begin to make the change; to start to embed the culture across the entire organisation, reduce the total cost to release, recruit consumers to the process and ensure learning is continuously caught and used to refine and improve what becomes by default a successful development.