WI-08 Change Request
Work Instruction for Change Request configuration items
Last updated
Was this helpful?
Work Instruction for Change Request configuration items
Last updated
Was this helpful?
This Work Instruction provides the tasks required to be performed as part of the Change Request configuration item lifecycle.
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 .
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
CI - Configuration Item
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.
Anyone
Log into your Jira organization, e.g., your-company.atlassian.net.
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.
Anyone
Using the popover shown by Jira or through other means, navigate to the Jira page of the Change Request.
Anyone
Change the issue status to In Progress using the issue status selector.
Item Assignee
In the description field of the Change Request, provide an explanation of the purpose 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.
Item Assignee
Describe why the change is necessary and whether the benefit is worth the risk in the Reason for Change text field.
Item Assignee
If any, add related risks that would emerge or are affected by this change in the Introduced risks field.
Item Assignee
If any, add in the New items field any items created as a result of this change.
Item Assignee
If any, add in the Affected Items field any items affected by this change.
Item Assignee
Select in the Change type field the nature of this change.
Item Assignee
Select in which version this change should be introduced.
Anyone
Once the Change Request is completed and ready for verification, change its status to Resolved.
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.
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.
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.
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.
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.
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.
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
Press the Create button in the top-level navigation to open the form to create a new Jira issue.
Ensure the desired project is selected, and select the Issue type "Change Request". If that does not appear, check with your system administrator to ensure your project is connected to Ketryx.
