Risk control and resolution
This ranking is necessary because it would be difficult, if not impossible, to provide a plan for dealing with every possible risk in every step of the project. With each risk assigned a risk factor value, the team now has a road map for mitigating project risk by developing contingency plans only for the tasks that have the highest risk factor. In most projects, the rule of thumb is that the team should focus its risk resolution efforts on the top 20 percent of the identified risks, but this is not a hard-and-fast rule. Risk resolution may need to be more extensive. Barki et al. (2001) have noted that the risk management profile of a project needs to vary according to the level of risk posed by the project itself with more risky projects needing more extensive risk resolution. For instance, the initial implementation of a digital repository is less risky than a subsequent software migration to a different repository architecture. Migration is more risky than implementation because in a migration there is a body of material that is in potential jeopardy which does not exist in an initial implementation. In an initial implementation, the only thing in jeopardy is the conceptual model – either it will work or not. Because there is no substantive body of material in danger of being lost or corrupted, this activity is less risky than migration of digital objects.
