With all the recent talk (and press) around SOA (Service-Oriented Architecture) as well as how many billions of $ are going to be spent by IT organizations on SOA-based initiatives, I can’t help but wonder what impact this bow-wave of activity will have on ITIL-related initiatives. Or will there be any impact at all?

Is this coming “wave” good news for ITIL and ITIL-related projects? Does it mean a shift in focus for many IT Organizations? After some analysis, I think the answer is pretty clear.

The increasing focus on SOA does not mean the demise of ITIL or a decrease in focus around ITIL-based initiatives. On the contrary, SOA-based initiatives only increases the need for the type of efficiency and control that ITIL seeks to implement.

All it takes is a quick look at some of the guiding principles defining SOA to better understand this point. These core SOA principles include:

• Reuse, granularity, modularity, componentization, and interoperability
• Compliance to standards (both common and industry-specific)
• Services identification and categorization, provisioning and delivery, and monitoring and tracking

Bottom line, I think what SOA seeks to achieve and leverage is directly in line with core ITIL processes. What’s more, in order for SOA initiatives to be successful, strong core infrastructure operations (like those targeted by ITIL) are a necessity. Organizations who have invested in ITIL-based initiatives to improve core operations will find themselves in a much better position to support SOA initiatives. Those that have not may indeed find themselves unable to support the increased demands SOA places on IT (not a good place to be).

What do you think? Do you see the dependencies between SOA and ITIL that I see? Do you agree that SOA (because it inherently increases the complexity of IT) will only drive organizations towards stronger infrastructure operations and controls- and thus more towards ITIL? Let me know…

Joe

Also, check out our new White Paper on “Developing the Busines Value for ITIL”.

The emphasis today around Change Management is establishing a good workflow to speed up the request and approval process. All well and good, but let’s fast forward and declare that part of journey over and pretend we’re so efficient that we can submit and approve 50 change requests a day. While we’re at it, let’s also assume you are also proficient at detecting and resolving collisions among a batch of RFCs.

The next challenge might be how do I really increase my level of confidence for critical and n-tier changes. Why? Because you can’t totally rely on analysis, sometimes you have to insert and evaluate the change in an actual environment. Obviously you can’t do this in a real production environment but you can in a replicated virtualized environment.

Virtualization allows you to create multiple and different types of abstract or logical servers on real physical machines without dedicating the machine to a particular operating system or application function. I’d be surprised if any IT shop today hasn’t already deployed products like VMware, Virtuozzo, Xen etc. This technology is a great opportunity for change management (and functional testing too) since you can build a replica of your product environment, roll in the change and evaluate the results. These virtual machines can be destroyed if you are simply using it as a lab or it can be migrated directly if you have a virtualized data center. Additionally you can create and restore snapshots for ongoing problem analysis. Ok I admit it’s a fairly advanced topic for the process world of ITIL but if you?re organization is already investing in VMware or similar products then take a look at how this technology can be leveraged to further mitigate change risk.

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Every well designed process or system relies on a feedback mechanism to ensure stability and to achieve a desired goal (that’s right, a process is a small system and not a Visio diagram). That?s simply a text book definition from school, but I?ve certainly come to respect the need for feedback in life as well as managing business processes.

So if you want your ITIL Change Management process to be more than pumping paperwork faster, then consider what feedback controls need to be designed into the workflow.

Here are some control points to design in:

Unplanned (aka unauthorized) changes - your CMDB should have capability to kick out daily alerts for CIs with change events that are under configuration control and not have a recently scheduled production change.

Business Verification - your workflow should allow the business representative to verify that certain types of changes are working as planned from the end user?s perspective.

Operational Monitoring - the changed CI is being monitored (or not if that was the type of change). If monitoring isn?t the appropriate mechanism for verifying a particular change then a test script or inspection should be run upon rolling it into production.

Production Operations Check-off - indicating that the RFC was promoted to production Operations successfully or rolled back

In addition to feedback for individual changes, the overall process should be periodically checked using management metrics.

Management KPI (Key Performance Metrics) trend the process results. Some examples are decreasing (hopefully) preventable errors, reduction or steady state number of emergency changes, or a reduction in untested changes. Now an undesirable trend is not always due to a poor process. People may simply be making errors in judgment. However, KPIs trending out of the desired limits may be telling you the process itself needs to be reevaluated.

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

People don’t seem to take the ITIL PIR concept seriously. Reviewing changes and projects are like hated exam papers. When they are turned in, no one wants to look at them again, regardless of grade or outcome.

But the PIR is an opportunity to learn and to avoid repeat mistakes thereby freeing capacity. And isn?t the lack of capacity one of the chief complaints from your staff?

So if you agree, your next question will probably be how to institutionalize the PIR into a formal component and ensure that the feedback loop is not broken?

The PIR needs to be owned by the original authorizing agent, typically the CAB. The rational is that people or teams who authorize something are accountable for the results.

Individual performance should include PIR contributions bonus points for identifying good corrective action, penalties for repeat failures. Plus it?s a concrete and easy metric to track.

Changes can be 1) bundled for efficiency or 2) setting a risk threshold for when a PIR is required. So you can?t use the excuse there?s too many to review.

Enabling workflow technology is needed (please don?t build your own) so the process will be enforced.

Yes and I have to say it, IT leaders (i.e. not managers) must expect improvement and reward individuals who help avoid repeat mistakes. If you only reward staff by solving 911’s then when will you ever stop to sharpen the saw?

Download Evergreen’s free Change Management Policies and Procedures Guide

Last time I shamelessly teased you by stating that speed, quality and cost can all be improved at the same time. Now I’ll tell you how I’ve seen it done in real-world IT shops.

Here’s the secret: they implemented strong, mature ITIL-based Configuration, Change and Release Management.

Here’s why it works: as I said, these three processes are tightly linked at almost every step.

For example, your planned changes (RfCs or Requests for Change) are assessed for impact and risk and which Configuration Items (CIs) are involved by using the relational data about your infrastructure that?s stored in your CMDB (Configuration Management Database).

Then, the Change Management process hands off the actual implementation of many (but not all) changes to the Release Management process, which is responsible for building, testing and implementing the actual changes to the infrastructure.

And of course, the CMDB gets updated with the new information about the CIs that have changed.

Because of this tight linking, smart companies are able to build in a high degree of control and quality checkpoints. For example, if a planned rollout fails, you want to be able to trace the cause of the failure back to its origin. When you build mature processes and tight controls, then review and act on the data and metrics you capture, you have specific, clear, measured information that you can use to make improvements in your policies and processes and procedures. It?s a continuous feedback loop.

Result: your operations become more efficient. Your shop can deliver more changes, with higher quality and reliability, at lower cost. CIOs love that stuff.

Till next time, keep up the good work, and ask yourself: ‘in our shop today, when a change causes problems, do we rigorously go back and find out not only the technical cause of the issue but the process or procedure gap that allowed the tech problem to sneak in?’

Scott Braden

Download Evergreen’s free Change Management Policies and Procedures Guide

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

When we’re working with clients to help them map out a long-term plan for ITSM (IT Service Management) using ITIL best practices as a guide and benchmark, one of the most important questions is “Which ITIL process should we work on first? Second?”

Well if you read my blogs, you’ll know my answer is going to depend on the results of the assessment, which makes heavy use of ITIL KPIs and metrics that IT and the business would like to see improve.

What’s not always so clear for clients is how to translate a business requirement or SLR (Service Level Requirement) into specific process changes that are needed to meet the goals.

For example, most businesses I’ve worked with in the past few years are looking for some combination of improved speed for IT to deliver changes, without hurting service quality and while keeping costs under control. Some of you are laughing already, as you recognize the old joke about ’speed, quality, price – pick any two.’

But, it is in fact possible to improve all three, at the same time. One of the most common examples I see is in the areas of Change, Configuration and Release Management. These three ITIL processes are very tightly linked, so that we frequently recommend that clients begin their SIP (Service Improvement Program) by focusing on these together, or at least in a very compressed time frame.

Next time, I’ll tell you why – till then, keep up the good work, and ask yourself “of the Changes our shop puts into production, how many are on time, on budget and produce no unknown errors?”

Scott Braden

Download Evergreen’s free Change Management manual

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

When I’m working with clients on ITIL awareness training or conducting an ITIL maturity assessment, there’s always a tension between ‘what the official ITIL book says’ and ‘how can we implement ITIL in the real world?’

For example, the ITIL maturity model defines four levels of maturity - Repeatable, Defined, Managed and Optimized. So for a given ITIL Process, such as Configuration Management, we assess the client?s current state and assign a score. Looks really simple, on paper.

But in the real world, it’s not so clear. For example, ITIL assumes (or at least strongly recommends) that you have consistent company-wide policies and processes. But very few real-world IT shops have common processes - whether ITIL-driven or not - even between adjoining departments within IT. So- how do you score the company on the maturity scale?

You would be correct if you answered: “with much debate”.

That’s why it’s so important to get past ‘the official ITIL Configuration Management Process’, for example, and instead ask questions based on KPIs (Key Performance Indicators). For example, in Configuration Management one of the usual KPIs is the accuracy of the CMDB (Configuration Management Database) as measured by periodic audits of the data. This is a specific number, arrived at by a specific, defined process that nobody can argue with.

So when you’re considering your ITIL maturity level, think in terms of measurements, not in terms of comparing the descriptions of your processes with the text in the ITIL books.

Till next time, keep up the good work and remember - what gets measured gets improved.

Scott Braden

Download Evergreen’s white paper on developing the business value of ITIL, including the development of metrics, at “Developing the Business Value for ITIL”.