Document code:  Security level:  Effective date:  ICT Governance  PRO-0027.06  Internal  15/01/2019  • Implementing small-scale improvements.  • Upgrading middleware platforms or operating system versions or implementing  minor changes to system architecture.  • Implementing modular additions to the existing functionality that do not require re- engineering the previously written code to any significant degree.  • Changes that justify a new minor release for the application, for example Release  2.2.1 / Release 3.1 / etc.  • The implementation effort stays within the effort size limits of maximum  implementation effort of 20 person days for a single change or 120 person days for  the set of changes.  Financial and contractual aspects of change management  The cost of Maintenance for an IT Product is budgeted on an annual basis, as part of the  IT Programme Plans, usually based on historical data. Such budget is called  Maintenance  budget .  By default the Service Manager is in charge of the maintenance budget for the Products  under the Service, including the budget implementation. If this accountability is assigned  to someone else, it is recorded into the Service’s Technical Service Description. As the maintenance budget is typically an annual envelope, its capacity can help in the  prioritisation of change requests.  If part of the work is outsourced, a suitable contract for such services (e.g. a software  maintenance contract, outsourcing contract) has to be in place before change  management can start.  The Service Owner appoints a Contract Manager, if the Service Manager does not  automatically play the role.  With the responsibility of the contract comes the responsibility of approving the invoices  related to the maintenance budget and of classifying them for the sake of the  capitalisation of the software asset and for cost accounting purposes. The  Change Advisory Board  (CAB) is a body that pre-approves standard changes and  approves normal changes. The  scope  of the CAB is defined when the CAB is appointed. It is good practice to  avoid  the unnecessary proliferation of CABs ; before creating a new CAB, opportunities for  consolidation should always be looked into firstly. The scope can be for example a single  Service or a single bespoke software application or the ECHA IT as in case of the iCAB. IT  Programme Boards normally appoint CABs  for managing changes at Product level as  a logical transition of the governance from initial Project work into Maintenance work at  Project closure. In addition, the Service Owner or the Director of Information Systems  can appoint CAB(s), of any scope. TEM-0129.01  Uncontrolled copy once printed. Ensure that the right version is in use.  Page  37  of  92 Change Advisory Board (CAB) 