Change Management Process
manager will be required to ensure that the status of the change is understood at key points in the project. The RFC will also be prioritised so that guidance is given for the use of resources across multiple changes. 2.4.6
Co-ordinate Change Build and Test
Once authorised, the change will be passed to the relevant team to build and test. For programming changes this may involve the creation or amendment of code and associated system and integration testing within separate test environments. For technical configuration changes, the build and test stage may consist of making such changes within a test server or network if available. The team building and testing the change will liaise with change management and report the status of the change on a regular basis. Once ready for deployment they will inform the change manager. 2.4.7
Authorise Change Deployment
Once completed, the test results from the previous stage will be reviewed by the relevant change authority. Peer technical reviews may be requested where appropriate. Authorisation will be given for the change to be implemented in a specific way and at a specific date and time. If these conditions cannot be met at the time of implementation, the change should be referred back to the change authority for reauthorisation for deployment. 2.4.8
Co-ordinate Change Deployment
For releases (i.e. groups of change implemented together), the implementation will be co-ordinated via the release and deployment management process. For individual changes change management will provide co-ordination. The change should be implemented at the agreed date and time and within the authorised scope. Post-implementation testing will be carried out to check that the implementation was successful. If the change is not successful then further actions will depend upon the actual effect of the change. The default situation will be that the change is backed out according to the agreed back-out plan but in some circumstances it may be appropriate to raise an additional RFC to correct failed aspects of the previous one. Any such RFCs raised must go through the change management process as described here.
Version 1
Page 14 of 35
Insert date Powered by CertiKit