User Modules

Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Human resources
Asset management module

Technical Modules

Sabre plugin module
Enterprise Architect connector

System Modules

The AyMINE framework module
System services


Risks are used to record the threats and opportunities that can reverse the course of a project or events in general. The purpose of recording risks is to get them under control.

Threats (risks) and opportunities

A risk is generally defined as anything that can unexpectedly interfere with progress, whether the impact is negative or positive. In common practice, only negative risks – threats – are dealt with, and therefore the term risk is used in the sense of threats. However, risks in AyMINE generally allow opportunities to be tracked as well.

Who monitors risks and when

Risks are most often monitored by the project manager. All project management methodologies (with PMBOK and Prince2 leading the way) require this, but they are not the only ones. Everyone should monitor risks in their work. The obligation to track risks and opportunities is thus part of standards across the board – ISO 9001, ISO 20000, .... CMMI etc. The reason is that if no one is monitoring risks, they will catch the team off guard and they will not be able to react. Conversely, if the risk is anticipated, it is possible to prepare.

Why write down risks

Writing down the risk will not reduce the risk per se, but it will still help significantly, especially for activities involving multiple people:

  • Writing it down facilitates discussion and the team can find solutions to prevent it.
  • If the risk is not written down, it is easy to forget that it needs to be monitored. Cautious team members may be frightened by it, courageous team members will put it behind them; neither approach is optimal. The optimal approach is to watch for it coming and how to counter it.
  • It is possible to monitor the current status
  • It is possible to evaluate how much resources to allocate to prevention

Risk description

In addition to the obvious identifiers and descriptions, risk documentation contains important risk-specific fields:


Probability evaluates how likely it is that the risk will not happen. Risks with low probability do not warrant as much attention as those with high probability. The probability estimate is therefore used to assess how much care should be given to the risk.

The probability rating is used to classify the significance of the risk. The verbal description is optional and is particularly meaningful when the risk is discussed in the team or when required by internal methodology.

The probability rating is expressed in terms that allow quantification of the probability by logical reasoning. If the probability cannot be estimated, a 50:50 midpoint is used.


Threat describes what the risk may cause if it occurs. If the threat of the risk is small, there is no reason to address it. A good knowledge of what it may cause is key to preparing for the risk. At the same time, it is an essential tool for risk prevention. It may not be possible to prevent the risk, but it may be possible to ensure that it does not cause significant damage.

As with probability, threat assessment is used to classify risk.

However, abstract numerical values are usually interpreted by people in teams in their own way (according to their own nature and attitude to the project) and it is therefore preferable to use criteria with a clear meaning. These are set out here by the methodology – in a context outside the company they should be understood analogously to the model used.

Risk recognition

An important tool to eliminate risks is to be able to recognise early that they will occur or that the likelihood of them occurring is significantly increasing. It is therefore important to have the tools to be able to monitor risks. (Common tools are generally unpopular analyses and trend-following statistics.) The field allows you to note what to do to identify risks early.

Recognition methods would not be effective if they were not used. Most quality methodologies prescribe how often they should be monitored and this information can be stored here.

A Risk Threshold is a flag where the risk is considered so high that active intervention is needed. The threshold at which teams and companies pay attention to risk depends on a variety of factors, such as the overall economic stability of the company, the nature of the manager, etc., and can therefore vary from project to project and from year to year.

How the risk threshold is used

The risk threshold (0 .. 30) is compared to the risk rating.

The Risk Rating is the product of the probability (0..5) and the impact (0..5) of the risk. This value (0 ... 25) is then rated against the threshold based on the criteria:

  • 0 = no risk (cannot occur or will not cause anything)
  • 1 ... 4: Negligible risk
  • 5 ... 9: Minor risk
  • 10 .. 14: Significant risk
  • 15 .. 24: Very high risk
  • 25 = Critical risk (Almost certain to occur and have major impacts).

If any of the probability or impact values are not filled in, the risk is considered to be furnished and its rating has a maximum value of 30. Therefore, in the comparison, risks that lack a probability or threat analysis come out as the most risky.

Rating frequency

Risks should be assessed regularly to ensure that they are still relevant. The following should be considered as part of the assessment:

  • Is the risk still as likely to occur?
  • Has the expected impact changed?
    If you revise the risk, it will automatically be considered revised. If you have assessed the risk as still current, the Revised function will confirm the check.

The Rating Frequency field should be left blank unless there are special reasons to fill it in. If no value is filled in, the rating frequency is based on the risk rating:

  • for a rating <20 the check is scheduled after 2 weeks
  • for a rating <25 is 1 week
  • for higher ratings 1 day

If a value is filled in the date of the next assessment is always according to the specified date since the last risk adjustment.

Sample risks

A risk in AyMINE requires a fairly detailed description – naming it is not enough, because then it is obvious that the risk has not been explored. Risks are often repeated in similar projects, usually with different degrees of impact or probability of occurrence. To avoid having to recreate risks each time, an organisation should create a risk catalogue (in the form of a methodology) where it keeps standard risks and selects those that are relevant within a project or other activity. The risk is then filled in automatically based on the template.

The sample risks are part of the methodologies and can be managed by people who have the right to modify the methodologies. (The right to work with the methodologies may not be available to your company or team.)