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 methodologya result that we were not expectingfollowed 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.
