Change Advisory Board - CAB

[michaelm]

The ITIL process for change seems to have the CAB sitting very much at the front of the process to assess RFC's being submitted so they can be approved for implementation. At this point the activities around change build/test/backout etc commence. Within my organisation the view being taken is the CAB is actually run very close to change implementation so the technical contents/change quality/etc can be assessed and the change approved or rejected at this point. Has anyone else implemented CAB processes and where in the change process flow have they occurred?

[rjp]

We don't have a CAB. Rather the CABs role/function has been allocated to the plenary meetings which were already taking place.

When a change is approved, this does not mean that if testing fails the parameters or scope of the change can be altered. In that case it becomes a 'diferrent' change and requires approval. But yes the 'CABs' are close to the implementation planning process. But our implementation strategy is to 'transform' existing practices (where possible) - A common approach is to implement alternative processes and 'switch' to them once you are sure they will work.

Also - remember that in ITIL the CAB, and the Change Management process is intended to be predominantly an assess, approve, update (cmdb) and review process. Not the implementation and planning process - which is what Release Management is about: I.e. getting all the tasks done, ensuring the change will work and 'releasing' it into the live environment. So where release management is in full swing, yes the CAB is very much at the front end of the process. But in business terms distance isn't really measured in the number of steps in a process, but in the time and resources expended to get from step 1 to step n (or back again), and the overall visibility of the activity in each task - monitoring, reporting, tracking. So the CAB can be at the front end of a complex process, and still be close by being well informed, and agile (quick to respond when required).

[blamblam]

We do have a CAB which convenes for Major Changes only. The Change Manager is the only permanent member of this group, the other members are assembled according to the Change. The CAB comes together to review and approve the Change following an impact assessment as overseen by the Change Owner. If the CAB gives it's approval for the Change to proceed, it's then developed and reviewed prior to release by the Change Manager. Any deviation from the original design that attained approval may mean the Change is stopped, though these things are usually dealt with pragmatically.

In our organisation, the Change Manager is also the Release Manager, so following approval for release, it is then scheduled for release. However this step is often done siginificantly in advance as Major Changes tend to be Projects and so there is visibility of when the Change will need to be implemented.

[SD]

We have a CAB, which meets on a weekly basis to approve/reject any signifcant changes pending.

Changes only go before the CAB, once they have been fully assessed in terms of impact, time, risk etc. by the resolver group(s). If the CAB gives its approval the change can proceed to implementation.

[mgnrfan]

We do have a CAB in our organization, and like SD mentioned they meet once a week in which they decide to go ahead or not.
Basically they review the Change Request, interms of Financial, Resource, Time requirement,
but Change Request goes to CAB only after first level of Impact analysis, so that it helps them to make decision in positve way

[Guerino1]

Good day all,

Change Management and the CAB is actually an interesting dilemna. If you think about it, assessing the impact of a Change has traditionally been the responsibility of a Product Manager, who is usually the accountable party for the strategy of a Product and ultimately what Changes actually go into a Release and why. In a small company, where there are only a handful of products, it's OK to continue to let the Product Manager perform the CAB functions. But, obviously, as you scale to a point where you have many Products, constantly being Released into one environment, it becomes important to try and coordinate and evaluate as many of those Changes as possible, since any one Change can possible take down other related businesses or business units who share infrastructure, systems, data, etc.

It is in companies where many Products all funnel into one common environment that a CAB seems to be most useful. However, it is in these same environments that we see a CAB function breakding down as the organization gets larger. As an enterprise grows to be very large, it becomes almost impossible for the CAB to understand the whole view of the enterprise and, as a result, their evaluation of the Changes and their impacts becomes ineffective. This usually happens because 1) There are far too many Changes for far too many systems to understand and 2) The environment is too large and in a constant state of flux, making it too difficult for any small group of humans to understand.

In cases where the organization gets very large, we see the role of the CAB being reduced. They do not evaluate Changes so much as facilitate the communication of Changes. For example:

- All RFCs and their schedules must be communicated to the CAB so that the CAB can, in turn, ensure that all parties in the organization know that such Changes are intended for the future.
- Provide a centralized Release calendar that highlights what Changes for what systems are going into any specific environment, usually a month or two out.
- Highlight what Changes are Standard, Emergency, or Expedite
- Provide information for how interested parties can find documentation on each scheduled Release and their related Change(s).
- Bring all appropriate stakeholders to the CAB table (usually a week or so in advance of scheduled Changes) to ensure everyone understands what's going in the environment and to allow interested stakeholders the opportunity to voice their concerns, for one last final time.
- Ensure that all Release Managers provide proof of detailed Release Plans that include rollback processes
- Review success/failure of deployed Changes
- Generate, manage, and communicate enterprise wide statistics and metrics of Changes across all products, systems, services, and environments in the enterprise
- Etc.

In short, what we're finding is that the understanding and evaluation of Change impact is falling off the CAB's table of responsibilities and that those functions are being pushed "back" into the Product Management role, who's responsibility it is to work with their Service Delivery managers to ensure that Change impact and risks are accounted for, before the scheduled Release.

Anyhow, I hope you find this useful.

Regards,
_________________
[Edited by Admin to remove link]

[WendyB]

We've just implemented Change, and had the first CAB meeting to review an upcomming change. Even with the review of the RFC during the prior week, there were enough concerns about the implementation of the change that the change builder felt they couldn't be addressed quickly enough so it was postponed until he has a better understanding.

First one out of the block, too. The next one should be interesting.

[TemperedMeasures]

Something that works well in a lot of companies is to have everything go through the CAB on the first go. As data is collected... the CAB can make the determination for what should and shouldn't continue to move through it. This way, the assessments are based on fact. The CAB can take the data to help structure the change categorization structure. Using the data the CAB can also make a determination for what should be considered "pre-authorized". This doesn't take a lot of effort up front, and is a huge time saver as you progress forward.

Dan Vogel