The change calendar drives the Change Advisory Board (CAB) meeting. Each change listed on the calendar is briefly reviewed, and the change owner (present at the meeting) attests to the readiness of that particular change for implementation. The items on the change calendar are separated into either “approved” and “pending” changes.

The approved changes are the items that have passed the standards of readiness already in place. For example, an approved change will have testing evidence as well as the required managerial approvals attached. Prior to the meeting, the CAB will have reviewed all submitted changes and classified each change as approved or pending. On the other hand, a change may be classified as pending because required approvals were not obtained before the CAB meeting. Furthermore, depending on the local practices, the CAB manager may approve such change requests for implementation the following week if the submitter succeeds in obtaining the required approvals by close of business on the following Monday.


Another important indicator on the change calendar is the planned implementation time—it indicates whether a specific change can be implemented during regular business hours or after business hours. For example, a change that may require shutting down a software system or turning off a piece of hardware may need to be implemented after business hours in order to not interfere with the normal operation of the business.

Moreover, the change calendar typically lists the names and contact information of the change requesters and the release and deployment managers, so that when necessary, parties can reach each other. Depending on the volume of change in a particular environment, an open phone bridge may be a standard arrangement to facilitate after-hours communication.



Lastly, the summary section of the change calendar document lists any known future changes that the development and support community need to be aware of, such as major planned downtime or major system upgrades that may require action on their part.

Share on Facebook

1. REQUIRED APPROVALS NOT ATTACHED

Any IT change control process worth its salt will require approval for a change from someone other than the change submitter.  Typically, each major subsystem, or even application, is assigned an “owner,” who is responsible for approving every change to the subsystem or application.  This type of structured procedure keeps the chain of responsibility intact and prevents unannounced or unauthorized changes from disrupting a production environment.

2. NO BACK-OUT PLAN INCLUDED

Another basic part of any sensible change control process is the inclusion of a back-out or fallback plan.  With any proposed change to a controlled IT environment, there is always a chance that some unforeseen circumstance may prevent the successful implementation of the change, whether it be large or small.  A clear statement of how to return the environment to its original, pre-change state is a critical component of every well-planned change.

3. REQUEST SUBMITTED PAST STATED DEADLINE

In any operative enterprise or organization, IT change management is a continuous process that evolves with the needs of the company.  In order to manage change effectively and smoothly, everyone must comply with his or her deadlines so that other people responsible for other steps of this continuous process have a reasonable amount of time to properly perform their function. 

For example: at Company A, software changes are managed on a weekly basis; therefore, a reasonable deadline would be that all changes scheduled for next Monday be submitted by Friday at noon, so that they can be reviewed at the weekly Friday 2:00 p.m. Change Meeting.

If some such logical schedule is not followed, chaos is sure to ensue.

4. EVIDENCE OF SUCCESSFUL TESTING NOT INCLUDED

Another vital requirement of a well-managed change system is that all change requests must include associated and relevant testing evidence.  Change to a controlled environment should not ever be made “on faith.”  There are, of course, situations where the exact actions that will occur in the controlled environment cannot be performed in the test environment (like sending money to a client), but all changes should be simulated to the utmost degree possible to reduce the likelihood of errors in the controlled system.  Change requests with no testing evidence attached should be rejected by the CAB – except where special and well-understood circumstances apply.

5. IMPLEMENTATION INSTRUCTIONS MISSING OR INCOMPLETE

To standardize and further automate your change process, you will need a plan that describes what the change action is.  Some companies refer to this plan as an implementation plan.  Regardless of what you call it at your company, you will need this plan.  As your organization changes over time, the implementation plan should evolve with such changes.  Moreover, it also has to capture all the standard change actions that have occurred company-wide.  It is the responsibility of the change requester to add the required information to the plan.  It is the responsibility of the CAB to assure that the plan is valid before anyone tries to act on the instruction it contains.  In sum, it makes perfect sense that an incomplete implementation plan will cause a change request to be rejected.

6. REQUESTED IMPLEMENTATION DATE IS IN A FREEZE PERIOD

Most organizations will block off certain days every month when any normal changes to the controlled environment are disallowed.  For instance, the change blackout period might be the end of each month when the company is closing out its financial records for the month.  During such a period, only emergency changes are permitted, and any such emergency change usually requires a high-level approval in order to move forward. 

The requirement of high-level approval accomplishes 2 objectives: 
1) Assures that senior managers are aware of the change
2) Discourages the misuse of the emergency change method by those who somehow did not complete a process on time.

7. REQUESTED CHANGE COLLIDES WITH ANOTHER SCHEDULED CHANGE

Another important function of the CAB is to prevent colliding change requests from being teed up at the same time. 

Example: The owners of System A are not fully aware of the plans and activities of System B.

Over time, the CAB should become sufficiently aware in all of the company’s systems that it can help prevent changes in one system that would negatively affect another. 

Example: System A produces output that is used by one or more other systems in the company.

Therefore, a planned change in System A might cause a problem in some downstream system that the owners of System A might not have considered.  The CAB can reject a change request when it detects such a situation.

8. REQUIRED CAVEATS/LANGUAGE NOT INCLUDED IN APPROVAL

A particular company may require that certain statements are included in every change approval form.  A federally regulated company may require, for example, that the Sarbanes-Oxley compliant controls be included in all change approval forms.  The lack of adhering to such controls would be a valid reason for rejecting a change request.

9. PROPER REQUEST ROUTING INFORMATION NOT SPECIFIED

A well-designed IT change request will include instructions that tell an analyst what group the change request should be sent to—that is, who will actually do the work described on the change form.  Without such information, the change request cannot be processed and should be returned to the requester.

10. CAB DECIDES THAT A REQUEST IS NOT COST-EFFECTIVE

The CAB can operate at a number of different levels.  In addition to processing the daily requests for change to existing processes, the CAB can also evaluate the cost-effectiveness of large, capital-intensive changes.  Some companies reserve such reviews for changes with an estimated cost over “X” dollars.  If the CAB decides that the proposal is not cost-effective, the project would be stopped.

The 10 issues described above are just some basic characteristics of a well-designed change process.  To delve deeper into ITIL-based change management, try the change management section at  IT Library .

Share on Facebook

In addition to EMA’s findings we have also uncovered that many CIOs either have placed self-service as a high priority or are looking to make improvements within their own Service Desk. Avaya’s CIO, Lorie Buckingham, cited that Boosting Agility was one of her top 5 current priorities in the August 17, 2009 edition of eWeek. Furthermore, Buckingham, went on to describe that the improvements made over a three year journey would increase the ease of doing business with Avaya and improve their ability to grow business without an increase in IT costs. Moving towards agile IT operations would mean significant improvements in customer and partner relationship management, operational process improvements, and the deployment of increased customer self-service capabilities.

Implementing ITIL process-based tools with an existing process are no joke to ICW Group Insurance Companies’ CIO Kevin Harris. According to a recent case study in Insurance & Technology Magazine, Harris was able to improve ICW’s incident management resolution times by approximately 90% and reducing the help desk personnel costs by 25%. This journey required optimization within Incident Management and integrating their ITSM tool with processes such as Change and Asset Management. “The net result,” according to Harris, “is that we significantly increase[d] overall customer satisfaction.”

EMA also stated in their trend analysis that in 2009, the service desk is still expected to continue its role as a central component in any service support and delivery strategy. Also, that CIOs are continually looking for ways to leverage the service desk to meet corporate expectations for IT service functions despite budget reductions. They also stated that organizations are looking towards process improvements and improving customer service in the Service Desk that will reduce the overall total cost of supporting the business.

Perspective

Many organizations are seeing the value in implementing a strategy towards improving the customer service and reducing the cost of the help desk by providing Self Service capabilities. Be it, the service catalog, a knowledge base, or the ability to open Incident Tickets via the web. As the Internet and Technology have became more a part of our everyday life from being able to buy a book on the internet to the replace of email to the written correspondence we see the technology makes life easier once it has been fully implemented and adopted.

I remember back in 1997 when the web was relatively fresh and new. The ability to send an email directly to a webmaster from a CGI scripted web form made my life easier when I wanted to correspond to a webmaster. This technology allowed me to quickly send the information I wanted to transpose without opening up an email application. Today, I can order a pizza online and visually see each step of the order delivery process along the way.

Sometimes the corporate environment is a bit behind in developing solutions that the consumer culture has already embraced. My perspective is that in the near future, once the service catalog and self-service capabilities become the norm, business customers will be able to track their IT order from start to finish. They will see what department is fulfilling their order and will have an accurate estimated time of delivery for their request. Maybe someday, we’ll hear stories of IT organizations being able to deliver fully provisioned desktop PCs to their business customers in 30 minutes or less.

Sources

Erickson-Harris, Lisa (2009, June 15). Enterprise Trends in the Service Desk 2009. EMA Advisory Note.
(2009, August 17). Priority List. eWeek, [26(14)], 43.
O’Connor, Nick (2009, August/September). Trouble Tickets No Longer Trouble. Insurance & Technology, [34(6)], 19.

Share on Facebook

A CMDB is a database that contains all the pertinent information about an organization’s technology components (called configuration items, or CIs) such as network equipment, computers, servers and peripherals and the relationships among those components. A CMDB gives enterprises an organized view as to how the various components interact to deliver applications and services for their customers. A CMDB can only be implemented in parallel with an effective Configuration Management Process. That means all data related to core IT operations must be appropriately stored and managed in order to ensure the integrity, validity, and accuracy of the configuration management data.

Here are five benefits of implementing a CMDB:

1. Breaks down the barriers between IT and the business—A CMDB removes IT silos and helps people, processes and technologies work more efficiently together. That’s because knowing what technology components you have, where they are and how they’re connected will let you better manage and improve your IT services.

2. Provides more proactive management—A CMDB allows organizations to better manage change in their IT environments. As the complexity of a organization’s IT infrastructure increases, a central database containing information about all the CIs and how they work together will help you avoid downtime by more efficiently planning and better appreciating how those changes affect the IT environment.

3. Helps better assess risk, improve security—IT organizations can use CMDB data to assess the risks to the business associated with known vulnerabilities on servers. That means your IT team can prioritize patches and secure the most critical vulnerabilities first.

4. Helps keep track of any changes in software—Data from the CMDB lets organizations know if there is any unauthorized or illegal software being used.

5. Makes compliance easier, more accurate—Using CMDB data, IT organizations can make sure that the information about their assets is accurate and up to date in order to comply with such initiatives as Sarbanes-Oxley and HIPAA. By keeping a close eye on CIs and their relationships and continually monitoring them to make sure they’re accurate, your IT organization can better ensure that your systems and their components comply with legislative mandates.

Share on Facebook

While this is a good definition for someone who understands the vernacular of ITIL, it isn’t easily understood by the layman. Let’s dissect the definition and put it into terms the general population can understand. The IT Service provider is the organization that has been hired by the Customer to perform a service, for example, answer calls. The service level agreement is the document, which can be a few brief lines or it can be a hundreds of pages, which describes each service level target(s). These service targets are based on the customers business needs. For example, if Large Corp. sells their products worldwide, they may have a need to have a call center that is available 24×7. This one business objective, call center available 24×7, could produce multiple service level targets such as:

Call Center is available to take calls 99.99% of the time each month.

No more than 5% of calls will abandon each month.

99% of all incoming calls must be answered within 30 seconds.

All of the service level targets must be agreed upon by both parties. Once both parties agree to all of the service level targets, they are assembled into the Service Level Agreement document. The service level targets will each have a description that identifies the expectation, how it will be measured and penalties, if missed. For example:

Call center must answer all incoming calls within 30 seconds

Measurement period: 1 month

Report(s): ASA Report 101 – monthly

Penalty: $10,000

The SLA is a joint goal between the IT Service Provider and the Customer. Although penalties do reduce costs and they do send a strong signal to service providers to improve their service, neither you nor the service provider “win” if an SLA is missed. Think of an SLA as a shared goal.

It should be noted that the term Service Level Agreement is used in many companies when discussing agreements between two internal groups, such as the Procurement Department will process all purchase requests by the Engineering Department within 5 business days. Technically, per ITIL, this is not a Service Level Agreement, but instead an Operational Level Agreement.

Share on Facebook

CUSTOMER: I submitted a ticket to have someone map a new printer to my laptop, but nobody has come by or called me back.

HELP DESK: I am sorry to hear that but we are busy with a network outage, it may be awhile before somebody comes by to assist you in your request.

CUSTOMER: Can you give me some timeframe on when to expect a visit from a technician?

HELP DESK: It all depends on when we get the network outage repaired; it could be then next 5 minutes or the next 5 days.

CUSTOMER: It is no wonder your area is referred to as the helpless desk. CLICK!

Unfortunately, the above conversation is all too familiar in many help desks across the world because expectations are never set with customer. One way of setting expectations with the customer, even before they call or write, is to establish Service Level Objectives, such as:

Ultimately, service level objectives will benefit the help desk in a number of ways such as: Less repeat callers/tickets – with service level objectives established, customers are less likely to repeatedly call in order to get a status of their issue.Less upset customers – if the objectives are “advertised” on websites and IVR/VRU’s, the customers are less likely to be irate when calling a help desk if they already know that their issue may not be resolved on first contact and may be considered a low priority.Potentially reduces staffing – less repeat calls and tickets to the help desk, lowers call and ticket volume, and potentially reduces the staff needed to perform the volume of work.Assists in priority setting for employees – with objectives in place, the help desk staff have a clear understanding of what issues should take precedent (i.e., individual outage should be worked prior to a individual new request).If your help desk has not established service level objectives, your next step should be to have a project approved to begin establishing the objectives to help you manage your customers.

Share on Facebook