| 10 | | • Minimize risk and impact of change |
| 11 | | • Highlight dependencies and conflicts through impact analysis |
| 12 | | • Aid in deployment of synchronized change, and make it possible to roll back a whole system to a previous, known, “stable” state, if necessary |
| 13 | | • Increase ability to plan and schedule changes |
| 14 | | • Decrease problem resolution through transparency |
| 15 | | • Maintain autonomy (I.e., group’s ability to make changes) |
| 16 | | • Aid in automated communication between groups (clients & providers) |
| 17 | | • Minimize resource and time commitments to supporting CM processes |
| 18 | | • Provide audit trail of key changes |
| 19 | | Policies |
| 20 | | • Change management procedures encompass all modifications to testing, backup, training and production servers, facilities, applications, networks and infrastructure services |
| 21 | | • Conflicts that cannot be resolved through these CM procedures will be escalated for resolution to the Griffin project team, and if necessary, to the Steering Committee and the Executive Sponsors. |
| 22 | | • Changes made by any group will be visible to all other groups |
| 23 | | • No sensitive information shall be stored in the repository (E.g., files containing passwords) |
| 24 | | • All project-related files (configuration, script or code) edited will be stored in repository |
| 25 | | • All project-related configurations that can be saved to flat files will be stored in repository |
| | 10 | * Minimize risk and impact of change |
| | 11 | * Highlight dependencies and conflicts through impact analysis |
| | 12 | * Aid in deployment of synchronized change, and make it possible to roll back a whole system to a previous, known, “stable” state, if necessary |
| | 13 | * Increase ability to plan and schedule changes |
| | 14 | * Decrease problem resolution through transparency |
| | 15 | * Maintain autonomy (I.e., group’s ability to make changes) |
| | 16 | * Aid in automated communication between groups (clients & providers) |
| | 17 | * Minimize resource and time commitments to supporting CM processes |
| | 18 | * Provide audit trail of key changes |
| | 19 | |
| | 20 | === Policies === |
| | 21 | * Change management procedures encompass all modifications to testing, backup, training and production servers, facilities, applications, networks and infrastructure services |
| | 22 | * Conflicts that cannot be resolved through these CM procedures will be escalated for resolution to the Griffin project team, and if necessary, to the Steering Committee and the Executive Sponsors. |
| | 23 | * Changes made by any group will be visible to all other groups |
| | 24 | * No sensitive information shall be stored in the repository (E.g., files containing passwords) |
| | 25 | * All project-related files (configuration, script or code) edited will be stored in repository |
| | 26 | * All project-related configurations that can be saved to flat files will be stored in repository |
| 28 | | • The individual performing or requesting the change initiates a change request via the ticketing system (The change request shall also specify back-out process) |
| 29 | | • Change request is sent to all approvers (stakeholder authorities) |
| 30 | | • Approvers approve or deny change request with explanation |
| 31 | | • All parties are notified of result of request – denial denotes no further proceedings |
| 32 | | • The change will be added to the change calendar |
| 33 | | • After approval, request must be closed with results within 7 days of approval notification |
| 34 | | • The results of the change will be documented and recorded in the ticketing system |
| 35 | | • Any changes to original request will result in re-approval and re-notification |
| 36 | | • Emergency change requests do not require prior approval, but must have a change request record created for tracking and auditing. |
| | 29 | * The individual performing or requesting the change initiates a change request via the ticketing system (The change request shall also specify back-out process) |
| | 30 | * Change request is sent to all approvers (stakeholder authorities) |
| | 31 | * Approvers approve or deny change request with explanation |
| | 32 | * All parties are notified of result of request – denial denotes no further proceedings |
| | 33 | * The change will be added to the change calendar |
| | 34 | * After approval, request must be closed with results within 7 days of approval notification |
| | 35 | * The results of the change will be documented and recorded in the ticketing system |
| | 36 | * Any changes to original request will result in re-approval and re-notification |
| | 37 | * Emergency change requests do not require prior approval, but must have a change request record created for tracking and auditing. |
| 39 | | • Change Management Meetings will be held weekly if there are change requests |
| 40 | | • A change coordinator will be given the responsibility for overseeing the change management policies and coordinating the processes |
| 41 | | o Facilitate change management meetings |
| 42 | | o Adding all changes to the change calendar |
| 43 | | o Escalating conflicts |
| 44 | | o Reviewing all requests for risk, accuracy and resolution |
| 45 | | • Representative approvers for each area of stakeholders will be identified and confirmed – delegated backup approvers will also be identified |
| 46 | | o Reviewing change requests |
| 47 | | o Allocating resources necessary |
| 48 | | o Resolving outstanding issues before authorizing |
| 49 | | o Reviewing requests for level of detail, risk, impact, technical merit, etc. |
| 50 | | o Providing timely review and authorizations |
| 51 | | • Domain change coordinators |
| 52 | | o Creating change requests |
| 53 | | o Scheduling changes |
| 54 | | o Attending CM meetings |
| 55 | | o Answering questions about requests |
| 56 | | • Change requestors will be given the ability to request changes through the proper procedures |
| 57 | | o Identifying specific changes that need to be made |
| 58 | | o Developing technical procedures required to implement the change |
| 59 | | o Developing technical procedures for backing-out the change, if necessary |
| 60 | | o Evaluating potential risk and impact |
| 61 | | o Adhering to the schedule and scope defined |
| | 40 | * Change Management Meetings will be held weekly if there are change requests |
| | 41 | * A change coordinator will be given the responsibility for overseeing the change management policies and coordinating the processes |
| | 42 | * Facilitate change management meetings |
| | 43 | * Adding all changes to the change calendar |
| | 44 | * Escalating conflicts |
| | 45 | * Reviewing all requests for risk, accuracy and resolution |
| | 46 | * Representative approvers for each area of stakeholders will be identified and confirmed – delegated backup approvers will also be identified |
| | 47 | * Reviewing change requests |
| | 48 | * Allocating resources necessary |
| | 49 | * Resolving outstanding issues before authorizing |
| | 50 | * Reviewing requests for level of detail, risk, impact, technical merit, etc. |
| | 51 | * Providing timely review and authorizations |
| | 52 | * Domain change coordinators |
| | 53 | * Creating change requests |
| | 54 | * Scheduling changes |
| | 55 | * Attending CM meetings |
| | 56 | * Answering questions about requests |
| | 57 | * Change requestors will be given the ability to request changes through the proper procedures |
| | 58 | * Identifying specific changes that need to be made |
| | 59 | * Developing technical procedures required to implement the change |
| | 60 | * Developing technical procedures for backing-out the change, if necessary |
| | 61 | * Evaluating potential risk and impact |
| | 62 | * Adhering to the schedule and scope defined |
