Change Control
Change control requires a systematic approach to dealing with improvements to the system, whether they are instigated by external suppliers, such as in the release of software patches, or internal stakeholders, such as in effecting resolution to specific problems or introducing enhancements to functionality.
Normal change control mechanisms will, for example, keep track of the details of the software version currently running and the patches that have been applied. However, some business requirements may require changes outside the technical capability of the system. Even during the implementation and certainly after go-live, procedures will be required to enable anyone to request a system and/or process change, and others to evaluate, reject or approve, introduce and control the implementation of those changes with minimum disruption to the service provided.
There will be ways in which the institution can accommodate some change requests by customising the system with tools provided with the system, but the degree of customisation should be carefully managed and wholesale requests for bespoke requirements must be resisted as often as possible.
The tools for customising the system may come in the form of simple methods of amending screen layouts or system parameters or complex and powerful proprietary or industry-standard programming languages. Whether the customisation is done by the system supplier or IT Services will depend on the nature of the requirement, the suitability of the tools provided, the skills and availability of IT Service staff, the organisation’s policy on customisations and the level of approval given or cost quoted by the supplier.
Certainly, it should be noted that changes made to the programming code or the database structure in one part of the system often affects other parts. This makes fixing some problems easy, but changing code to fix one part of the system more often produces problems in another part. Consequently, changes to the software must be made serially, be accompanied by comprehensive and detailed documentation and be thoroughly tested carefully for unexpected consequences before they can be made available for live operation. All users should, therefore, fully understand the complexities involved in resolving problems and controlling change. Where organisations do plan to make their own customisations, it is vital that software source code control procedures are in place.
As mentioned above in respect of problems raised by users via the Helpdesk/Advice Centre, all requests for changes in the system or business processes raised by users or other parties, whether technical or procedural in nature, must be subject to strict change control procedures and must be entered on the change log. Again the JISC infoNet Project Controls database could be used for this purpose.
Originators of the change requests should always provide enough detail to enable the proper evaluation of the matter.
The support team should be made responsible for maintaining the integrity of the system and, by implication, the integrity of the issue log. All change proposals and initiatives, and progress chasing and follow-up procedures must be managed via the log and no independent actions that affect the integrity of the system can be tolerated.
Further, it is important that the log should be used only to reflect issues of importance to the maintenance and on-going development of the system and does not become a dumping ground for vague complaints, or merely an aide memoire for regular housekeeping activities. Essentially, the log should focus on areas of the system which do not work effectively and requests for system or processing enhancements.
All technical changes to the system must be controlled and no changes should be made to the system environments without supporting documentation and approval. The supporting documentation must state all known impacts on the system and there should also be a clearly defined plan for recovery if applicable and necessary. No system changes should be implemented without prior back-ups having been taken and verified.
Software upgrades and patches should be handled through the same procedures. Customised software alterations must be submitted to the supplier for final approval to ensure that the warranty is not compromised in any way. It should be noted that approval of the software change may not imply that the supplier will support the customisation, but merely that it does not invalidate the support agreement or the licence to use the software.
Changes, upgrades and patches to the hardware environment and the operating systems should also be subject to change control and approval procedures.
