I have seen so many Change management processes from many organisations following ITIL, passed audit, attained ISO 20001 but people on the grounds only know “how” the process works, without knowing the actual “why” these processes are in place. ITIL doesn’t specifically list the layers of approvals required, but here’s my recommendation on the core approvers required and what they should think about before clicking the “Approve” button.
I have seen so many Change management processes from many organisations following ITIL, passed audit, attained ISO 20001 but people on the grounds only know “how” the process works, without knowing the actual “why” these processes are in place. ITIL doesn’t specifically list the layers of approvals required, but here’s my recommendation on the core approvers required and what they should think about before clicking the “Approve” button.
1. Business justifications (Business unit Manager)
This should be approved by the end user’s manager who is submitting this change. It could be for an application enhancement, database patch, etc. If the request comes from users, someone from the end user end should approve the business justifications and analyse on the business impact.
The approver should consider: Is this change what the business wants? Will it impact any business operations? Is the cost justifiable?
2. Technical Assessment (Tech Engineer)
From a technical perspective, someone should be filling in the impact analysis of the change. Business users are not expect to know the technical complications, impact to related IT components or technical implementation plan. This role of the assessor should be answering those questions in the RFC form (or approving the RFC filled by another tech person).
The approver should consider: Is there a fall-back plan? Will this cause downtime? Have we informed the users of the downtime? Will this impact other systems? Is capacity planning catered for this change?
3. Change Manager Approval (Chg Manager)
Technical guys only assess it from their point of view in a siloed manner. They are not aware of the other changes going on in other departments. A change collision might occur when a DB of the application is undergoing a patch while the application is scheduled for an enhancement at the same time. Change manager’s role here is to be aware of all other changes going on and be familiarised with the FSC (forward schedule of changes)
The approver should consider: Is the details in RFC complete? Is this a major change to go for a CAB review? Is there a change conflict that might happen here?
4. Change Advisory Board (CAB)
For Major or high impact changes, this last additional layer of approval is required. CAB compromise different stakeholders from different departments and sometimes business managers or head of departments are invited for this meeting as well. They will know the business directions and look out for conflicts on a higher level. EG. Marketing might be running a campaign in Feb for Chinese New Year promotion and will be expecting huge network traffic during the month. A cisco firmware upgrade change might be delayed if it involves a downtime during the critical period.
The CAB team should discuss: Critical business events happening during the change period, change freeze periods on FY closing, deciding on taking risks on major changes with no alternative fall-back plans.