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

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.
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).

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).

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).

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