ITIL and Cab Problems

The software development community has a number of definitions for phrases like software configuration management, software change management, change control and asset management, and an even larger number for words and terms like configuration, baseline, change, release, version history, and repository management. It is not important to argue the right or wrong of these definitions, but rather to understand these terms in the context of the discussion.

For example, an organization may use the word project to refer to a job or task, while a version control application may use the word project to refer to a component or class. Nether definition is wrong, but there could be considerable confusion if the project - task organization tries to automate their 'project' management with the project - class version control tool.

Whenever vendor and client meet to discuss application development tool solutions, they should first make sure they are speaking from the same dictionary. Put the glossary on the table, and make sure you all agree to a single set of definitions. All application development organizations should maintain an in-house glossary of terms. It can be dangerous to assume that every new employee will be familiar with the local terminology.

With the above mentioned points in mind let’s see clearly ITIL and Cab Problems in details:

The Importance of Change Advisory Boards (CAB): A key part of managing changes in IT is to have a change advisory board (CAB). A CAB offers multiple perspectives necessary to ensure proper decision making. For example, a decision made solely by IT may fail to recognize the concerns of accounting. The CAB is tasked with reviewing and prioritizing requested changes, monitoring the change process and providing managerial feedback. This article discusses the role and composition of a CAB.

A CAB is an integral part of a defined change management process designed to balance the need for change with the need to minimize inherent risks. For example, the CAB is responsible for oversight of all changes in the production environment. As such, it has requests coming in from management, customers, users and IT. Plus the changes may involve hardware, software, configuration settings, patches, etc.

The Change Process Itself and that may lead to ITIL and Cab Problems: A change process often has requests forwarded to a change manager who then makes a rough-cut determination about whether the changes should be allowed to go further in the process. Assuming they are, a CAB may meet and review requested changes, including those that involve further testing.

It then delegates the discovery and testing phases to an engineering group to document what needs to be done. When the discovery and testing are complete, a report is made to the CAB, which then makes a final determination regarding whether the change should be allowed to proceed along with proper explanation of ITIL and Cab Problems. Now this process as defined is very high-level. The ITIL has a great discussion of the change management process in section 8.3 of the Service Support book (also known as the "Blue Book").

In situations where there is a crisis and the whole board cannot be convened, there should be a change advisory board/emergency committee (CAB/EC) made up of a core team of people that can make a decision to clearly define and to take immediate actions for ITIL and Cab Problems. For example, it is Sunday at 5 p.m. and a major worm hits that blows through the firewall: Who do you call to discuss the patches? Is there an accelerated emergency change process and a CAB/EC?

Obviously, while dealing and providing solutions in ITIL and Cab Problems you need a way to rush emergency changes into production and then a means to review them after the fact. Tracking the total number of changes, the number of emergency changes and success rates are all good metrics to monitor. If emergency changes are increasing and the success rate is falling, then a serious analysis of the situation is required.

To deal effectively and efficiently with ITIL and Cab Problems, one should be well aware of CAB Meeting Topics. The group should meet weekly, or on some appropriate regular schedule, to discuss change-related matters. Topics for discussion include:

• Newly submitted requests for change (RFCs), the CAB reviews change requests and make a determination to change, reject, or request more information.
• Review of the minutes from the last meeting -- Ensure that people are aware of the decisions made last time and review the status of any open actions.
• Review change status -- Update the status of approved change requests in regard to schedule, implementation phase, priorities, etc.
• Post Implementation Review -- For completed changes, successful or not, review what went good, bad and lessons learned.
• Review health of the change process -- There are two parts to this. First, a detective control system, such as Tripwire, should be used to detect all changes. These changes should then be reviewed by the CAB to ensure that they tie back to approved changes. If there are unapproved changes, then the CAB should launch an inquiry to determine the source and reason for the change. Second, the CAB must ensure that service-level agreements are being met. If not, then corrective actions must be taken.