The perceived risks won't reflect the real risks
Perception of risks is to some extent based on experience, to some extent based on teaching. Either could be lacking or not used to the best advantage, and perception may not match reality.
“The greatest risk we face in software development is that of overestimating our own knowledge” – Jim Highsmith, Ref 1.
There are two particular related risks here, and each brings its own problems. There is the obvious risk that a real risk that has been ignored or undervalued will occur and give problems that could have been prevented or ameliorated. There is the less obvious risk that a perception of a risk overvalues the risk, and we will expend more effort in preventing or ameliorating the risk than necessary. Perceived risks are also known as ‘fears’. Some fears are justified; some are not. Some people have no fear in the face of real risk.
There is an old rule that a problem detected and dealt with at requirements will cost 1 unit to cure; at design will cost 10 units to cure, at implementation will cost 100 units to cure. However, certain types of problem do not occur very often, and that rule does not deal with the cost of trying to detect problems that are not there. Where a problem is rare, it may be better to assume it won’t happen, and take the hit (pay your 100 units) on the rare occasions it does happen. What we save by not trying to detect or prevent the problem during requirements and design covers the cost of the occasional detection and cure at implementation. The fear of making a preventable error outweighs the risk – in this example case.
This website is an attempt to address a shortfall in the techniques to deal with inaccurate risk perception. The WiseFool role helps in asking questions where others would not.
Most Agile methodologies start with an assumption of the most likely risks, and also assume that for most risks the easiest and most flexible approach is to have an experienced, skilled workforce organized in a way that the skill and experience can be used effectively. Skill transfer techniques are common, to bring the workforce rapidly to a state of high skill. The typical starting point for agile methodologies assumes changing requirements will be the most significant risk. RUP takes the starting point that lack of knowledge of process will be the most significant risk, though it may be tailored to be a more agile process. Older methodologies tend to assume prevention of change to requirements is possible, and place an unquestioning belief in the ‘old rule’ outlined above.
1. “Adaptive Software Development: a collaborative approach to managing complex systems”, James A. Highsmith III, Dorset House 1998, ISBN 0-932633-40-4