Last week I shared my thoughts on why consolidation of the various management of change processes in your company (check here if you missed it) is a necessary step for success in MoC and as the scope of this process increases also the pressure and the number of attempts to influence or by-pass it will increase. Let’s elaborate on that for a little bit, shall we?

Let’s assume that you have successfully consolidated the MoC processes for process and application changes (let’s not get over-ambitious) and we have gradually extended the scope of the organizational entities of our company. In others words, we’re now responsible for the execution of changes on processes and applications for pretty much the entire company. If the size of company is significant, you can also rest assured that the number of change request will be significant. The more people that work with processes and applications and the more countries you’re active in, the more requirements for change will be created. That is not rocket science, but simply a fact of life. Another undeniable fact is that human beings always think that their change request is more important that those submitted by the colleagues. There is always a very pressing reason or compelling event that makes them think that the execution of their change request deserves priority over others, and truth be told sometimes they are right, but mostly they’re not. From time to time there will be a change request that is so important or urgent that it does need to be prioritized over already existing change requests. This could be because of a legislative nature (you need to comply to the requirements of SOX-xx (I lost track of count on that financial framework) before the end of the year, or to the requirements of the Corporate Reform in the UK early 2022, just to name two. 

You could plot the importance / priority of a change request easily on a normal distribution graph, the vast majority is all the same (let’s say everything between plus or minus 3 standard deviations, but some of them (outside the plus 3 standard deviations) just mess up your change request processing schedule because of legitimate reasons. The major challenge with the MoC process is to be able to distinguish between the legitimate priorities and the wishfull thinking priorities, and in order to do this you either need to be quite seasoned and steadfast or you need to have a senior executive overseeing the MoC process and decide on these priority requests. No matter how you look at it, your capabilities to judge, decide and withstand these requests will make or break your MoC process. 

In order to be able to withstand these numerous requests there is one thing that needs to be firmly in place: a sturdy and just governance framework for your management of change process. This framework consists out of a number of components, but two of the most important ones are:
1. The mandate
2. The RACI on the MoC process

To start with the first one, the mandate. At the moment that you decide to implement a more central MoC process, the first thing that needs to be taken care of is a definition of the MoC mandate and this mandate puts the responsibility and accountability in the hands of the group of people executing the MoC process, including a senior executive that has the ultimate ownership of this process. Let’s assume that your organization has a central process management group (sometimes called a BPM CoE or process excellence group) that executes the MoC process. The leader of this group has the over-all R(esponsibility) for the MoC process, and his/her manager would have the over-all A(ccountability) for this process. The “A” needs to be sufficiently ranked with the organization in order to have sometimes difficult discussions with business line/unit leaders in case of escalations. This “A” needs to have the mandate to accept or reject the prioritization requests coming from the business executives. If this is not the case, the MoC group will become nothing more than an execution group with increasingly faster changing priorities, driving them barking mad and virtually no change requests will be fininshed and delivered on time. This is of course not something you wish to see. 

If you look at the picture below you will see why the mandate matters. In traditional set ups very often the MoC responsibility is tucked away deep in the CIO column. At the moment that a business unit wants to dispute the priorities or a change request coming from another BU or even Corporate departement, they will escalate ultimately and the level of escalation (I always look at two levels up in the org chart) simply is not an equal match in that case. A BU Director is much more powerful compare to for example a Head of IT Delivery. At the moment that the MoC process is part of a Corporate BPM group, this escalation game becomes much more of a level playing field, increasing the likelihood that the MoC process is constantly overruled. 

So, summarizing for this week, if you want to engage in centralizing your MoC process (over the different types of changes and/or over the organizational axis) please be sure to anchor it at a sufficiently high level in the organization and give the MoC group the mandate they need to do their work. That way they can make sure that all submitted change requests will be executed in the proper order, at the proper time and without the unexpected consequences that are unfortunately characteristic for large organizations. 

Ciao, Caspar