AUCKLAND (10/10/2003) - Debate on the merits of application development techniques -- whether development should use waterfall, iterative or agile methods, for example -- can be irrelevant if the up-front work on user requirements and risk assessment is skimped on, says a U.S.-based visiting researcher.
"Most projects fail because of management difficulties," says Donald Gotterbarn, from East Tennessee State University, conducting research on software development as a visiting professor at the Auckland University of Technology.
Significant among these is incomplete risk assessment. This often results from "too narrow a view of who the stakeholders are" and how each part of the system will affect them, he says.
A project could satisfy the three classic core requirements -- good functionality, developed on time and within budget -- and still fail to provide the users with what they want or need, or put them at risk.
Gotterbarn's views are echoed in a report on project failure from consultancy KPMG, which highlights similar lack of attention to user requirements in the broader sphere of business projects, including IT.
Gotterbarn jointly developed a technique called the software development impact statement (SoDIS), for identifying and quantifying risks more effectively. A SoDIS audit consists of taking individual tasks handled by a system, considering which of the stakeholders are affected by this task, evaluating the risk to them and considering how to mitigate that risk and how to monitor it.
Gotterbarn and colleagues have developed a computer-based application to help with the SoDIS process, by leading developers through "structured questions", and giving them "stickies" -- pop-up note facilities -- to keep track of particular points of concern and suggested remedies as they go.
For example, if a perceived problem is "we may have to rush testing of this stage using inexperienced staff", noted "sticky" suggestions might be to extend the testing timeframe or to begin, at an early stage, a search for more knowledgeable testers.
Databases of pertinent considerations for particular problem domains are being evolved to lighten the task.
Like the KPMG report authors, Gotterbarn fingers lack of resources as an important reason why these preliminary stages are skimped on. The temptation is great to say "we haven't got the time", he says; but sound risk assessments will benefit the project and in the long run will save time, as well as producing a system which meets the needs of the users 0 saving on rework 0 and in many cases avoids danger to the person and lawsuits.
"If you don't attack risks," Gotterbarn says, "then they will attack you." Gotterbarn will be speaking about mitigating project risk at a New Zealand Computer Society event in Auckland next week.