WI-08 Change Request
Work Instruction for Change Request configuration items
1. Introduction
1.1. Purpose
This Work Instruction provides the tasks required to be performed as part of the Change Request configuration item lifecycle.
1.2. Scope
This Work Instruction covers the complete change request lifecycle. Records for each change request will be held based on the records and retention policy. For a complete description of change management, please refer to MAN-01 Ketryx Lifecycle Management.
1.3. Records and evidence
Records for each Change Request will be held based on the records and retention policy. Change Requests are used to generate the following artifacts:
Change management file
Change request verification report
Test plan
1.4. Definitions and Acronyms
CI - Configuration Item
1.5. Responsibilities
As listed in the procedure description, each task in the Requirement 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 Change Request. This organization member is responsible for managing/completing the Change Request lifecycle activities. This Item Assignee can change from time to time.
Product Managers: The person accountable for the Change Request. This organization member leads the product development and defines requirements. The Product Manager is accountable for the Change Request meeting customer demands.
R&D Leads: The person that verifies the Change Request is executable. The R&D Lead is consulted to approve that the Change Request is actionable.
Quality Managers: The person that verifies the Change Request is correctly documented. The Quality Manager is consulted to approve the Change Request is correctly documented.
2. Procedure description
2.1. Step 1: Log into Jira
Anyone
Log into your Jira organization, e.g., your-company.atlassian.net.
2.2. Step 2: Create a Change Request
Anyone
Define an appropriate title in the Summary field.
Define an appropriate Assignee (the Item Assignee).
Provide additional preliminary information in the extra fields. (All fields can still be edited later.)
Press the Create button at the end of the form to finalize the creation of the new Jira issue.
2.3. Step 3: Navigate to the issue page
Anyone
Using the popover shown by Jira or through other means, navigate to the Jira page of the Change Request.
2.4. Step 4: Change status to In Progress
Anyone
Change the issue status to In Progress using the issue status selector.
2.5. Step 5: Describe the change
Item Assignee
In the description field of the Change Request, provide an explanation of the purpose of the change.
2.6. Step 6: Describe the impact of the change
Item Assignee
Describe the impact of this change using the Impact of change field. The description should answer and describe the following points:
What are the potential impacts and risks of this change?
What related systems and components would be affected?
What are the risks associated with this change? What adverse events can happen?
Consult Subject Mater Experts on the change. If unsure about the impact, refer to the expertise of an expert.
2.7. Step 7: Describe the reason for the change
Item Assignee
Describe why the change is necessary and whether the benefit is worth the risk in the Reason for Change text field.
2.8. Step 8: Add introduced risks
Item Assignee
If any, add related risks that would emerge or are affected by this change in the Introduced risks field.
2.9. Step 9: Add new items
Item Assignee
If any, add in the New items field any items created as a result of this change.
2.10. Step 10: Add affected items
Item Assignee
If any, add in the Affected Items field any items affected by this change.
2.11. Step 11: Specify the type of change
Item Assignee
Select in the Change type field the nature of this change.
2.12. Step 12: Select the version
Item Assignee
Select in which version this change should be introduced.
2.13. Step 13: Change status to Resolved (Ready for Review)
Anyone
Once the Change Request is completed and ready for verification, change its status to Resolved.
2.14. Step 14: Review as Owner
Item Assignee
Review the Change Request to verify:
The Change Request is traceable to all other needed items, and all interfaces are defined.
The Change Request is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Change Request) conforms to the design input (the Change Request’s Introduced risks, Affect items, and New items).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Change Request and continue to Step 15.
2.15. Step 15: Review as R&D Lead
R&D Lead
Review the Change Request to verify:
The Change Request is traceable to all other needed items, and all interfaces are defined.
The Change Request is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Change Request) conforms to the design input (the Change Request’s Introduced risks, Affect items, and New items).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Change Request and continue to Step 15.
2.16. Step 16: Review as Quality Manager
Quality Manager
Review the Change Request to verify:
The Change Request is traceable to all other needed items, and all interfaces are defined.
The Change Request is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Change Request) conforms to the design input (the Change Request’s Introduced risks, Affect items, and New items).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Change Request and continue to Step 15.
2.17. Step 17: Review as Product Manager
Product Manager
Review the Change Request to verify:
The Change Request is traceable to all other needed items, and all interfaces are defined.
The Change Request is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Change Request) conforms to the design input (the Change Request’s Introduced risks, Affect items, and New items).
If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Change Request and continue to Step 15.
2.18. Step 18: Transition to a controlled state
Ketryx
Only Ketryx can move a Change Request to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Change Request to a Closed state after all approval rules have been passed, i.e., all required steps have approved the Change Request.
Ketryx automatically adds a comment to the Jira issue with a link to the effective controlled record in Ketryx.
3. Procedure flow diagram
4. Item schema
Description (rich text): The Change Request description. Change Requests should be Specific, Measurable, Achievable, Realistic, Testable (SMART).
Change type (multi-choice): May be either Perfective, Adaptive, Corrective, Preventive.
Reason for change (rich text): Describes the reason for this change.
Impact of change (rich text): Describes the impact of this change.
Introduced risks (-> Risk): Lists the risks introduced by this change.
Affected items (-> Requirement, Software Item Spec, Hardware Item Spec, Test Case, Risk, Configuration Item, CAPA, Anomaly, Change Request): Items affected by this change.
New items (-> Requirement, Software Item Spec, Hardware Item Spec, Test Case, Risk, Configuration Item, CAPA, Anomaly, Change Request): Items resulting from this change.
5. Traceability to other configuration items
The following relations can be defined from a Change Request to other configuration items:
Change Request introduces risk Risk
Change Request affects CAPA, Change Request, Anomaly, Configuration Item, Risks, Hardware Item Spec, Requirement, Software Item Spec
Change Request results in CAPA, Software Item Spec, Change Request, Anomaly, Requirement, Risks, Hardware Item Spec, Configuration item
The following relations can be defined from other configuration items to a Change Request:
Change Request is implemented by Task
Change Request is affected by CAPA, Change Request, Anomaly
Change Request is tested by Test Case
Change Request results from Change Request, CAPA
Change Request resolves Anomaly, Complaint
Last updated
Was this helpful?
