ScottBraden posted on December 24, 2005 01:54

Welcome back! I suppose that one normally expects that business activity tends to slow down toward year?s end as people focus on preparing for their holiday activities. Not so at Real World ITIL, however. The team here has had a very busy couple of weeks since our last entry.

Our current project involves helping a major international financial services firm implement Service Level, Configuration, Incident, Change, Capacity and Availability Management for a portion of their global IT organization. Over time, we expect that this project will serve as a springboard for the eventual introduction of ITIL-based processes into the rest of their IT.

Much has been written about how lengthy ITIL implementation projects can be - sometimes running into years. While this can certainly be true in some cases, sometimes our business drivers demand better performance than that.

What’s making this project especially interesting is that we only have about a 6-month timeline to get the essential elements of these six processes in place. This naturally begs the question ‘what do we consider the essential elements of ITIL?’

In this author’s view, the most essential elements are the lines between the boxes on the widely-published diagram of ITIL’s 10 core processes. While it’s certainly helpful that ITIL defines what the 10 processes are supposed to do, it’s really the integration of the workflows that make IT Service Delivery run better. To this extent, it may benefit larger organizations who are approaching ITIL for the first time to seriously consider implementing more than one process in a sensible way and get the interrelationships right than to first do only one process (usually either Incident or Configuration is chosen) in greater detail.

Though ITIL’s documentation presents this concept by describing the counterparts of each core process, it could really say a lot more about the whats and whys of the interactions between the core elements. (Do you agree? Click on the Comment link below to share your thoughts.) Perhaps the next version of ITIL will do better in this regard than the current version does. I believe that more detail could safely be provided without sacrificing the (understandable and valuable) generic nature of the standard.

For example, there should be a very close operating relationship between Capacity and Financial Management: Capacity provides forward-looking capacity plans to Finance, who then uses the information to establish forward-looking budgets. Finance in turn feeds actual historical spend data back to Capacity, who uses the data to, as ITIL states, manage cost vs. capacity. Then, Capacity ( using additional input from the CMDB ) sends ‘cost per unit capacity’ data back to Finance, which uses the data to generate accurate chargeback statements to IT’s clients.

It’s in documenting this back-and-forth motion of specific kinds of information and the reasons for the data flows that the Library falls short in terms of detail. Yet, getting these interfaces running is where, over the long run, the greatest overall efficiency improvements are likely to happen.

In the present case, our short timeline has caused us to reflect on the essential truth that we’re not really building six different things (though of course we have to develop at least six detailed workflows) but rather a single, integrated workflow for operating six necessary IT functions. On a schedule this aggressive, there’s no avoiding the fact that we’ll only be able to deliver a ‘Version 1.0′ process structure toward the end of the second quarter, then have to spend the next year or so adding detail & smoothing over rough spots.

We therefore must focus on getting the overall ITIL architecture right the first time, then fill in most of the details later. This means that we’ll spend more time in process integration workshops between the six process teams than in detailed design workshops within the teams.

Of course, we haven’t forgotten that ‘the devil is in the details’ when it comes to successfully getting real life workers to follow unfamiliar workflows. Implementing processes that are too vague can certainly lead to the failure of the whole ITIL initiative. Nonetheless, we believe that, when required to implement multiple processes simultaneously on a tight deadline, an appropriate balance can successfully be struck between the level of detail and the usefulness of the process designs.

An iterative approach to process implementation can work well - especially if the overall process architecture is correct from the start and also that workers and their managers have had their expectations set appropriately. Our main burden instead will be to employ effective organizational change leadership methods to ensure process adoption. We must also invest sufficient effort into facilitating appropriate political agreements between essential IT functional areas to ensure smooth handoffs of operational inputs and outputs.

Next time, we’ll do a ‘deep dive’ article on one of the least written-about processes: Availability Management.

Until then, we wish you and yours a happy and relaxing holiday season. Thanks to all of our readers for sharing our adventures through 2005 - we appreciate you following along.

Real World ITIL will be on vacation next week, so see you back here in 2006 for more adventures in IT process improvement - when we hope to hear from you!

Regards,
Scott (your moderator)

Technorati Tags:

—–


Posted in: ITIL Implementation  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted in: ITIL Implementation  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Welcome back to Real World ITIL!

It’s been a few weeks since our last entry, during which interval we completed the white paper mentioned in our last entry. The writing part is done now and we hope that it will be published soon. We’ll let you know, so keep watching this space!

Also in the interval, our time has been consumed with two ITIL projects: a strategic roadmap for the implementation of several ITIL processes for the government of a certain island; and leading implementations of Service Level, Availability, Capacity, Change, Configuration and Incident for an IT component of a major European bank.

So, here at Real World ITIL, our effort will always go first to actually doing ITIL in the real world as opposed to only blogging about it.

Nevertheless, we think it’s important to share some of our stories through this blog. We hope to hear some of yours, too!

On that note, we’ll focus this week on responding to all of the great responses we’ve gotten on our last few topics. THANK YOU again to everyone who has taken the time to write in - we really appreciate the chance to have substantial discussions with you about ITIL.

Before we jump into our responses, though, I’d like to share an interesting observation I heard recently from Jim Freeman. In a chat one day about the nature of Our Favorite Subject, Jim likened ITIL to a practice called ‘Extreme Programming’. That was a new term for me.

Apparently, Extreme Programming is a type of Rapid Application Development methodology, which, naturally enough, is meant to speed the creation of software.

According to Jim, Extreme Programming makes the assumption that ‘extremely good’ programmers have developed better ways of working than most other programmers have. We assume this means that their coding and communications habits are better than most. Of specific interest to us, though, is its presumption that good programmers also use better workflows to accomplish better programs in less time.

The principle is to gather together small groups of extremely good programmers and then observe how they interact over time as they develop applications. If you then carefully document the workflows and practices within the small groups, you are by default documenting ‘best practices’ processes for programming. If all programmers on the project are then taught these practices, the overall quality and productivity of the larger team will naturally improve.

Sound familiar?

Jim’s analogy, therefore, is that ITIL is like documenting the practices of an extremely good IT department - one that all IT departments should aspire to be. I think this is an intriguing and powerful thought.

Would you agree? Share your thoughts on Jim’s analogy by clicking on the Comment link below.

Thanks, Jim, for sharing your thoughts - we hope to hear from you again!

Now, to John, Bernardo, Ric, Brian, and Dr. ITIL (that is, if you’re still out there after our long hiatus :-) we’ve responded to each of your comments as follows. We hope you’ll stay in touch!

For Ric P: click

For John W: click

For Bernardo: click

For Dr. ITIL: click

Just before we go, we’d like to call our readers’ attention to the recent results from an ITIL Maturity Survey recently conducted by Evergreen Systems - it contains some interesting findings.

Thanks for reading Real World ITIL. Until next time, have a great week!

Regards,
Scott (your moderator)

Technorati Tags:

—–


Posted in: ITIL Implementation  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted in: ITIL Implementation  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Just finished up a quickie assessment of change control for a long time client. You know, when we get invited to look at a company’s environment, there are always layers upon layers of people, processes, tools, organization, culture… and politics.

In this case, we were asked by one Senior Director to assess change controls in the enterprise, and we both knew full well that another Senior Director, reporting to a different VP, carrying the Governance title, is the one who owns “change”.

It made for some interesting interviews! Along the lines of “yes, I own this process, but that other person owns all the tools that allow this process to happen, and lots of other people are the ones actually doing the work.”

We in IT casually throw around terms like “Billy Bob owns the raised floor” and “Janie Sue owns the backup process for the Unix environments” and “Herman’s the admin for that particular server.”

But it’s not that simple. Billy Bob has to rely on the facilities department, the OS team(s), the network team, etc. Janie Sue relies on Billy Bob because that’s where her Unix servers and storage live. She also has to work with the various app and server admins, to get their data and apps backed up, failover tested, all that good stuff. And those people in turn deal with Billy Bob and lots of other process owners and internal service providers.

Now let’s take this very complicated, multilayered, partially (at best) undocumented situation… and plug it into a CMDB.

As you know, one of the commonly discused characteristics of a Configuration Item is… ownership. And ITIL include “process” and “documentation” as possible Configuration Items.

So which CI’s does Janie Sue own?

The tapes / tape drives / robots? Sure, tangible, physical things are easy.
Backup procedures, offsite policies? Yeah, I’m throwing softballs.

How about the contracts with the offsite storage vendor? Hmm.. might be a bit of discussion with the contracts / vendor management groups about that one.

How about the process of handling “restore” requests? The service desk can take the request (hopefully via web), but who does the work? In many shops, it’ll be one of Billy Bob’s people to pull the tape, bring it to Herman, who does the restore. Unless it’s the app owner or the database guys. But “restore process” is clearly a Janie Sue responsibility… even though nobody that reports to her may ever actually do any restore work.

Are you still with me? So how the heck are you going to build a cohesive, change-managed CI model that captures all of this stuff?

You’re not, of course. You’ll go where the ROI lives, which is in tracking the relatively easy stuff - physical assets, software, and the most important relationships so you can get beter pre-change impact assessments.

There’s plenty of really hard stuff just in that “easy” stuff - more on that later.

Happy Friday.

Scott Braden

Technorati Tags:

—–


Posted in: ITIL Implementation  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

IT Managers typically allocate precious (and sometimes inordinate) human and financial resources to implementing technology solutions to combat security breaches, even as research shows that a significantly larger part of the problem is inadequate policy development, process implementation and enforcement.  Indicative of this, Gartner reports organizations that incorporate a vulnerability management process will experience 90 percent fewer attacks than organizations that invest the same resources into intrusion-detection systems.

“Conventional wisdom is that technology alone can solve the increasing threat of security breaches by creative hackers, internal attacks, spyware and malware, among others.  The reality is technology solves only a portion of the equation.  Of equal, if not greater, importance, is implementation of these solutions in the context of a rigorous IT planning process and an enforceable, enterprise-wide policy,” says Don Casson, president and CEO of Evergreen.  “Unfortunately, two factors are causing IT managers and their superiors to believe that technology can do it alone.  First, technology providers promote their solutions as being able to solve the problem.  Second, many enterprises invest with the goal of meeting security requirements for one specific compliance issue – say Sarbanes-Oxley or HIPAA – without taking a holistic view.   Often the result is a false sense of security.”

A Holistic Approach Will Include a Global Plan and Enforceable Policy

Enterprises need to take a holistic approach in which they first develop a process for security implementation across the entire organization.  This plan needs to be rooted in the best practices outlined by the IT Infrastructure Library (ITIL) and the Control Objectives for Information and Related Technologies (CobiT), which function as guidelines for a planful approach to IT implementation.  Out of this process two things should emerge – first, a global plan for the kinds of specific technologies needed not only to defend against specific attacks and meet certain compliance requirements, but also to ensure protection at every level of the enterprise.   Second, there must be an enforceable policy for the entire organization.  This policy, while central to IT, should also extend across the enterprise.  For example, employees can be unintentionally downloading malware when they access web sites at their desktops, which technology might detect.  However, without a policy in place it would be up to the individual to decide whether to continue downloading.  A policy-driven approach negates this possibility.  

Evergreen works with some of the world’s best known brands in insurance, finance, healthcare and consumer products to develop and implement strategy and standards-based approaches to IT.  We recommend that IT departments adopt a multi-point analysis that will lead to more appropriate acquisitions and implementations of security solutions and, most importantly, protect vital assets. 

Adopt a Process-Driven Approach to Developing an IT Strategy and Policy

Leveraging the guidelines set forth in ITIL and CobiT, Evergreen works with organizations to assess current technology structures and policies.  Out of this analysis emerges a holistic plan for IT acquisition and a policy-driven approach to deployment and enforcement.  The following approach simultaneously maximizes security and return on technology investment:

  1. Rank all potential risks, including areas for potential breaches, as well as implications should such breaches occur.  The implications portion should include an assessment of exposure relative to compliance with regulations, as well as to the security of the overall organization;
  2. Develop a policy and processes for addressing each of these risks;
  3. Convert process into a concrete implementation with the acquisition of technology solutions that support the policy (e.g. if the problem is at the desktop, and policy is written to address this, it is reasonable to assume that the technology investment should be in an end-point security offering); and
  4. Constantly evaluate effectiveness of the policy and processes relative to the evolution of risks.

“Only after organizations adopt a strategic approach geared to developing and automating policy and processes, can they fully and effectively deal with the growing problem of security breaches,” continues Casson.  “Our approach is to link every technology acquisition and implementation into a process and policy-driven framework.  Only after establishing such a framework, should organizations invest in technology solutions, with the piece of mind that they support a measurable and enforceable strategic framework.”

Click here to read more Management Tips from Evergreen Systems, Inc.

Technorati Tags:

—–


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted in: ITIL Implementation  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Search

Calendar

«  March 2010  »
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234
View posts in large calendar