“Keeping you up to date with everything software engineering!”

Six Drivers of Project Risk and Their Relative Importance

Project Management | February 03, 2005 | 0 comments

A study was done to determine the six drivers of project risk and the relative importance of each one. The study was done by examining 720 software projects that were carried out by 60 large companies.

The study found that all project failures can be traced to one cause:

The delivered solution does not fit the problem.

This came to no surprise to me. I truly believe that a large percentage of software that is being used on a daily basis is only being used because it is forced upon the user rather then the user choosing the software.

To give a real life example, I was in the bank the other morning doing my banking and I asked my banker, who happens to be my sister, if she finds the software she uses to do her work works well and if it worked the way she worked? She told me she did not like the application they use in the bank at all. She said they are moving the system over to a webbased application though. My only concern with that is speed. I watch my sister go from screen to screen and it is scary how fast she works. I wonder if a web application will slow her down… even if done right. But then again if they understand how a banker works she won’t have to go from screen to screen and all the information will be infront of her when she needs it. Not too much to ask for if you ask me :-).

The following is the list of the six main software project risks in order of importance (with the weight of each risk in parentheses) that was found in the study:

1. Use of an inappropriate methodology (3.0)
2. Lack of customer involvement (1.9)
3. Lack of formal project management practices (1.7)
4. Dissimilarity to previous projects (1.5)
5. Project complexity (1.1)
6. Requirements volatility (0.8)

For some odd reason I was surprised with the largest risk and it’s relative weight (“Use of an inappropriate methodology”). I wonder if it was more the risk in not having a methodoloy all together rather then the methodology choosen?

I would even consider combining numbers 2 and 6. I feel that requirements volatility can be the result of lack of customer involvement. Which would give a combined weight of 2.7 to the newly combined risk of managing requirements. Bring the importance of methology choosen and requirements to being very similar in importance.

What I am not surprised about is the fact that programming languages and the individual competency of a programmer is not on the list.

What do you guys/gals feel about the result of the study? How do you interpret it? Were you surprised by any of it? Would you add anything to the list from your experience?

Related Links:

• Original Article: “The One Minute Risk Assessment Tool”

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)