With the overwhelming number of software development projects failing to come in on time and within budget, and a shift in CIO priorities towards quality and lowering cost, effectively managing the requirements of development projects is becoming even more critical.
Speaking to 150 delegates from government and the private sector at a Compuware event at the Castle Kyalami in Johannesburg yesterday, Yuan Sun, Compuware EMEA Solutions Architect said that only 35% of software development projects started in 2006 were categorised as successful. The focus for companies had to be on improving requirements management.
“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 says.
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, 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.
Complementing Sun’s remarks, Steve Erlank, MD of the Faculty Training Institute (FTI) said generating quality requirements comes down to a handful of simple truths – requirements need to be clear and unambiguous; discrete; in a shopping list type format; verifiable (measurable) and contain the appropriate level of detail.
“The challenge comes in applying these principles across large scale projects with multiple stakeholders,” Erlank says. “This challenge usually produces the ‘broken telephone’ effect with a requirements document that does not actually reflect the business need or the necessary specs for the developers.”
This, in turn, leads to extended time lines and increased support costs, the very thing Sun said CIOs are trying to get away from.
Sun says one of the reasons for this is that those writing requirements use document centric tools including word processing and spreadsheet applications, combining them with drawing tools.
“The problem with this is that you have not one, but three sets of documents describing your requirements, which mean you have to synchronise information across documentation. Secondly, with multiple stakeholders or in a team environment, you will have multiple versions of your documentation, which then needs to be consolidated,” he says.
Erlank’s conclusion was that companies needed to do sufficient analysis early in the lifecycle so that requirements can be managed in list form, supplemented by sufficient descriptive information to make each requirement relatively clear. Without this list, traceability and cross-referencing through the lifecycle are impossible.
“And the only way to do this on a large project is with the right software so that your requirements are held within a central repository and not across multiple documents. If you make the effort to structure your requirements in the right way early on, the right software will automatically provide you with the traceability you need to effectively manage the project,” he says.
“Requirements management is therefore about thinking about what is needed, communicating effectively and facilitating team work with a central plan to get the project complete on time and within budget.”