There is an overwhelming number of large-scale software development projects failing to come in on time and within budget, says Compuware.
Citing the Chaos Report from the US-based Standish Group, Yuan Sun, Compuware EMEA solutions architect, says only 35% of software development projects started in 2006 were categorised as successful.
"Furthermore, research among European CIOs conducted by Forrester, on behalf of Compuware, rated quality and lowering of costs as the two top priorities in software development. Timing was rated as less of a priority, with CIOs wanting projects completed properly the first time, providing a solution that met the business requirement," he notes.
The problem for organisations comes in managing requirements as project sizes increase. "The tipping point is generally around $750 000," Sun says.
Projects under that mark have around a 70% success rate, he adds, while the figure inverts for projects over the amount, with around 70% of large scale projects failing either to come in on time and within budget, or failing completely.
Broken telephone
Steve Erlank, Faculty Training Institute MD, says generating quality requirements comes down to a handful of simple truths - requirements need to be clear and unambiguous, discreet, in a shopping-list type format, verifiable, and must contain the appropriate level of detail.
"The challenge comes in applying these principles across large-scale projects with multiple stakeholders."
This challenge usually produces the 'broken telephone' effect, where a requirements document does not reflect the business need or the necessary specifications for the developers.
This, in turn, leads to extended time lines and increased support costs, the very thing research shows CIOs are trying to get away from.
Document overload
Sun says one of the reasons for the complicated project requirements is that people writing requirements use document-centric tools, including word-processing and spreadsheet applications, combining them with drawing tools.
"The problem with this is you have not one, but three sets of documents describing your requirements, requiring you to synchronise information across documentation."
Secondly, when there are multiple stakeholders operating within a team environment, the project manager ends up with multiple versions of the documentation, which needs to be consolidated, he notes.
"Companies need to do sufficient analysis early in the life cycle so requirements can be managed in list form, supplemented by sufficient descriptive information to make each requirement relatively clear," says Erlank. "Without this list, traceability and cross-referencing through the life cycle are impossible.
"The only way to do this on a large project is with the right software, so your requirements are held within a central repository and not across multiple documents."
Share