IT project failure is rife, judging by media reports of huge programmes that become investment black holes and lead to disappointment all round. Research firm Standish Group contends that 90 percent of software projects are completed late, 66 percent are deemed failures and 30 percent are scrapped.
That situation has driven firms including Borland and Microsoft to join specialists such as Perforce in offering frameworks that help customers plan and track the collaborative development. But how much of a problem is there in software projects today? At a recent round-table organised by Borland, experts and end-users suggested that the common equation of software development projects with poor return on investment is not necessarily fair, and noted that software development has some unique issues.
Bola Rotibi, head of the application lifecycle service at analyst firm Ovum, said, “There are projects that fail, but I think a lot of that is to do with mismanagement. You look at the manufacturing industry and no way would they ever start off thinking, ‘I’m going to build a car and I’m going to think about putting this in and along the way I might change this and I might change that’. They have a very clear idea of associating the product with the requirements and features that they need to build in.”
Others agreed that the open-ended nature of software development means that disputes are always possible.
Nigel Reed, Met Office head of technology development, said, “If you’re running a project to build a bridge, at the end you’ve built a bridge and you know you’ve done it and everybody else knows you’ve done it, but if you’re developing software solutions then success or failure have less well-defined criteria. A lot of this is not about the hard technology, it’s about people and processes and, in particular, the relationship between the business-facing part of the organisation and the technical, internal delivery of the organisation. It ’s about agreeing what it is you’re trying to do as much as possible upfront.”
Michael Azoff, research analyst at Butler Group, said, “The crux of the issue is that software is difficult and we’re still learning how to do it properly. We have to recognise that software is more like lettuce than like gold. It is something that is perishable and also the technology is constantly changing so it’s not as if you’ve got a standing animal that you can try to characterise and understand.”
Ian Mitchell of BT suggested another grey area.
“A project may well reach the original objectives but that might not be what you want anymore when it actually comes to delivering the thing,” he said.
That challenge has seen BT pursue so-called agile methodologies that support
flexibility.
“The [classic] implication is the requirements are out there and if we do a job
well enough we’ll be able to capture them and then we can deliver them and
everybody will be happy, but today it’s all about change,” said Roger Leaton,
agile advocate at BT.
Andy Seager, Borland director of solutions marketing, describes the developer-user communications problem as “the IKIWISI factor”, where users might not be able to articulate requirements but say, “I know it when I see it”. His answer is tools that help control the process and mitigate risk.
“I can put some kind of guard-rails around innovation. I don’t want innovation for the sake of it, I want what I asked for and I want that baseline of understanding to be delivered.”
