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.

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 .

First, in a September 2009 blog article titled Moving Beyond Compliance: The Status Quo is No Longer Acceptable, government technology heavyweights, Vivek Kundra (Federal CIO), Robert Carey (Navy CIO), and Vance Hitch (DOJ CIO) informed the public that a Security Metrics Taskforce was formed to combat the continuously evolving threats to our nation’s information security. Experts, from both the Federal community and the private sector, such as the Federal CIO Council, the Department of Defense, the Director of National Intelligence, Privacy Advisory Board, and many others held their inaugural meeting on September 17, 2009, to discuss and debate, and subsequently to develop new metrics for information security performance for Federal agencies that are focused on outcomes, rather than mere compliance. By shifting the focus to outcomes, the experts anticipate that the change will “enable new and actionable insight into agencies’ information and network security postures, possible vulnerabilities and the ability to better protect our federal systems.”

Although this blog does not specifically state that Federal IT spending will increase in the near future, all signs point to “Yes.” Experience and common sense indicate that certain actions and key words = more Federal spending.

A new taskforce/committee, Security Metrics Taskforce, was formed. This new taskforce will evaluate threats to the electronic infrastructure of the Federal government.

The Security Metrics Taskforce will develop a new set of security metrics. Factors that will impact the development of new metric include: “a trust but verify approach, fulfilling statutory requirements, real-time awareness security posture.” “Fulfilling statutory requirements” and “real-time awareness security posture” are phrases indicative of more Federal spending since more manpower—both administrative government workers as well as IT specialists—must be hired, and more hardware as well as software purchases and upgrades must be implemented in order to fulfill the new security metrics.

In the most recent issue of CDW IT Monitor, a bimonthly indicator that tracks the direction and momentum of the US IT marketplace, all signs and trends point to the continual increase of Federal government IT spending. For starters, when surveyed, Federal government IT decision makers anticipated growth on many levels—“44 percent of Federal government organizations plan to make significant software purchases in the next six months, an increase of 14 percent since June.” Additionally, “89 percent of Federal IT decision makers plan to make hardware purchases in the next six months, an increase of nine percentage points since June.” Though this short blog does not offer any explanation as to why Federal spending is increasing, by taking into account the article Moving Beyond Compliance: The Status Quo is No Longer Acceptable, and the subsequent analysis, we can safely draw the conclusion that Federal IT spending will be increasing in the months to come.

Perspective Conclusion on Federal IT Spending:

Federal IT Spending will increase in the areas of Public Healthcare, Defense, and general Information Technology in 2010—due in part to projected plans from President Obama’s executive branch as well as the typical upgrade cycle for most technology assets. No doubt some of the Federal IT budgets increase will be spent on Microsoft Windows 7. Moreover, the government’s main expenditures of 2010 in IT will vastly exceed expenditures in previous years with the focus on the aforementioned Windows 7, Process Improvement such as ITIL, Security Software, and Asset Management Software.

For more information on the Federal IT articles mentioned, check out the following sites:

Federal IT Dashboard

CDW IT Monitor

For instance, it’s no longer enough for CFOs to master their financial dominions—to set financial priorities that satisfy business objectives, to budget spending and cash flow models, and to know the most updated financial health of their businesses. As integral components of most businesses, IT departments and/or technology services account for a sizable portion of the operating budget. Therefore, many of today’s CFOs need to actively participate in making technology decisions at their businesses, not from a technology perspective, but from the financial perspective of more control over budgeting and cutting costs.

On the other hand, it’s also no longer enough for CIOs to just focus on delivering effective and efficient technology solutions; nowadays, CIOs must also factor in costs as many companies are evaluating their CIOs’ performance based on the resulting business profit gains or loss that are tied to the implementation of such technology solutions.

In order for modern businesses to, not just survive, but thrive, key officers such as the CFOs and CIOs can no longer operate their respective departments independently, without accounting for the needs of other departments within the businesses. Now CFOs and CIOs need to work together in a collaborative environment to achieve the common goal of running a financially successful business through efficient and cost-effective technology solutions.

The following are recommendations from Andrew Jesse, VP, Professional Services, Basware, detailed in his article in Enterprise Management Quarterly:

• Develop a cross-functional team to engage all key players in technology decisions: CFO, CIO, and business users.

• Identify and measure improvements in key performance indicators.

• Implement a shared service centers model to standardize best practices throughout your entire business—improve technology processes as well as cut costs.

In order to maintain a competitive edge, CFOs and CIOs of modern businesses must align closely and share responsibilities of streamlining operations and meeting key business goals. For instance, CFOs and CIOs can collaborate on how to leverage technology to cut costs so that they can provide, as a team rather than individual departments, greater profitability and value for their businesses.

To see how SmallCart implemented such practices described in the above article, please read our case study how an Electronics Distributor implements a global service portfolio solution to manage irresponsible spending in Information Technology.

For more on the changing roles of CIOs and CFOs:

Sources
-Enterprise Management Quarterly article: The changing roles of the CFO and CIO for greater business agility in a turbulent economy

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.

More often than not, companies and their suppliers are just not on the same page when it comes to the type of performance that was expected and whether the vendor agreed to adhere to specific benchmarks within the contract.

So in order to provide clear guidance to the vendor about what you expect, you must negotiate an agreement—it should be in writing and be part of the original contract—that details the performance expectations of both parties.

By doing so, you can make sure the supplier will respond to your needs in a timely manner. You can also include financial incentives for the vendor to meet your critical service level needs. And you could agree to financially reward your vendor if he helps you increase your revenue.

An SLA should be crafted to make sure the vendor meets all your requirements. That means you must use language that requires the supplier to perform his responsibilities. For example use words like “the vendor will,” do something. Additionally you should also use language that obligates the vendor to make his “best efforts” to meet your needs.

While SLAs vary, you should make sure your supplier responds to your problem as quickly as possible. Ensure that you receive a firm commitment from your vendor as to the maximum time it will take respond to a problem, and ultimately resolve it. For example, a vendor might have at most 30 minutes to respond to a critical error and should use his “best efforts” to fix it within several hours. For a less serious error, the supplier might have several hours to respond and up to a business day to fix the problem.

If your vendor hosts part of your IT infrastructure or if he provides support on-site, you should ensure that you get a firm commitment from him as to the percentage of time the hosted service or application will be available. This does not include scheduled maintenance. You should negotiate a reduction in fees if the vendor does not meet the availability requirements.

Also try and negotiate the right to continually compare the costs and levels of service offered by industry leaders. If you find that another vendor is charging less or offering better service, then you should require your vendor to match what that vendor is offering

Sometimes a vendor introduces a new product, which is just an update version of the product you purchased, and decides to discontinue support for your product, forcing you to purchase the new product. To prepare for such an eventuality you should require your vendor to commit to continue supporting your product for a certain period of time, usually 18 months.

• Use What-If scenarios to determine who does what during a critical outage.
• Develop a Critical Outage Bridge Toll-Free Number and Procedures on how to inform critical people when an outage occurs.
• Assign a role of Severity Analyst to someone in your organization and make sure the person in that role knows all of the proper procedures and people on the vendors side to both open an incident as well as escalate.
• Define reporting guidelines and spend time with the vendor informing them on how the SLA will be measured as well as general expectations of availability.

Remember, it is your company’s best interest for the supplier to be able to make their SLA. If the supplier is regularly able to achieve their SLA your employees and IT users will be able to remain productive. So an SLA should be a cooperative effort between vendor and the company.

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.

Since 1989, the OGC has issued a series of books on ITIL. Each of the books covers a topic of IT service management.

The core ITIL process have basically stayed the same since v1, however the way they are put together has evolved to meet the ever-changing needs of the organization.

Since v3 was introduced in 2007, many IT service managers have wondered about the key differences between v2 and v3.

For one thing, the library has been consolidated to five new books, each dealing with a phase of the service lifecycle. In ITIL v3, the concept of IT service delivery has been expanded from the day-to-day operations of those services to the following five phases of the service lifecycle:

• Service Strategy: Developing and implementing service management as a business strategy.

• Service Design: Designing the right IT services to support the business strategy.

• Service Transition: Transitioning the new system to production.

• Service Operation: Developing effective services to support operations.

• Continual Service Improvement: Continuing to improve IT services.

For another, while v2 is organized around process, v3 is centered around service and helping IT provide value to the business. Version 3 calls on IT to develop, design and expand IT services based on what’s best for the business. Version 3 is more about making IT a business partner, rather than just a department that provides the technology to support the business. One benefit of v3 is that it closes the gap between the IT organization and the business. In v3, the success of the business depends on its relationship with IT.

Although v2 talked about using IT to save money, it focused on how much the IT services cost, rather than the return on investment realized by integrating IT services with the business needs.

Version 2 also focused on the best practices for incident management, change management, capacity management and configuration management to help companies improve and standardize their data center operations. But while v2 told organizations what to do, it really didn’t explain how to do it. And for some, that just wasn’t good enough.

Version 3, however, provides more specifics on how to reach the goals advocated in v2, including offering examples of various business cases. What v3 does is integrate the different ITIL components much better than v2, making them all equally important.

Version 3 is also less complicated and more easy to understand than v2. Additionally, organizations can customize it to meet their specific business needs. And because v3 provides more structure than v2, organizations can incorporate other best practices and standards like Six Sigma.

ITIL v3, therefore, is a change in mindset from v2. It provides the framework for IT to work more closely with the business so it can design and develop the appropriate services to move the business forward efficiently and effectively. Version 3 is about integrating IT services with the business for the good of the business.

One of the keys to managing change is creating a Change Advisory Board, or CAB, which will help a business balance the need for the changes with any inherent risks. The members of this board will give the change management team the input necessary to help you make the best decisions for your company.

The job of the CAB is to review and prioritize any potential changes, keep track of the change process, and provide feedback. The board will also make sure that all the stakeholders including IT, security and business analyze the changes. The board will help ensure that the changes are implemented without disrupting your customers’ operations.

But once the CAB is established, what can be done to ensure that the board’s meetings are as productive as possible?

For one thing, the Change Manager, who convenes the meeting, must make sure that someone from the essential departments in the company are at the meeting. The Change Manager, who is responsible for change management, serves as the leader and facilitator of the CAB. If board member disagree about how best to prioritize changes, the Change Manager can resolve those disputes.

The CAB must meet on a regular, published schedule, typically weekly, to authorize changes. Hold meetings at a time that is convenient for board members. But they should be held at the same time and same day every week for consistency’s sake.

No one in the company should schedule a meeting that conflicts with the CAB meeting. And, if at all possible, CAB meetings should not be cancelled. Decide whether every board member needs to attend every meeting. Members new to the board should receive an orientation before they begin. The orientation should include the board’s bylaws, work plans, and descriptions of their roles on the board.

In order to make the meeting run smoothly, the topics for discussion should be distributed to each member of the board before the meeting. Too much time will be wasted if the members are required to review this information for the first time at the meeting.

These topics include:

• The requests for changes that have been submitted

• Minutes of the last meeting to be reviewed

• Updates of the status of changes that the board has already approved

• Review of the changes that have already been completed

Taking part in a Change Advisory Board requires members to listen to the ideas and opinions of other members. And they should discuss those ideas and opinions before making any final decisions. Sometimes it’s hard to work together as a group but here are a few tips to help board members feel more comfortable with one another and become a cohesive board:

• Ensure board members know each other’s names and a little bit about each other

• Encourage all board members to participate in the discussions and brainstorming sessions

• Ensure that each board member respects the opinions of fellow board members

In order to keep the CAB meeting moving forward as efficiently as possible, the Change Manager has to take charge and own the meeting. He must let members know he plans to keep the discussion on topic and on time. Having a clock nearby lets members know he values their time. Keeping to the schedule of agenda topics, and setting a time limit for each agenda item, will also help the Change Manager keep the meeting on track. If the members start to discuss something that’s not on the agenda, the leader must refocus their attention to the task at hand.

For the meeting to be most productive, the Change Manager has to be sure to get input from all the board members. He should treat all board members with respect and not immediately reject ideas or opinions he believes are worthless. And he must not impose his opinion on the group.

Before the meeting ends, the Change Manager should ensure that all the board members understand the next step or steps. Additionally, he should ask members if they thought the meeting was useful and stayed on track and what could be done differently at the next meeting. He could also follow up with board members individually to gain insight into his meeting strategies.

Finally, the Change Manager should ensure that the appropriate people understand what happened at the CAB meeting and what decisions were made. In addition, the Change Manager should have a system in place to track the board’s decisions and what, if any, tasks individual members agreed to undertake so he can follow up with them to make sure things are proceeded as scheduled.