Friday, April 30, 2010

What could we learn from software failure?

Currently Queensland Health is enjoying a vast amount of media coverage because it's new pay system isn't working. - 'The scope of the problems are breathtaking' a staff representative said. In past times we have had a massive failure of a new student booking system at RMIT - that one was scrapped costing AU$30M because it just didn't work.

The only reason I highlight those two is because they're big enough to get media coverage. We all know that many many more broken systems are out there quietly squeaking and rattling their way to an early demise - if they were cars they'd be lemons, taken off the road and scrapped. With software it's more difficult, not least because of the money involved but also because the basic need to admit there's a problem. When management has spent millions it can be too bitter a pill to admit failure and take the financial hit, better to let the organisation work through the problems throwing good money after bad.

It's not the decision makers who have to use the horror system and at their level a failure is distinctly career limiting. As the managers don't use systems it's easy for them to paper over the cracks of failure. If someone in accounts has to spend twice as long doing a basic task that will annoy one person but it's better, for the manager, to take that hit rather than risk their own status quo.

Of course the real ongoing cost to the organisation is high, but it's difficult to quantify, especially the intangibles such as staff satisfaction. These points are rarely taken into account when planning a project, yet it's precisely in these areas that most risk lies. With new systems it's too easy to be enamoured with the latest SOA architecture or whatever, rather than the boring nuts and bolts of getting the core business processes running properly. Analysing risk in this way is simply foreign to most people. The reason for that is that in most other fields it would be ludicrous to expect these risks - new trucks do the basics right every time, as do new photocopiers, as do most standard elements of a business. The difference is that most software, beyond the likes of MS Office, is distinctly non standard and managers simply don't even know there will be risk associated with that. No awareness of risk, means no assesment of risk, leading to expensive failure.

The bottom line is that organisations are not effective when it comes to ad-hoc software development. Regardless of whether it's in house or out sourced - they simply don't have the skills to measure the risk and know whether something is likely to be a success or failure.

I'm going to blog extensively about this area and in this first missive I wanted to touch onto two key points.

1) Admitting to a failure is too hard for most organisations
2) Organisations lack the risk analysis skills to decide what is worth doing and what is just too complex.

No comments:

Post a Comment