Change Control Documentation Policy
|Policy Title||Change Control Documentation Policy (AIS)|
|Responsible Executive||Vice President for Information Technology and CIO Jay Dominick|
|Responsible Office||Office of Information Technology
Administrative Information Services
|Contact||Colin Currie; (609) 258-8193|
|Effective Date||July 1, 2013|
|Last Update||July 29, 2013|
I. Policy Statement
Administrative Information Services strives to deliver applications that provide the highest level of reliability and service to our Customers. Part of maintaining this high level of service is properly documenting change control events performed on applications, for both planned migration events and emergency migration events. Proper change control event documentation provides for accountability, transparency, and knowledge sharing, for both AIS and our Customers. This Change Control Documentation Policy illustrates appropriate documentation proecdures for both planned migration events and emergency migration events.
Planned Migration Event – Documentation Procedure
Any planned migration event should be fully documented. Any relevant specifications pertaining to a planned migration event should be submitted in writing by the Customer, preferably through the University's OIT ticketing system, OPM. If submission through OPM is not possible, any written form of specifications will be sufficient. At a minimum, submissions to AIS should be submitted through email.
If a planned migration event's specifications are not submitted to AIS through OPM, AIS should document these specifications in OPM. Any other relevant information about the planned migration event should be documented in OPM.
Before a planned migration event's changes are moved to the application’s production instance, written approval from the requesting Customer must first be obtained by AIS. In other words, Customers must sign-off, in writing, that a planned migration event’s changes can be implemented in the application’s production instance. This written approval must then be entered in, or cross-referenced to, OPM before the planned migration event’s changes are implemented in the application’s production instance.
Once the changes are migrated, the customer will then give written confirmation that the new functionality meets the requirements as described in the specifications. Any information gathered after the changes are implemented in the application’s production instance should also be added to the original OPM Change Control Queue and the ticket is closed.
Emergency Migration Event – Documentation Procedure
Any emergency migration event should also be fully documented. Initiating an emergency migration event begins with the customer completing the Production Control Emergency Migration Form. [http://oitdas.princeton.edu/forms/EMigReq.php]
Completing this form will trigger an OPM ticket which will then be reviewed by the appropriate AIS application manager. Once the AIS application manager has verified that the request was initiated by an authorized user, and that the request is indeed an emergency, AIS will implement the requested change in the necessary production and/or nonproduction instance(s).
Once the changes are migrated, the customer will then give written confirmation taht the new functionality meets the requirements as described in the specifications. Any information gathered after the changes are implemented in the application's production instance should also be added to the original OPM ticket. Once this is completed, the ticket will be moved to the appropriate OPM Change Control Queue and the ticket is closed.
IV. Who is Affected by this Policy
All Princeton University faculty, staff and students are affected by this policy.
There is no content for this section.
VI. Related Policies
There is no content for this section.
VII. Update Log
Date: Policy issued.
June 26, 2012: Policy updated.