Software Tech News 2-2: Risk Management

What Do You Mean You Can’t Tell Me If My Project Is In Trouble?

Part 2

Please note this is the second part of a long article. The article starts at this page.

Further Analysis

The top seven (high priority) risk-indicators were identified using the following approaches:

The Tally: An agree was allocated a value of +1, a disagree a value of -1. The answers to each survey statement were then tallied. The raw results are shown in Table 1. The following risk-indicators received the highest positive values (most agreement) as causes of project failure:

Risk	Risk-indicator	Responses
1	Poor requirements	134
5	Lack of, or, poor plans	125
6	Failure to validate original specification and requirements	113
30	Resources are not allocated well	109
16	Failure to communicate with the customer	106
25	Lack of management support	98
33	Unrealistic deadlines - hence schedule slips	97

Priorities: The survey asked respondents to rank the risk-indicators in order of priority. The weighted results are as follows (top priority first):

Risk	Risk-indicator	Weight
1	Poor requirements	864
16	Failure to communicate with the customer	683
5	Lack of, or, poor plans	574
4	Lack of process and standards	361
25	Lack of management support	350
6	Failure to validate original specification and requirements	329
29	Political considerations outweigh technical factors	304

Top Seven List: Since the actual position may be subjective, the number of times a risk-indicator showed up in the priority list was also tallied. The results are as follows:

Risk	Risk-indicator	Count
1	Poor requirements	99
16	Failure to communicate with the customer	86
5	Lack of, or, poor plans	77
4	Lack of process and standards	51
25	Lack of management support	51
29	Political considerations outweigh technical factors	45
6	Failure to validate original specification and requirements	44

These results show a high degree of consensus on these risk-indicators as causes of project failures.

Sensitivity Analysis

The sample size for respondents without management experience was 99. The raw tallies for the risk-indicators listed below were examined to see if there was a difference between non managers and managers with various years of experience. No differences of more than 10% were noted.

Risk	Risk-indicator
5	Lack of, or, poor plans
8	Low morale
15	Failure to collect performance & process metrics and report them to management
25	Lack of management support
27	Lack of understanding that demo software is only good for demos
29	Political considerations outweigh technical factors
32	There are too many people working on the project
33	Unrealistic deadlines - hence schedule slips

The “Other” Category

Several respondents added a small number of risk-indicators in the other category of the questionnaire. These included:

Failure to control change

Rapid rate of change of technology

Low bidding

Poor management

Lack of a technical leader

Thus, the small student sample size of 19 seems to have identified most of the important risk-indicators.

The Risk-Indicators Most People Disagreed With

Part of the analysis of the survey results was to determine which risk-indicators received the most amounts of disagreement as causes of project failure. This was done by determining the:

largest number of disagreements by the recipients, and

least number of agreements by the recipients.

The risk-indicators receiving the largest number of disagreements were:

Risk	Risk-indicator	Responses
18	Failure to reuse code	88
3	Failure to use Independent Verification and Validation (IV&V)	80
32	There are too many people working on the project	75
12	Client and development staff fail to attend scheduled meetings	74
34	Hostility between developer and IV&V	70
31	The Quality Assurance Team is not responsible for the quality of the software	68
15	Failure to collect performance & process metrics and report them to management	67

The following risk-indicators received the least number of agreements as causes of project failure:

Risk	Risk-indicator	Responses
20	Failure to use problem language	30
18	Failure to reuse code	32
34	Hostility between developer and IV&V	34
32	There are too many people working on the project	43
31	The Quality Assurance Team is not responsible for the quality of the software	45
3	Failure to use Independent Verification and Validation (IV&V)	49
28	Management expects a CASE Tool to be a silver bullet	53
12	Client and development staff fail to attend scheduled meetings	54
27	Lack of understanding that demo software is only good for demos	55

In each method of analysis, six risk-indicators showed up in the group receiving the most amount of disagreement. Consider the risk-indicators most of the respondents disagreed with, namely:

Failure to reuse code: A major advantage of Object Oriented Technology is the ability to lower costs by reusing code. Yet 73% of those surveyed did not agree with this risk-indicator.

Hostility between developer and IV&V: This risk-indicator shows a team problem and results in less than optimal costs due to the lack of cooperation.

There are too many people working on the project: This risk-indicator is based on (Brooks, 1982) which describes the problems associated with assigning additional people to projects.

Failure to use problem language: The use of problem language was promoted as one of the major advantages by (Ward & Mellor, 1985). Yet, only 34% of the respondents agreed that it was a risk. Several did not know what the term meant.

The Quality Assurance Team is not responsible for the quality of the software: As discussed above, this was the only indicator that should have shown disagreement.

Client and development staff fail to attend scheduled meetings: This is a symptom of poor communication between the client and the developer. In addition, while there are other communication techniques available, if meetings are scheduled, and not attended, negative messages are sent to the project personnel.

Failure to collect performance & process metrics and report them to management: If measurements are not made and acted upon, how can the process be improved? Yet 52% of the respondents disagreed that this was a risk-indicator.

The Chaos Study, the Presence of Risk-Indicators in ISO 9001 and Software-CMM, Conclusions, References and Author Information are in next section of this article.

Continue this article by following the next button.