Differences between revisions 5 and 6
Revision 5 as of 2008-09-04 09:06:54
Size: 5909
Editor: kfc
Comment:
Revision 6 as of 2010-03-17 13:12:53
Size: 5928
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
||[:RiskKeypersonsQuit:Key persons quit] ||Knowledge of some area of the DOMS rests on a single person ||0.8 ||0.4 ||0.32 ||
||[:RiskUserInterface:User interface insufficient for librarian use] ||Problems about cooperation about defining a user interface. User tests with bad results. ||0.3 ||0.7 ||0.21 ||
||[:RiskBitStorage:IT does not provide active bit check of the bitstorage] ||The IT dept. is reluctant or refuses to provide active bit check of the data stored in the DOMS. ||0.8 ||0.2 ||0.16 ||
||[:RiskPreservationStrategy:We can not rely on the Planets project to satisfy the needs of our preservation strategy.] ||The regularly feedback from the Planets project indicates that the future services will not meet our needs or be ready when we need them. ||0.8 ||0.2 ||0.16 ||
||[:RiskLackOfRessources:Lack of department ressources] ||Cut in ressources. Pressure to finish ahead of time. ||0.5 ||0.3 ||0.15 ||
||[:RiskThirdPartyRequirements:We get third-party requirements for DOMS integration with other systems, which we cannot meet] ||We get difficult/impossible integration requirements from a third party. ||0.5 ||0.3 ||0.15 ||
||[:RiskCopyrights:The copyright holders are unsatisfied with the enforcement of copyrights in the DOMS.] ||The copyright holders are reluctant or refuses to let their material being stored in the DOMS. ||0.7 ||0.2 ||0.14 ||
||[:RiskDelays:Project takes longer than estimated] ||Individual estimates of actions or tasks start sliding. ||0.6 ||0.2 ||0.12 ||
||[:RiskTDR:DOMS cannot obtain a TDR certification] || The application for TDR certification is denied (once it becomes possible to apply for a certification) ||0.9 ||0.1 ||0.09 ||
||[:RiskRightsFramework:The access control framework provided by DK-AAI does meet the requirements] || Content owners and/or copyright holders complain about the lack of access control in the DOMS. ||0.4 ||0.2 ||0.08 ||
||[:RiskThirdPartyProduct:A Competing 3rd party alternative to the DOMS becomes more popular among the stakeholders.] || The stakeholders shows lack of interest in the DOMS project. ||0.1 ||0.7 ||0.07 ||
||[:RiskLibraryLosesInterest:The Library loses interest in DOMS] ||Missing feedback. Cut in ressources. ||0.1 ||0.7 ||0.07 ||
||[:RiskUnacceptedSystem:The DOMS Meets Resistance in the Library] ||We hear misconceptions about DOMS or see initiatives that contradict DOMS ||0.1 ||0.6 ||0.06 ||
||[:RiskSummaIntegration:The integration with Summa turns out to be more difficult than expected.] || The time usage on Summa integration tasks exceeds the estimates. ||0.1 ||0.3 ||0.03 ||
||[:RiskFedoraFails:Fedora does not meet expectations, e.g. fails to scale] ||Slow response times. Unstable behaviour. ||0.1 ||0.6 ||0.06 ||
||[:RiskCollectionMismatch:Some collections do not fit with the DOMS data model] ||New identified collections which do not look like previous identified collections. ||0.2 ||0.3 ||0.06 ||
||[:RiskFedoraUnresponsive:The Fedora community does not respond or accept our feedback.] || We get no response on our feedback and/or the Fedora team ignores it when they make decisions. ||0.2 ||0.2 ||0.04 ||
||[:RiskSensitiveData:Datatilsynet considers some of the DOMS content causes privacy issues.] || We get a notification from Datatilsynet that they think we have a problem. ||0.1 ||0.3 ||0.03 ||
||[:RiskHelpDesk:HelpDesk will not do end user support] ||High number of support calls directly to the DOMS development team. ||0.1 ||0.3 ||0.03 ||
||[[RiskKeypersonsQuit|Key persons quit]] ||Knowledge of some area of the DOMS rests on a single person ||0.8 ||0.4 ||0.32 ||
||[[RiskUserInterface|User interface insufficient for librarian use]] ||Problems about cooperation about defining a user interface. User tests with bad results. ||0.3 ||0.7 ||0.21 ||
||[[RiskBitStorage|IT does not provide active bit check of the bitstorage]] ||The IT dept. is reluctant or refuses to provide active bit check of the data stored in the DOMS. ||0.8 ||0.2 ||0.16 ||
||[[RiskPreservationStrategy|We can not rely on the Planets project to satisfy the needs of our preservation strategy.]] ||The regularly feedback from the Planets project indicates that the future services will not meet our needs or be ready when we need them. ||0.8 ||0.2 ||0.16 ||
||[[RiskLackOfRessources|Lack of department ressources]] ||Cut in ressources. Pressure to finish ahead of time. ||0.5 ||0.3 ||0.15 ||
||[[RiskThirdPartyRequirements|We get third-party requirements for DOMS integration with other systems, which we cannot meet]] ||We get difficult/impossible integration requirements from a third party. ||0.5 ||0.3 ||0.15 ||
||[[RiskCopyrights|The copyright holders are unsatisfied with the enforcement of copyrights in the DOMS.]] ||The copyright holders are reluctant or refuses to let their material being stored in the DOMS. ||0.7 ||0.2 ||0.14 ||
||[[RiskDelays|Project takes longer than estimated]] ||Individual estimates of actions or tasks start sliding. ||0.6 ||0.2 ||0.12 ||
||[[RiskTDR|DOMS cannot obtain a TDR certification]] || The application for TDR certification is denied (once it becomes possible to apply for a certification) ||0.9 ||0.1 ||0.09 ||
||[[RiskRightsFramework|The access control framework provided by DK-AAI does meet the requirements]] || Content owners and/or copyright holders complain about the lack of access control in the DOMS. ||0.4 ||0.2 ||0.08 ||
||[[RiskThirdPartyProduct|A Competing 3rd party alternative to the DOMS becomes more popular among the stakeholders.]] || The stakeholders shows lack of interest in the DOMS project. ||0.1 ||0.7 ||0.07 ||
||[[RiskLibraryLosesInterest|The Library loses interest in DOMS]] ||Missing feedback. Cut in ressources. ||0.1 ||0.7 ||0.07 ||
||[[RiskUnacceptedSystem|The DOMS Meets Resistance in the Library]] ||We hear misconceptions about DOMS or see initiatives that contradict DOMS ||0.1 ||0.6 ||0.06 ||
||[[RiskSummaIntegration|The integration with Summa turns out to be more difficult than expected.]] || The time usage on Summa integration tasks exceeds the estimates. ||0.1 ||0.3 ||0.03 ||
||[[RiskFedoraFails|Fedora does not meet expectations, e.g. fails to scale]] ||Slow response times. Unstable behaviour. ||0.1 ||0.6 ||0.06 ||
||[[RiskCollectionMismatch|Some collections do not fit with the DOMS data model]] ||New identified collections which do not look like previous identified collections. ||0.2 ||0.3 ||0.06 ||
||[[RiskFedoraUnresponsive|The Fedora community does not respond or accept our feedback.]] || We get no response on our feedback and/or the Fedora team ignores it when they make decisions. ||0.2 ||0.2 ||0.04 ||
||[[RiskSensitiveData|Datatilsynet considers some of the DOMS content causes privacy issues.]] || We get a notification from Datatilsynet that they think we have a problem. ||0.1 ||0.3 ||0.03 ||
||[[RiskHelpDesk|HelpDesk will not do end user support]] ||High number of support calls directly to the DOMS development team. ||0.1 ||0.3 ||0.03 ||

Risk Analysis

The risk analysis is an assessment of all identified risks that are considered relevant for this project. This page provides an overview over these risks and information on how to detect when they may occur and how likely it is, how severe the consequences are if they occur and their over-all importance for the project.

This information may change during the project as all risks must be continuously monitored to see if there are any changes in their properties. Some risks may even become irrelevant during the project or new risks may be identified.

Overview

The below table lists all the identified risks. Each entry has a brief description of the risk, a brief description of the warning signs that may indicate that it is imminent and some values that indicate the probability of occurrence, consequence and its over-all importance to the project.

The probability and consequence fields in the table must be filled with a number between 0.1 and 0.9, where a value of 0.1 indicates a low probability/consequence and 0.9 indicates a very high probability/consequence. If a risk has a high consequence value then it will have a great impact on the project if it becomes reality.

The over-all importance of the risk is determined by multiplying its probability with its consequence, thus, if a risk would have a great impact on the project (e.g. a consequence of 0.9) but is very unlikely to occur (e.g. a probability of 0.1) then it will not be very important (as the importance would be 0.9 * 0.1 = 0.09). However, the risk must still be continuously monitored just like all other risks in the project.

Risk Description

Symptoms / Warning Signs

Probability (P)

Consequence (C)

Importance (P * C)

Key persons quit

Knowledge of some area of the DOMS rests on a single person

0.8

0.4

0.32

User interface insufficient for librarian use

Problems about cooperation about defining a user interface. User tests with bad results.

0.3

0.7

0.21

IT does not provide active bit check of the bitstorage

The IT dept. is reluctant or refuses to provide active bit check of the data stored in the DOMS.

0.8

0.2

0.16

We can not rely on the Planets project to satisfy the needs of our preservation strategy.

The regularly feedback from the Planets project indicates that the future services will not meet our needs or be ready when we need them.

0.8

0.2

0.16

Lack of department ressources

Cut in ressources. Pressure to finish ahead of time.

0.5

0.3

0.15

We get third-party requirements for DOMS integration with other systems, which we cannot meet

We get difficult/impossible integration requirements from a third party.

0.5

0.3

0.15

The copyright holders are unsatisfied with the enforcement of copyrights in the DOMS.

The copyright holders are reluctant or refuses to let their material being stored in the DOMS.

0.7

0.2

0.14

Project takes longer than estimated

Individual estimates of actions or tasks start sliding.

0.6

0.2

0.12

DOMS cannot obtain a TDR certification

The application for TDR certification is denied (once it becomes possible to apply for a certification)

0.9

0.1

0.09

The access control framework provided by DK-AAI does meet the requirements

Content owners and/or copyright holders complain about the lack of access control in the DOMS.

0.4

0.2

0.08

A Competing 3rd party alternative to the DOMS becomes more popular among the stakeholders.

The stakeholders shows lack of interest in the DOMS project.

0.1

0.7

0.07

The Library loses interest in DOMS

Missing feedback. Cut in ressources.

0.1

0.7

0.07

The DOMS Meets Resistance in the Library

We hear misconceptions about DOMS or see initiatives that contradict DOMS

0.1

0.6

0.06

The integration with Summa turns out to be more difficult than expected.

The time usage on Summa integration tasks exceeds the estimates.

0.1

0.3

0.03

Fedora does not meet expectations, e.g. fails to scale

Slow response times. Unstable behaviour.

0.1

0.6

0.06

Some collections do not fit with the DOMS data model

New identified collections which do not look like previous identified collections.

0.2

0.3

0.06

The Fedora community does not respond or accept our feedback.

We get no response on our feedback and/or the Fedora team ignores it when they make decisions.

0.2

0.2

0.04

Datatilsynet considers some of the DOMS content causes privacy issues.

We get a notification from Datatilsynet that they think we have a problem.

0.1

0.3

0.03

HelpDesk will not do end user support

High number of support calls directly to the DOMS development team.

0.1

0.3

0.03

RiskAnalysis (last edited 2010-03-17 13:12:53 by localhost)