The Department for Work and Pensions (DWP) faces constant pressure to provide its end-users and partners with customised, high quality, working software applications on time and to budget.
This is the primary reason why, with the National Audit Office and other government departments paying close attention to its progress, all future DWP development projects will use agile methodologies.
“Agile is already delivering for us, and it is our intention not to use the old style of project management for new projects in the future. Quite clearly for me and many of the senior people in this department, this is a successful route to higher quality [software] in less time,” said Steve Dover, the DWP programme delivery director paid £125,000 a year to shoulder the responsibility.
“That does not mean to say that all of what was done in the past was wrong – the old way, provided it was supported by effective collaboration, worked and did deliver, but not as efficiently.”
Many project managers would agree there is considerable scope for improvement on more traditional ways of software development and project management – micromanaged, waterfall and so on.
But whether more lightweight, incremental agile alternatives that place greater emphasis on collaboration between teams of developers and end user interaction are the best way forward in every case is not certain either.
Precise figures detailing the DWP’s rate of past software development project failures were not available at the time of writing, with Dover preferring to highlight the NHS National Programme for IT (NPfIT), originally expected to cost £2.3bn but estimated by the NAO to be £12.4bn over 10 years, and already four years behind schedule, as a prime example of what can go wrong.
"The National Programme for IT is not unique: individual departments had already followed the same path but we, as experts in technology-enabled business initiatives, have delivered the wrong thing," he said.
"It is not necessarily the fault of IT but it begins with the client and it is incumbent on me and anyone else in my position to be really clear about what the client wants and how they want to go about achieving it, and collaboration is key to this."
Statistics compiled by the Standish Group in its annual Chaos summary suggest that in 2009, nearly one in four (24 per cent) IT projects within public and private sector organisations across the globe were considered failures, either having been cancelled before they were completed or delivered but never used.
Another 44 per cent were considered "challenged" (either late, over budget or with fewer than required features and functions), and only 32 per cent actually rated successful.
The Standish Group calculated that this was the first increase in IT project failures for a while: historically success rates had risen steadily between 1994 when the firm first started compiling its figures, to 2000 when many companies rushed through Y2K projects to combat the much anticipated millennium bug.
Success rates started to rise again in 2002 through to 2006, but have since fallen, primarily due to the budget cuts during the recession, said the research company.
Some IT industry experts and academics have questioned whether the Standish Group figures accurately document development project failure rates, arguing that the way the firm calculates success versus failure does not reflect reality, are influenced by forecasting bias and are more indicative of failures to manage client expectations rather than project delivery.
Even so Gartner figures from 2008 also suggest around a 20 per cent failure rate across the board, although there are variations – between 14 and 22 per cent – depending on the size of the individual software development project.
It estimated that 25 per cent fail due to functionality issues, 15 per cent because of cost variations, 20 per cent due to cancellation, and 18 per cent because they were delivered too late to be of any use.
Dover believes some behaviours on major software projects are so deeply ingrained that it is difficult for people to let them go, while there is often a perception that third party development houses or software providers are only out to drive variations into the initial set of application specifications because they want to make more money out of the contract.
“If we start off in a mature way and collaborate more effectively, we as clients will ensure that we do maintain a reasonable profit for the contractor,” he said.
“A provider that offers solutions and options that are not going to break the bank is key, but the last thing I want on any of our undertakings is for any party to look to drive those variations because they do not feel they are making enough money. That does not mean we will pay a premium, but maintaining enough profit for the contractor or service provider is key.”
Equally important is to make sure that clients and end users see a working application before it is finalised at the end of the project, because delays between conception and delivery are often so long that the requirements will have changed in the meantime and alterations can be incorporated as part of the initial development process.
"Provide something of value and build incrementally on top of that," advised Dover. "Don’t just mock up an animation of what the real application might look like, produce the real thing even if it's not pretty in the early stages."
Pete Dupre is chief solutions architect at application lifecycle management (ALM) and testing firm Micro Focus, which currently uses agile methodology for 70 per cent of all the software development projects it initiates for in-house use and on behalf of its clients.
"We are not 100 per cent on agile, and nor do we mean to be, but we would encourage those interested to take direction from organisations that have already been through the pain – the process is not without roadblocks and failures, but we have seen significant improvements in quality, productivity and business satisfaction," he said.
By eliminating high entry costs for big data analysis, you can convert more raw data into valuable business insight.
A discussion of the "risk perception gap", its implications and how it can be closed