ACM today released a survey of IT/software development projects to
identify the most common causes of
failure
and developed a tool to assess what the risk of failure for a given
project is.
As part of a multiyear research program on software project risk, we
asked MIS directors in 60 organizations to make 720 separate project
evaluations (see "How the Study was Conducted"). The purpose of the
study was to understand the relative importance they ascribed to the
software project risk drivers described earlier. The results revealed
that the most critical risk driver was the choice of methodology---a
result that we were not expecting---followed by customer involvement,
use of formal project management practices, similarity to previous
projects, project complexity, and requirements volatility (see Figure
1).
It's interesting to note that of the six key drivers of failure,
complexity ranks #5. While the most important driver was "choice of
methodology", which means that one approach is not always going to work
across different engagements. For a small projects, a more iterative
methodology might be a better fit but you should keep in mind the
budgeting and staffing implications that would result.
For example, a methodology such as rapid prototyping relies on
iteration to uncover novel or poorly understood user needs. In
contrast, a structured methodology emphasizes structure over iteration
and might be more useful for managing larger projects where
requirements are better understood."
Finally, #6 emphasizes that getting requirements right is both difficult
and important. All software projects struggle with this to one extent or
another.
"Building a system on volatile requirements is like attempting to
build a structure on a foundation of sand. Tweaking an unfinished
system to match shifting requirements requires additional programming
effort and expensive reworking. Even if requirements are correctly
elicited, there is no guarantee that they will remain unchanged over
the project trajectory. Both changing business environments and fickle
customers can contribute to requirements volatility. A certain level
of requirements volatility has come to be expected in software
projects, which may explain why this factor emerged with the lowest
weighting among the six drivers of project risk in our study."
I'm not sure of the value of their 1 minute risk assessment
tool to produce a
number that "predicts" project risk score. (). Different folks could
score the factors differently but it could be a valuable way to evaluate
project performance along the way (identify areas of concern for
managers and developers to focus on) and at the end of a project.