WI-10 Risk
Work Instruction for Risk configuration items
1. Introduction
1.1. Purpose
This Work Instruction provides the tasks required to be performed as part of the Risk configuration item lifecycle.
1.2. Scope
This Work Instruction covers the complete Risk lifecycle, from creation to obsolescence.
1.3. Records and evidence
Records for each Risk will be held based on the records and retention policy. Risks are used to generate the following artifacts:
Change management file
Change request verification report
Risk control matrix
Risk management file
Risk matrix
System requirements specification (relations)
System design specification (relations)
System design specification (with details)
Test plan (relations)
Traceability matrix
1.4. Responsibilities
As listed in the procedure description, each task in the Risk item’s lifecycle will be completed by a member that is part of one of the following approval steps. When any of these members can perform the task, Anyone is listed.
Item Assignee: The person authoring and responsible for the Risk. This organization member is responsible for managing/completing the Risk lifecycle activities. This Item Assignee can change from time to time.
Quality Managers: The person accountable for the Risk. The Quality Manager ensures the Risk is correctly documented.
R&D Leads: The R&D Lead verifies the Risk is technically correct and any risk control measures are executable.
2. Procedure description
2.1. Step 1: Log into Ketryx
Anyone
2.2. Step 2: Create
Anyone
After product-level risk analysis is performed, for example, through a Failure Mode and Effects Analysis (FMEA), users should create a Risk to represent certain risks.
Navigate to the Risks page via the left-hand sidebar.
Define an appropriate title in the Title field. To make the most out of Ketryx, it is recommended to name a Risk after its Hazardous Situation. Should there be multiple identical Hazardous Situations, one should differentiate each Risk item by including the hazard in the title. As an example:
Under Infusion (Electrical hazard)andUnder Infusion (Functional hazard)
Define the item metadata with an appropriate Assignee (the Item Assignee) and Introduced in version.
After saving the item, you will be directed to the item details page, where information about the newly created item will be displayed.
2.3. Step 3: Change status to In Progress
Anyone
You can change the work item status to In Progress, either in Jira or Ketryx.
2.3.1. Transition in Ketryx
Transition an item on the All items page
Navigate to the All items page via the left-hand sidebar.
Transition an item on the Edit risk page
Navigate to the Risks page via the left-hand sidebar.
For the relevant Risk item, click the Edit risk button.
Select In Progress in the State dropdown.
2.3.2. Transition in Jira
2.4. Step 4: Edit the Risk item in Ketryx
Item Assignee
Navigate to the Risks page via the left-hand sidebar.
2.5. Step 5: Add general Risk information
Item Assignee
As needed, fill in the relevant information in the Risk form:
Select one or more System categories.
Select one or more Risk assessment methodologies.
Fill in/select a Harm (based on the project configuration, a harm may prepopulate a pre-defined Initial severity value within the Initial risk analysis section)
Select a Hazard type (based on the project configuration, a hazard type may use a different risk analysis calculation schema).
Fill in the Hazardous situation.
2.6. Step 6: Perform an initial risk analysis
Item Assignee
Set the Initial likelihood of occurrence (P1).
Set the Initial likelihood of harm (P2).
Set the Initial severity (may be pre-selected depending on the Harm provided).
After P1, P2 and severity have been set, the Initial risk evaluation value will be set according to the project's configured risk evaluation matrix. You may override the value if necessary.
An information box is visible next to the Initial risk analysis section for improved comprehension of how the values were derived.
Verify the calculated value for Risk acceptability. If it is Acceptable go to Step 9, otherwise continue with Step 7 to identify potential risk controls.
2.7. Step 7: Add risk controls
Item Assignee
As needed, add some details in the Risk control description field.
Create risk control measure CIs as needed and add them under Risk control measures section by selecting the item in the corresponding dropdown and clicking the Add risk control measures button.
2.8. Step 8: Perform a residual risk analysis
Item Assignee
Set the Residual likelihood of occurrence (P1).
Set the Residual likelihood of harm (P2).
Set the Residual severity.
After P1, P2 and severity have been set, the Residual risk evaluation value will be set according to the project's configured risk evaluation matrix. You may override the value if necessary.
An information box is visible next to the Residual risk analysis section for improved comprehension of how the values were derived.
If the residual risk is still considered Not acceptable, perform a Benefit-risk analysis to ensure the benefit of the product justifies the unacceptable risk, or override the calculated acceptability by selecting Acceptable in the Overall risk analysis section.
If the calculated overall acceptability is overridden, this will be explicitly pointed out on the right-hand side.
Save the changes
2.9. Step 9: Change status to Resolved (Ready for Review)
Anyone
2.10. Step 10: Review as Owner
Item Assignee
Review the Risk to verify:
The Risk is traceable to all other needed items, and all interfaces are defined.
The Risk is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The Risk as a design output conforms to its design input (the items introducing the risk).
2.10.1. Risk approval
Approval in Jira
Access the item in Jira via a link in Ketryx (e.g. in the item details page, risk management page or all items page).
Approval in Ketryx
In Ketryx, risk items can be approved either on the All items page or on the Risk management page.
Approval on the All items page
Navigate to the All items page via the left-hand sidebar.
Approval on the Risk management page
Navigate to the Risks page via the left-hand sidebar.
2.11. Step 11: Review as R&D Lead
R&D Lead
Review the Risk to verify:
The Risk is traceable to all other needed items, and all interfaces are defined.
The Risk is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The Risk as a design output conforms to its design input (the items introducing the risk).
2.12. Step 12: Review as Quality Manager
Quality Manager
Review the Risk to verify:
The Risk is traceable to all other needed items, and all interfaces are defined.
The Risk is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The Risk as a design output conforms to its design input (the items introducing the risk).
2.13. Step 13: Transition to a controlled state
Ketryx
Only Ketryx can move a Risk to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Risk to a Closed state after all approval rules have been passed, i.e., all required steps have approved the Risk.
Ketryx automatically adds a comment to the Jira work item with a link to the effective controlled record in Ketryx.
2.14. Step 14: Change
Item Assignee
Following a Change Request (i.e., the work item needs to be modified), reopen the Risk to create a new record, and go back to Step 3.
2.15. Step 15: Mark as obsolete
Item Assignee
To mark a Risk as obsolete (i.e., as not effective anymore, starting with a given version),
Reopen it for change (Step 14),
Set the version it will be obsolete in (i.e., where the first version that it will not be effective in anymore) in the Obsolete in version field,
Resolve the work item (Step 9),
Approve the item (Steps 10-12).
3. Procedure flow diagram
4. Item schema
Introduced in version (version reference): The first version this risk is effective in. If empty, the risk is considered effective from the start of the project.
Obsolete in version (version reference): The version the risk is becoming obsolete in, i.e., the first version that this risk is not effective anymore.
5. Traceability to other configuration items
The following relations can be defined from a Risk to other configuration items:
Risk is risk-controlled by Test Case, Requirement, Software Item Spec, Hardware Item Spec
The following relations can be defined from other configuration items to a Risk:
Risk is introduced by Requirement, Change Request, Hardware Item Spec, Software Item Spec
Risk is affected by CAPA, Change Request, Anomaly
Risk results from Change Request, CAPA
Last updated
Was this helpful?
