1.Document Overview
1.1Purpose and Scope
This document establishes the procedures for managing changes on Caradigm Services Implementation projects. It defines a process for requesting changes to project schedules, cost, resources, and documentation. It also describes the necessary controls required to document, approve and track these changes.
The Scope of this procedure is any change that affects design artifacts or “batch” (Design Inputs, Outputs, Verification, Validation, or Transfer Artifacts) which must follow the change control process.
This document was written for use by members of Caradigm Services implementation teams.
1.2Parent document
∙Caradigm Quality Manual
∙Caradigm Implementation Methodology Overview
1.3Related References
∙Document Control Procedure
∙Design Control Procedure
∙Risk Management Work Instruction
∙Risk Management Log Template
∙Change Request Template
∙Change Control Register
1.4Terminology
The following terms occur in Caradigm Methodology documents.
TERM
DEFINITION
Batch
For Caradigm Services, a “batch” is the deliverable as designed and configured.
Change Control
A Change Control Procedure is required for all changes that can potentially impact design, including any design planning, input, output, Verification, Validation, or artifact. Design planning encompasses resources, capabilities, cost or schedule. Formal deliverables are to be under Change Control once baselined or approved.
Change Request (CR)
A change request is used to handle potential changes to capabilities, processes, and design documents (inputs, outputs, Verification, Validation, and artifacts).
Change Order (CO)
The term “Change Order” is synonymous & interchangeable with Change Request (see above).
Device History Record
(DHR)
The Quality Management System’s Device History Record stores an archive of changes that occur during the Services implementation project.
Governance Board
The Caradigm Governance Board provides representation for Best Practices, Engineering, Clinical, Portfolio Management, Compliance, and Methodology.
Schedule
A Microsoft Project file (.MPP) which contains tasks required to complete the project from start to finish.
Scope
Scope is defined in formal project deliverables throughout the project lifecycle. Examples include: Vision and Scope; Requirements Specifications Document; Project Plan; and Project Charter.
2.Change Control Process
2.1.1Introduction
An effective Change Control procedure is critical to successful project completion. It will help keep the project within its scope, schedule, and budget.
For Caradigm, an effective Change Control procedure will:
∙Facilitate communication about requested changes amongst the project and business stakeholders
∙Provide a common process and escalation path for resolving requested changes
∙Reduce the uncertainty around the existence, state, and outcome of a change that has been requested
2.1.2Scope
This document establishes the procedure for change control in Caradigm Implementations. It details how to request changes to project schedules, cost, resources, and artifacts. It also describes the controls required to document, approve and track any changes. The Scope of this procedure is any change that affects design artifacts or “batch” (Design Inputs, Outputs, Verification, Validation, and Transfer Artifacts) which are under change control.
2.2Roles and Responsibilities
The PMO manages the Change Control procedure and ensures that Change Requests are properly reviewed throughout the project lifecycle. Major roles are described below.
ROLES
RESPONSIBILITIES
Requestor
∙Identifies an area of change to be addressed by the project
∙Documents issue driving need for change
∙Makes an assessment on magnitude of change
Project Manager (EM)
∙Collection point for every project team Change Request (CR)
∙Reviews CR for completeness
∙Identified impacted project documentation (plan, budget, etc.)
∙Determines magnitude of Change Request to project
∙Presents CR to project team for review and impact consideration
validation verification∙Escalates CR is beyond project team scope of approval
∙Communicates Change Request outcome to project team
∙Revaluates impacted schedule/resources and deliverables upon approval of a scope change
∙Responsible for executing the requested change, as appropriate
∙Updates documentation after Review/approved/rejected
Program Management Office (PMO)
∙Owns the Change Control procedure
∙Facilitates the procedure for escalations to the Governance Board and Caradigm Leadership
∙Communicates the scope change decisions to Stakeholders
Project Core Team
(PC)
∙Review and approve or reject all low-impact Change Requests
∙Medium or High impact CRs will be escalated to the Governance Board for review
Governance Board
∙Escalation point (From project core team) for all medium-impact Change Requests
∙Approached for guidance if the medium impact CR has been rejected and requestor escalates
Caradigm Leadership
∙Escalation point above Governance Board for high/material impact CRs
∙Approached for guidance if the high impact CR has been rejected and requestor escalates

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。