Full Change Management functionality

[daragh@…]

It would be great to use this system to handle config change requests, deployment requests, etc. as well as defects/enhancements. This may require the addition of a field or two, and it would be nice to have some sort of strong (automated) link with SVN, so that there is impact-type information w.r.t. what files were changed to resolve what ticket.

In the interests of full disclosure, the following is what we'd love to be able to support using Trac.

Definition

The purpose of change management (CM) is to minimize the risk and impact of change to an organization. A CM system is used to notify all the appropriate people (clients, support, operational, management, technical, etc.) of planned changed. CM is necessary for changes resulting from internal updates (new development or documentation), vendor-initiated changes (upgrades) and re-configuration.

Goals

The goal of Change Management is to:

• Minimize risk and impact of change
• Highlight dependencies and conflicts through impact analysis
• Aid in deployment of synchronized change, and make it possible to roll back a whole system to a previous, known, “stable” state, if necessary
• Increase ability to plan and schedule changes
• Decrease problem resolution through transparency
• Maintain autonomy (I.e., group’s ability to make changes)
• Aid in automated communication between groups (clients & providers)
• Minimize resource and time commitments to supporting CM processes
• Provide audit trail of key changes

Policies

• Change management procedures encompass all modifications to testing, backup, training and production servers, facilities, applications, networks and infrastructure services
• 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.
• Changes made by any group will be visible to all other groups
• No sensitive information shall be stored in the repository (E.g., files containing passwords)
• All project-related files (configuration, script or code) edited will be stored in repository
• All project-related configurations that can be saved to flat files will be stored in repository

Change Request Procedure

• The individual performing or requesting the change initiates a change request via the ticketing system (The change request shall also specify back-out process)
• Change request is sent to all approvers (stakeholder authorities)
• Approvers approve or deny change request with explanation
• All parties are notified of result of request – denial denotes no further proceedings
• The change will be added to the change calendar
• After approval, request must be closed with results within 7 days of approval notification
• The results of the change will be documented and recorded in the ticketing system
• Any changes to original request will result in re-approval and re-notification
• Emergency change requests do not require prior approval, but must have a change request record created for tracking and auditing.

Administration

• Change Management Meetings will be held weekly if there are change requests
• A change coordinator will be given the responsibility for overseeing the change management policies and coordinating the processes
  • Facilitate change management meetings
  • Adding all changes to the change calendar
  • Escalating conflicts
  • Reviewing all requests for risk, accuracy and resolution
• Representative approvers for each area of stakeholders will be identified and confirmed – delegated backup approvers will also be identified
  • Reviewing change requests
  • Allocating resources necessary
  • Resolving outstanding issues before authorizing
  • Reviewing requests for level of detail, risk, impact, technical merit, etc.
  • Providing timely review and authorizations
• Domain change coordinators
  • Creating change requests
  • Scheduling changes
  • Attending CM meetings
  • Answering questions about requests
• Change requestors will be given the ability to request changes through the proper procedures
  • Identifying specific changes that need to be made
  • Developing technical procedures required to implement the change
  • Developing technical procedures for backing-out the change, if necessary
  • Evaluating potential risk and impact
  • Adhering to the schedule and scope defined

[daragh@…]

ug - the formatting came out horrible - I can email a nice copy to whomever.

[Christopher Lenz]

This request isn't really specific enough. I think you can do a lot of this stuff with custom ticket fields in 0.8 (although that doesn't include custom workflow or anything that fancy).

Please try to outline the specific features that Trac is missing for your purposes.

[Christian Boos]

(reformatted the original description, which was unreadable)

[Emmanuel Blot]

(restoring original status)

[Alec Thomas]

Please leave this ticket closed unless you have specific complaints with Trac 0.11, which includes customisable WorkFlow.