You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/use-cases/risk-management/README.md
+57-49Lines changed: 57 additions & 49 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ Use these official sources alongside this OpenProject configuration guide:
31
31
-[PM² artefacts, including the Risk Management Plan and Risk Log](https://pm2.europa.eu/pm2-artefacts_en)
32
32
-[PM² and PMflex project management with OpenProject](../project-management-pm2-pmflex/)
33
33
34
-
## Recommended structure
34
+
## How risk management looks in OpenProject
35
35
36
36
| Risk management concept | OpenProject entity |
37
37
| --- | --- |
@@ -42,17 +42,68 @@ Use these official sources alongside this OpenProject configuration guide:
42
42
| Review trail | Work package activity, comments and status history |
43
43
| Standard setup | A reusable [project template](../../user-guide/projects/project-templates/)|
44
44
45
-
## 1. Administrator setup
45
+
## 1. Project member workflow
46
+
47
+
Project members use the shared risk register to identify, assess, respond to and monitor risks throughout the project. The following checklist gives a quick overview before the detailed workflow.
48
+
49
+
### Quick checklist for each risk
50
+
51
+
- Describe the risk clearly and assign one owner.
52
+
- Assess probability and impact using the agreed scale.
53
+
- Select a response strategy and assign dated response actions.
54
+
- Set the next review date and document review decisions.
55
+
- Escalate or close the risk when appropriate.
56
+
57
+
### 1.1 Identify and record a risk
58
+
59
+
Create a work package of type `Risk`. Write the subject as a concise cause–event–effect statement, for example: “Because the supplier has not confirmed capacity, hardware delivery may be delayed, which could move the pilot date.”
60
+
61
+
In the description, record the context, assumptions and affected objectives. Select a category and assign a risk owner. The [create work package guide](../../user-guide/work-packages/create-work-package/) describes the available creation flows.
62
+
63
+
### 1.2 Assess the risk
64
+
65
+
The risk owner and relevant specialists agree on probability and impact using the scale defined in the Risk Management Plan. Add supporting evidence in the description or as an attachment, and move the risk to `Assessed` when the assessment is complete.
66
+
67
+
Prioritize risks consistently. A high score should trigger a timely response and, where defined by the organization's thresholds, escalation to the project manager, Project Owner or steering body.
68
+
69
+
### 1.3 Plan and assign the response
70
+
71
+
Select the response strategy and document the intended outcome. Turn concrete actions into child or related work packages, assign each action and give it a due date. Relations preserve traceability between the risk and the work needed to address it; see [work package relations and hierarchies](../../user-guide/work-packages/work-package-relations-hierarchies/).
72
+
73
+
Record both preventive actions and contingency actions where useful. Preventive actions reduce probability or impact before the event; contingency actions define what to do if it occurs.
74
+
75
+
### 1.4 Monitor and review
76
+
77
+
Review active risks regularly in a project meeting or dedicated risk review. For each risk:
78
+
79
+
1. Check whether probability, impact and assumptions have changed.
80
+
2. Review the progress and effectiveness of response actions.
81
+
3. Update the next review date.
82
+
4. Reassess probability and impact based on current information and the effectiveness of response actions.
83
+
5. Escalate when a threshold is exceeded or a decision is required.
84
+
6. Close risks that no longer require active monitoring.
85
+
86
+
Use comments for decisions and concise review notes. The work package activity provides a chronological audit trail. See [edit work packages](../../user-guide/work-packages/edit-work-package/) for updating fields, status and comments.
87
+
88
+
### 1.5 Handle an occurred risk
89
+
90
+
When the uncertain event happens, it is no longer only a risk. Mark it as `Occurred` if that status is part of the workflow, create or link an issue or task, and carry over the relevant owner, impact, response and due dates. Keep the relation between the original risk and the resulting issue so the decision trail remains visible.
91
+
92
+
### 1.6 Report and learn
93
+
94
+
Use the active register and attention view for status reporting. At phase gates and project closure, review closed and occurred risks to identify recurring causes, effective responses and improvements for future project templates or the Risk Management Plan.
95
+
96
+
## 2. Administrator setup
46
97
47
98
The following configuration is normally created once and then reused across projects. Administrators should agree the terminology, scales and workflow with the organization's project management office before configuring them.
48
99
49
-
### 1.1 Create and activate the `Risk` work package type
100
+
### 2.1 Create and activate the `Risk` work package type
50
101
51
102
Create a work package type named `Risk` under **Administration → Work packages → Types**. Add the fields needed for assessment, response and review to its form. See [work package types](../../system-admin-guide/manage-work-packages/work-package-types/) for configuration details.
52
103
53
104
Activate the type for the relevant projects under **Project settings → Work packages → Types**. The same project settings also control which custom fields are active in a project; see [project work package settings](../../user-guide/projects/project-settings/work-packages/).
54
105
55
-
### 1.2 Define risk fields
106
+
### 2.2 Define risk fields
56
107
57
108
Create the required fields under **Administration → Custom fields → Work packages**. The following baseline works well for many teams:
58
109
@@ -65,15 +116,13 @@ Create the required fields under **Administration → Custom fields → Work pac
65
116
| Response strategy | List | Records the chosen approach, for example avoid, reduce, transfer/share or accept |
66
117
| Response description | Long text | Describes the concrete preventive and contingency actions |
67
118
| Next review date | Date | Ensures that the risk is reconsidered at an agreed time |
68
-
| Residual probability | List | Records likelihood expected after the response |
69
-
| Residual impact | List | Records impact expected after the response |
70
119
| Escalation required | Boolean | Flags risks that require a governance decision |
71
120
72
121
See [custom fields](../../system-admin-guide/custom-fields/) for the available field types and configuration options.
73
122
74
123
Use one consistent scale across projects. If the organization uses a 1–5 scale, define in the Risk Management Plan what each probability and impact value means. Until calculated fields are available, record the score explicitly or group/filter the register by probability and impact; do not imply that OpenProject calculates `probability × impact` automatically.
75
124
76
-
### 1.3 Configure statuses and workflows
125
+
### 2.3 Configure statuses and workflows
77
126
78
127
A small workflow is usually easier to maintain than a highly detailed one. For example:
79
128
@@ -87,7 +136,7 @@ Optionally add `Occurred` when a realized risk must be handed over to issue mana
87
136
88
137
Restrict sensitive transitions where appropriate. For example, only the project manager or risk manager may accept a high risk or close an escalated risk. Configure the corresponding rights under [roles and permissions](../../system-admin-guide/users-permissions/roles-permissions/).
89
138
90
-
### 1.4 Prepare reusable views and a project template
139
+
### 2.4 Prepare reusable views and a project template
91
140
92
141
Create and save at least these shared work package views:
93
142
@@ -99,47 +148,6 @@ The [work package table configuration](../../user-guide/work-packages/work-packa
99
148
100
149
Finally, include the type, fields, permissions and saved views in a [project template](../../user-guide/projects/project-templates/) so new projects start with the same risk management structure.
101
150
102
-
## 2. Project member workflow
103
-
104
-
### 2.1 Identify and record a risk
105
-
106
-
Create a work package of type `Risk`. Write the subject as a concise cause–event–effect statement, for example: “Because the supplier has not confirmed capacity, hardware delivery may be delayed, which could move the pilot date.”
107
-
108
-
In the description, record the context, assumptions and affected objectives. Select a category and assign a risk owner. The [create work package guide](../../user-guide/work-packages/create-work-package/) describes the available creation flows.
109
-
110
-
### 2.2 Assess the risk
111
-
112
-
The risk owner and relevant specialists agree on probability and impact using the scale defined in the Risk Management Plan. Add supporting evidence in the description or as an attachment, and move the risk to `Assessed` when the assessment is complete.
113
-
114
-
Prioritize risks consistently. A high score should trigger a timely response and, where defined by the organization's thresholds, escalation to the project manager, Project Owner or steering body.
115
-
116
-
### 2.3 Plan and assign the response
117
-
118
-
Select the response strategy and document the intended outcome. Turn concrete actions into child or related work packages, assign each action and give it a due date. Relations preserve traceability between the risk and the work needed to address it; see [work package relations and hierarchies](../../user-guide/work-packages/work-package-relations-hierarchies/).
119
-
120
-
Record both preventive actions and contingency actions where useful. Preventive actions reduce probability or impact before the event; contingency actions define what to do if it occurs.
121
-
122
-
### 2.4 Monitor and review
123
-
124
-
Review active risks regularly in a project meeting or dedicated risk review. For each risk:
125
-
126
-
1. Check whether probability, impact and assumptions have changed.
127
-
2. Review the progress and effectiveness of response actions.
128
-
3. Update the next review date.
129
-
4. Reassess residual probability and impact.
130
-
5. Escalate when a threshold is exceeded or a decision is required.
131
-
6. Close risks that no longer require active monitoring.
132
-
133
-
Use comments for decisions and concise review notes. The work package activity provides a chronological audit trail. See [edit work packages](../../user-guide/work-packages/edit-work-package/) for updating fields, status and comments.
134
-
135
-
### 2.5 Handle an occurred risk
136
-
137
-
When the uncertain event happens, it is no longer only a risk. Mark it as `Occurred` if that status is part of the workflow, create or link an issue or task, and carry over the relevant owner, impact, response and due dates. Keep the relation between the original risk and the resulting issue so the decision trail remains visible.
138
-
139
-
### 2.6 Report and learn
140
-
141
-
Use the active register and attention view for status reporting. At phase gates and project closure, review closed and occurred risks to identify recurring causes, effective responses and improvements for future project templates or the Risk Management Plan.
0 commit comments