Administering the application
Customization of the application for your organization is accomplished through several administration pages.
Accessing the administration pages
Select the gear icon in the top right-hand of the screen and then select Apps. The Risk Register App menu appears in the left-hand panel with these links:
Each link is described below.
This page appears when you install the application. It describes the various steps you must undertake to initialize the application for use. It is primarily a prompt to remind you to configure the pages described below.
This page enables you to configure the appearance and behavior of the application. The following configuration options are available:
Risk (issue) types
These drop-down menus determine when and how various options are presented to users:
Note the following:
If an issue has a risk assessment attached to it, that issue will appear in any risk register based on those projects or filters that include the issue (though a sub-filter can be used to exclude it).
If the issue is of the primary risk type, then it always has a risk assessment attached to it. In the example above, issues of type Story will always appear in a risk register.
New issues that are one of the supplementary risk types don’t have risk assessments attached to them by default, but you are able to add risk assessments to them. You can define the supplementary risk types by inclusion or exclusion using the Only and All except options. In the example above, you will be able to add a risk assessment to issues of type Task.
If an issue is neither of the primary risk type nor one of the supplementary risk types, then it’s not possible to add a new risk assessment to it.
If an issue was once a primary risk type, or if it was once a supplementary risk type and the user added a risk assessment to it, then it will continue to appear in relevant risk registers even if the project/app settings are changed so that it no longer is of the primary risk type nor a supplementary risk type.
- The primary risk type and supplementary risk types defined here represent defaults. Individual projects can override these defaults.
This drop-down allows you to nominate an issue link type that defines how treatments are connected to risks. When this relationship is defined, treatments will appear beneath risks on the risk register page. If you leave the field blank, then treatments will not appear on the risk register page.
Users typically use this feature to record the treatment plans they have defined for their risks. Recording treatment plans in separate issues will enable you to quickly reference them in the main risk register view. It also enables you to track a separate priority and status for each treatment, and gives you auditing via Jira's issue history log.
You can choose to use any issue link type that has been defined in your Jira Cloud instance; however, the following link type is recommended:
Inward relationship: is treated by
Outward relationship: treats
If your Jira instance does not already have an issue link type named Treatment, then Risk Register will offer to create one for you as defined above.
Note that in Jira Cloud, you can disable issue linking. If issue linking is disabled in Jira, then a warning message is displayed on the app settings page.
Risk matrix appearance
This section allows you to control the risk matrix appearance. The Color of empty cells option determines whether empty cells on the risk matrix are filled with gray or with the appropriate risk color.
Old releases had an option to "enable" risk management. With the current release, users no longer explicitly enable risk management, neither at the app level nor at the project level. Whereas enabling risk management for a project previously generated an 'implicit' risk register, that is no longer the case. Instead, you explicitly create the risk registers that you want. For customers using the older version, any implicit risk registers were converted to explicit risk registers for any projects that had risk management enabled at the project level (overriding the app settings), or which contained one or more risks.
A risk model defines the impact levels and probability levels that the application uses to assess risks. This page lists the risk models defined for your Jira instance.
There is one default risk model configured when you install the app. You can edit that risk model to shape it according to the standards followed by your organization. In addition to the default risk model, you can create as many project-specific risk models as you like. In each case, you nominate the projects to which the risk model applies. Using project-specific risk models, your organization can manage risk differently between projects or groups of projects. Each risk model can be assigned to multiple projects, but a project can only have one risk model. A project that does not have a project-specific risk model assigned will use the default risk model.
Clicking on the Add a risk model button creates a new project-specific risk model for you, using the default risk model as a template.
Risk model editing
Clicking on a risk model opens up the risk model editing screen. The top portion of the screen is shown here:
The Clone button creates a new risk model that is configured the same way as the current model. If you clone a project-specific risk model, the result is a new risk model that has a name derived from the original (the name of the original risk model with “- copy” appended). The new risk model is not assigned to any projects by default. You must edit the new risk model to rename it, assign it to projects, and make whatever other changes are required. The changes that you make to the new risk model do not affect the original risk model.
The Delete button (the small trash can icon) deletes the current risk model. You cannot delete the default risk model.
The Name of the risk can contain special characters, but it must be unique.
The Projects field defines which projects in your Jira instance are associated with this risk model. Whenever you create a risk in one of those projects, it will use this model to calculate the risk level.
The Risk matrix defines the risk levels that result from combinations of impact and probability levels. You can think of a risk model as a rules engine for your risk assessments. For example, in the above matrix, if impact is High and Probability is Likely, then the risk level is Medium. Clicking on any of the cells changes the risk level in that cell.
The Flip button swaps the impact and probability axis on the risk matrix.
Levels of risk
Below the risk matrix is the Levels of risk list, which displays all of the risk levels associated with this model.
The drag handles (the double-horizontal lines) enable you to shift the order of the risk levels.
The Add level of risk button creates a blank risk level.
Clicking on the down-arrow enables you to edit details of the risk level.
The risk level Name can contain special characters.
The Description defines the tool tip information that is displayed when editing risk assessments.
The Color picker allows you to define the color associated with this risk level. This color is displayed prominently throughout the system.
The Delete this level of risk button removes the risk level. You must have at least one risk level.
Impacts and Probability
Below the levels of risk list are the Impacts and Probabilities lists.
The drag handles (the double-horizontal lines) enable you to shift the order of the impacts or probabilities.
The Add impact and Add probability buttons create blank entries in their respective lists. Changing the number of entries in the list automatically changes the dimensions of the risk matrix.
Clicking on the down-arrow enables you to edit details of an impact or probability.
The Name can contain special characters.
The Description contains additional information about the impact or probability.
The Delete... button removes the entry from the list. You must have at least one probability and one impact in your risk model.
The effects of changing risk models
Any changes that you make to a risk model automatically propagate to risk assessments via risk harmonization.
- If you change the configuration of a project-specific risk model, any risks contained by the projects assigned to that risk model will be re-harmonized.
- If you change the configuration of the default risk model, any risks contained in projects that are not assigned to any project-specific risk models will be re-harmonized.
- If you add a project to a project-specific risk model or remove a project from a project-specific risk model, all of the risks in that added/removed project will be re-harmonized.
Note that any changes to risk assessments arising from re-harmonization will occur in the background. The process usually takes just a few seconds, but can take longer if your Jira instance contains many projects and/or many risks.
This page enables you to change generic Risk Register terms, allowing you to customize these to conform to your organizational norms. You can use non-English words if you wish.
Click Change terminology to edit these terms, which will be replaced in the risk register and matrix view, on the risk assessment panel, and in the cloud gadget.
This page tells you how many cloud migrations have happened to this instance.
Clicking on this link opens up the ProjectBalm support portal, which allows you to search our knowledge base and also raise a service request.