Global change management

[Jon]

I work for a global firm and we are currently restructuring our change management process to include other regions around the world.

One of the ideas that we have is to have regional change management with a global CAB for strategic changes and changes that affect all regions.

The different regions will have the own mini CAB

Has anyone had any experience of using change management in a global organisation and what advice could anyone give

[arthur-fox]

Having worked for an Global FMCG firm, a Global Change Management process was put in place with 2 regional CABs (EMEA & NA) that took place every Wednesday. Changes that were mainly impacting or originated from EMEA were discussed at the EMEA and similarly for NA. For truly Global impacting changes these tended to be discussed at the EMEA as this was where most of the core infrastructure was located. The NA CM team attended the EMEA CAB and vice versa.

My main piece of advice is to define your Change categories carefully, primarily based upon urgency, priority and impact. Empower the Change Manager(s) to approve low level changes so the CAB does not deal with these types of changes and therefore keeps the meeting brief but effective.

[SD]

I work in Global Change Management for my organisation and host a CAB meeting once a week where we approve/reject global changes that fall into what we term severity 1 or 2.

Low level changes are approved by the Global Change Coordinator.

For the Global CAB it is important that you get management buy-in and that the appropriate people attend the meeting. If CAB members cannot attend they should appoint a delegate.

Also the Global CAB should be as efficient as possible. It is a time for making decisions and not for overly long debate.

Hope this helps.

[TemperedMeasures]

One of the things that has worked in global organizations is to maintain the regional change groups, but to have a global CAB which can hold periodic meetings to review "global changes" or to recommend those changes downward. The local groups still do the technical evaluations, the majority of the scheduling, etc. The global CAB, however, can act as that group which can put the global schedules into perspective, global impact analysis into perspective, etc.

Dan Vogel

[dgasparac]

OK, in my organization we call this "group" change management, but I guess this is the same. I'm responsible for implementation of such grpup change management process.

Situation is as follows: a "group" I'm referring to is a group of 5 companies in CEE. For strategic reasons, since all companies offer same services to local custommers, we decided to host some of them: collocate infrastructure in one of the companies and make them available to all.

Now, of course, change management comes in place. If there is some change on the hosted infrastructure, it may affect users in other companies. So, CAB should consist of the representatives of all companies: possibel a lot of them. Question I have is: how to structure that. I.e. local CAB's have about 10-20 people, depending on company size. If I just merge it, I'll have not a meeting, but a ~70 people conference once a week -> this can't work. So, I'm wondering how others made this differentiation, or what was the frame for local/global CAB's (I guess that in global CAB can be only the people from local CAB's?).

Thanks!

[m_croon]

Hi dgasparac,

Personally, I have never attended a CAB with > 8 people. I think you ought to think of a different structure when your CAB team contains as many people as you said. Are there other possibilities along geographical or product lines? Do you have the possiblity to replace part of the physical meetings by virtual meetings (change autorization by automated e-mail through your workflow management tool? I know that HP OVSD provides this for example).

Cheers,

Michiel

[dgasparac]

[m_croon]

Ok, here is my try, hope it makes sense. I must admit I am not too familiar yet with SOX.

First of all: you’ll need a sharp and smart definition of change categories:
· Which changes are pre-defined, which are to be locally (i.e. within one team) authorized, which are to be centrally authorized. When I say “one team”, you should not take this literally. It may be along hierarchical, geographical or product lines.
· How do you categorize and classify CAB changes in a standard way.
· Is there a possibility for change to be “promoted” from non standard (i.e. CAB change) to standard change, by addressing the change WITH a written procedure for its execution once in a CAB (consecutive requests for this change would be executed according to the procedure, which will still contain a formal assessment, yet not by CAB but by another role)? This in order to alleviate the agenda of CABs.

Secondly, (re?)define tasks, responsibilities and authorizations for the roles within your change management process. There is a difference between a centrally steered process (very important), and centrally assessed changes (not always necessary).
· When looking at authorization of a change, consider low impact changes to be authorized by change coordinators within a team. They should be made responsible for the change to be registered in a centralized tool. That way, you can always check on their performance.

Consider the role of tooling. Make sure all groups/units register their changes in one tool, controlled by one process manager. You already mentioned video conferencing, excellent. Also: some tools such as HP-OVSD allow you to create a group of people within the tool that can be sent e-mails requesting an authorization of a change. You can define authorization policies, with either a majority or 100% authorization requested before a change can proceed. Using this functionality, you can decrease the time and # of people actually and physically spent together in meetings.

After this, look again at the composition of your CAB(s).
A. Can you split up in operational versus strategic CABs? Operational meaning: to discuss changes on techie merits, and therefore preparing the formal / financial assessment and authorization in a strategic CAB (dept. heads).
B. Can you split up between local (team/unit) CABs and central CABs, with changes focussing on one team or product line being addressed in local CABs?
C. Can you split up along product lines.
D. ...?

You see that most of these options provide you with more meetings. The trick would be to convince people that they will be much more efficient, and therefore not as long as meetings with 10+people.

Hope this helps, cheers,

Michiel

[Globis]

Change management in ITIL clearly comes from a software development angle - and hence I think ITIL can be confusing for an organisation that does many 1000s of routine operational moves/adds/changes (MACs) to standard services.

I have worked for many multi-nationals with e.g. 150,000 seats in 40 countries. With this kind of scope you must have regional (or service based) groups with delegated authority otherwise the process is too slow.

Note that there should only ever be one CAB for an organisation, which delegates authority to all other change groups. Whether you call them mini-CABs or not is only a matter of terminology.

Whether you delegate along service or regional lines (or both) is up to you but be aware that processes involve people, and people inevitably form hierarchies, which inevitably attempt to become autonomous. Political power struggles will ensue and chaos will result. Probably.

A tad cynical perhaps but it happens, so as with any form of delegation the boundaries must be carefully set, and there must be only one change system used. Ever. Do not be persuaded to allow multiple autonomous systems to exist (believe me it happens).

All changes must be visible to the CAB for management and audit purposes.

A few other things to note (based entirely on personal experience):

Whilst a global CAB could do the job, you have several potential problems. One is purely reaction time: if you are in London, and a change requestor is in Indonesia, you have only a couple of hours per day to communicate whether via email, IM, or voice. Getting the answers to questions can be difficult as this may take several iterations.

Do not underestimate cultural differences. Some people may nod and say yes, but this may mean 'yes I hear you' not 'yes I agree with you'.

Finally a global CAB may fall prey to the 'Ivory Tower' syndrome where it becomes isolated from the majority of the organisation and will not only make bad decisions, but encounter resistance from the regional organisations who may believe (possibly correctly) that it does not have its best interests at heart.

Funny how global IT can mirror global politics:-)

Dave

[UKVIKING]

The CAB and the approvers for a Global organizaton should be local to the supporting groups and implementing groups.

If change only impacts Singapore and Indonesia, the supporting teams, implementing team, operations mgmt and change mgmt etc are Singapore and Indonesia.. the CAB should be local

If the change is done to systems in Indonesia by teams in London remotely and the IT operations mgmt is in London while the customers/users are in Indonesia, the CAB should be london based and the change should be process with additional time so that the representative of the users (if there is one) can propogate the change and its impact to them

The Change Manager should always act as the defacto agent for the business/users as a sanity check for them. And push back if necessary
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[rockon]

[UKVIKING]

True

This should be handled by the Forwward Scheduled of Change which the Change Manager in Indonesia send to all his peers/upp mgmt

The local CM should make sure that the respective support grp mgmt gets highlighted on the changes

In addition, I would expect that the local support groups - net, sysem, etc are linked to each other in hierarchal manner
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter