Edgewall Software

Changes between Initial Version and Version 5 of Ticket #574


Ignore:
Timestamp:
Sep 13, 2005, 7:10:46 PM (14 years ago)
Author:
Christian Boos
Comment:

(reformatted the original description, which was unreadable)

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #574

    • Property Status newclosed
    • Property Resolutioninvalid
  • Ticket #574 – Description

    initial v5  
    88=== Goals ===
    99The goal of Change Management is to:
    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
    2627
    2728=== Change Request Procedure ===
    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.
    3738
    3839=== Administration ===
    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