Since I haven't written anything in quite a while, I'm not sure which of those facts you find most shocking.

Personally, I'm voting for the house being complete as the most shocking news I've heard in a while (except, of course, the Patriots losing the Super Bowl)!

I guess technically, I'm not actually complete with the house yet.  I am, however, in the final stages.  The floor guys are sanding and finishing the floors even as I type and the landscapers are working away on the outside.  In theory, I should be in the house by the end of this month (February).

Needless to say, this process has taught me a great many things about the construction industry.  For example, when a sub-contractor says, "I promise I'll be there tomorrow" he really means "If I happen to finish my other job and can't pick up any other work, there's a remote chance I'll grace you with my presence and swing by your pathetic house!"  It's also, however, served to reinforce to me something about the IT industry.

After 11 months I've concluded, that the typical contractor really doesn't care about the big picture (i.e. my house).  They're strictly concerned with just their work (and their paycheck) and have very little (if any) regard for how it integrates with the other aspects of construction.  Further, because they don't know whose house it is, it's difficult for them to make any personal investment in the project - it's just a job.  As a result, I've spent quite a bit of time (and money) having to redo things that weren't done right the first time.

What does this have to do with IT?!?!

Lately I've been spending a good bit of time in the world of ITIL v3.  Between visiting with customers, teaching the Foundation Bridge class, and taking the Service Manager Bridge class, I've been involved in quite a few discussions about the nature of service and about IT facilitating business outcomes.  In all of those discussions, there's been a consistent theme - unless the people in the IT trenches understand how what they do directly impacts their customers, IT has little hope of providing real business value on a consistent basis.  As always, it begins and ends with people.

I was reminded of this fact one day at the beginning of my construction odyssey while reading "Building Your Own Home for Dummies" (yes, there is such book).  In one of the chapters about dealing with sub-contractors, it suggested bringing cookies to the job site in order to encourage the workers and help them make a connection with their work and you, the homeowner.

It's the same in IT.  Whether through technology, processes, or organizational structures/initiatives, we have to ensure that people don't have to go too far to see the link between their actions and the upstream business impact.

In the next couple of weeks (in between packing and moving) I'll share some thoughts on things you can do in each of these areas to make sure you and your IT organization don't lose sight of who you're building the house for.

By the way, the cookie thing works!

Every year, someone (or a group of people I suspect) get together and decide what items to offer in the catalog.  I've always wondered how they decide what makes it into the catalog and what doesn't.

I bring up Neiman's catalog because lately there seems to be a lot of buzz around another type of catalog - the Service Catalog.  I frequently run into IT folks asking a lot of good questions about it.  Do I need one?  What exactly is it?  How will it help?  Can I get Fries with it?

Origins of the Service Catalog

I once heard a CIO say, "My job is to convert cash to value".  I love that phrase because it really does capture what should be the service-oriented nature of IT.  An IT professional's job is to provide a service that adds value to the business in exchange for funds.  The challenge that many IT organizations face, however, is how to best communicate that value to the business.

The simplest approach is to write it down.  Come up with a list of the services that IT provides and share that with the business.  Thus the Service Catalog was born.  In its earliest incarnations, the Service Catalog was simply a list of what IT did for the business that the business valued.  If the CEO ever confronted the CIO with "what have you done for me lately?" the CIO could produce the service catalog to demonstrate his/her value.  The service catalog was aptly named because it was intended to be a catalog of the "services" that IT provided and not just products.  For example, a laptop is a product.  However, providing that same laptop to a new employee within one day of their start date could be considered a service - more on this later.

As time went on, many CIOs - pressured by the need to be more cost effective  - were faced with the need to not only passively meet demand for service, but rather to try and shape the very demand for those services.  One way to do this was to charge for the service.  According to ITIL, one reason to implement a chargeback system is to influence customer behavior.  If the business now has to pay for service, they will most likely start to think about how they consume it.  To facilitate this process, cost information (as well as what would be delivered for that cost) was added to the service catalog.

Now, IT could use the service catalog to not only communicate the things it did for the business but also to communicate how much it would charge to do those things.  The business, in turn, could use the catalog to decide whether or not to acquire that service.

It Depends!

At this point, many IT organizations start asking the question, "what should I put in my service catalog?"  Before we answer that question, let's take a quick look at the definition of a service.  Consider the following definitions:

From the Oxford English Dictionary:
"...work done for; benefit conferred on another; maintenance and repair work; provision or supply of what is necessary (e.g. supply of gas, water etc). Yes there are goods involved, but one is not ordering or purchasing the good, one is ordering or purchasing the service, which may incorporate the good in some way"

From the ITIL v3 Glossary:
Providing something of value to a customer that is not goods (i.e. physical things with material value).

From Wikipedia:
A process that creates benefits by facilitating a change in customers, a change in their physical possessions, or a change in their intangible assets.

I think most people would agree that the common thread here is that a service is something done by someone for someone else that is valued by the receiving party.  It's really that simple so let's leave it there!  Translating that to IT terms, a service is something IT does that the business values.  Once again, let's keep it that simple.

So now, let's go back to the question of what to put in the service catalog.  If I want to use my service catalog to communicate with the business, then I'm going to include the key things that I do for the business that they value.  These "key things" are commonly referred to as "business services".  Thus I could include services in my catalog such as:

* Sales Force Automation Service
* Patient Care Service
* Order Entry Service

For each of these services, I would add cost and corresponding service level information to the catalog to aid the business in their decision on whether to acquire the services.  Thus, the Sales Force Automation service may cost the Sales Department $1,000 per user per year for "Platinum Level" service, $750 for "Gold" service and "$500" for "Silver" service.  The sales department could then manage its expenditure by figuring out which sales reps needed which level of service.

Beware the Duck!

At this point, I've cataloged my services to communicate value as well as the costs and corresponding service levels.  That's a great start.  But what happens when the number of "key things" (i.e. business services) that I can provide is being impacted by all of the "minor" things my staff is doing.  I once heard this referred to as "getting pecked to death by ducks".  One ornery duck might be considered a nuisance.  Enough of them, however, can be lethal!

In the same way, a small number of "minor" requests for service may not impact the overall business service delivery capability.  Enough of them, however, most assuredly will.  Accordingly, IT must shape and manage the demand for these "minor" services as well as fulfill them in a more cost effective manner.

One way of doing that is to use the service catalog to also document the "minor" things that IT can do for the business.  Some people refer to these as "supporting" services.  Others call them "requestable" services.  Examples of these types of services include:

* Setting up email distribution lists
* Resetting passwords
* Provisioning laptops

Regardless of the qualifying term used, however, the key point here is that these are all services just as Sales Force Automation is a service.  Clearly, they are different in terms of scale, scope, delivery method, etc. but the fact is that they are all services offered by IT and thus should all be listed in the service catalog.

Enter BMC Service Request Management (SRM)

In practice, however, you would potentially want to present different "views" of the catalog to different audiences.  The business customer (i.e. the person writing the check) is probably most interested in the business service view of the catalog.  On the other hand, the end users in the business are focused on the "supporting" or "reqeustable" services in the catalog.  As I pointed out earlier, if not properly managed, these are the things that can overwhelm an IT organization and impact its ability to deliver the business services at the required service levels.

To address this issue, BMC is introducing the BMC Service Request Management (SRM) solution.  This solution allows IT organizations to catalog all of their "requestable" services and then automate much of the submission, tracking and fulfillment of end-user's requests for those services.  To the extent that routine requests can be handled in an automated fashion, IT support personnel are freed up to focus on the provision and operation of the more strategic business services.

How much is that Castle in the Window?

In the end - just like Neiman-Marcus - IT organizations need a place to capture and publish all of the "things" they provide to their customers regardless of scale (e.g. the $3.8M membership to The Club At Castiglion Del Bosco in Italy vs. the $50 tin of cookies - both found in the N-M catalog).  The service catalog is that place.  SRM represents a first step in the development and leveraging of the service catalog that IT organizations need.  Stay tuned as the story unfolds!  Anyone want to go in on the castle?!

A couple of weeks ago I visited with a customer who was trying to figure out how to "move our operations group to the next level".  They had implemented several of the ITIL processes within their organization (e.g. Change, Config, Service Desk, and Incident) but were still struggling to show any gains in either improved service or improved efficiencies.

As we dug a little deeper into their situation, I discovered that they were a very silo'ed organization.  Although they did have someone looking at the performance metrics of their group (operations), there was no one responsible for looking at the metrics across functional silos.  Also, the ITIL processes implemented were just within the ops group.  Finally, there really wasn't a concept of "service" within the organization.  By that I mean that they didn't think in terms of attributing the work done within the organization directly to the provision and operation of services consumed by the business.

In the course of our discussion, I shared how BMC's IT department was organized when I joined BMC back in 2002.  As Director of Service Management, I reported to the CIO and was responsible for monitoring, measuring, and reporting on the quality of the services provided by IT and consumed by the business.  I was a peer with the Director of Application Development and the Director of Infrastructure and Operations and thus was able to independently measure and report across the functional silos to provide an independent, holistic view of the service being provided.

Today, I'm seeing more and more companies moving toward this organizational model.  In the absence of this cross-functional role, you inevitably wind up with a silo'ed view of service performance.   For example, this same customer shared a situation where his desktop support team was getting heat from the business for failing to provision laptops for new employees within the five day SLA.  Meanwhile, he had metrics for his team showing that it took on average only a half-day for the desktop support technician to image and deliver the laptop upon receipt.  The issue, of course, was that procurement, the external vendor, and the asset management folks required almost three weeks to order, ship, receive, and inventory the hardware.  The SLA was put in place with no supporting Operating Level Agreements (OLAs) or Underpinning Contracts (UCs).  It was done in a vacuum.  Someone responsible for measuring the service end-to-end, however, is going to look at all aspects of delivering the service prior to entering into Service Level discussions with the business.

The other problem you run into is if the role is not placed sufficiently high enough in the organization you'll wind up with the fox guarding the hen house.  I've heard more than one story from service managers reporting to the VP/Director of Operations that they've been asked to alter their reporting formulas so that the ops team always looks good.  Yes, it happens!

To avoid these types of issues, organizations need to designate a Service Manager and then give that person the responsibility and authority to look at service across the enterprise.  Ideally, they should report directly to the CIO or at a minimum, high enough in the organization to be able to affect change across the organization.

At the end of the day, I contend it's a little difficult to implement Service Management without a Service Manager.  To use the words of this customer, "it's like pushing a boulder uphill!"

Now, for the nine of you who've been following my blog, don't get too excited.  I'm not referring to the house I've been working on for over a year now.   I'm referring to my new home within BMC.

On October 1, 2006 I moved into the Technology Architecture Group within our CTO's office.  Officially, I'm now a Solutions Architect focused on ITIL, and Service Management.  I work with our product managers and product architects to help ensure that our solutions meet real world needs and are aligned with ITIL and industry best practices in the area of Service Management.  I love it!  It gives me the opportunity to leverage my experience working in IT, my knowledge of ITIL and Service Management, and the feedback I get from visiting with BMC customers.  In the words of Candide, "It's the best of all possible worlds!"  So stay tuned as I'll be sharing some of the things I run into in my comings and goings.

And by the way, in case you're wondering.  I actually will break ground on my new house in the middle of February!  I can't wait!!

Unfortunately, I see it in the IT field as well. Far too often, business customers and end-users feel as if their IT departments are missing in action (or moonlighting in the construction industry)! Requests for service are either ignored or take longer than expected to be addressed. Communication during and about service outages are either too infrequent and cryptic or completely non-existent. For their part, IT departments may actually be working on trying to help, but no one outside of IT ever knows about.

To address this issue, IT departments need to have an effective Service Desk function and a supporting Incident Management process. Together, these two combine to ensure that user requests and issues are addressed in a timely manner in accordance with business priorities and agreed-to service levels. For many IT departments, this combination represents a great starting point for their IT Service Management (ITSM) initiatives. An effective Service Desk will provide immediate benefit to the user community and allow IT to achieve a "quick win" with the business. The business needs to know that someone is there to respond to its needs. The Service Desk fulfills that objective. Specifically, a Service Desk can provide the following benefits:

• Improved Customer service, perception, and satisfaction
• Increased accessibility through a single point of contact, communication and information
• Better quality and speedier turnaround of customer requests
• Reduced negative business impact in the event of service outages/degradations

While this may seem obvious to some, I still run into quite a few people who want to begin their ITSM efforts with a CMDB implementation. Although this may make sense in a particular situation, in general, it is not the best place to begin. Among other reasons, it will not be immediately visible to the business and thus will not help you garner the support you need from the business to keep the program moving forward.

At the end of the day, the business wants to be assured that IT is there, ready to meet its ever-changing requirements and priorities. A timely response and resolution goes a long way to providing that assurance.

Now, if only builders and designers had Service Desks!!

Last month I closed on the lot where I intend to build my new home.  While I fully understand that the lot will soon be the location for my house and will serve as the foundation for its construction, I have to admit that I still struggled with the notion of paying that much money for a bunch of dirt.

That same week, I happened to be speaking at a briefing on Configuration Management and a woman there struggled with a similar issue.  She was asking about how to cost justify the implementation of a Configuration Management process and the accompanying Configuration Management Database (CMDB).  She was looking for Configuration Management return on investment (ROI) measures.  I'm discovering that she is not alone.

Today many organizations are either actively pursuing or seriously considering CMDB projects.  Unfortunately, many of these projects are doomed for failure.  I believe that they will fail not because they didn't have the right technology or bright people working on the effort.  No, I believe that they will fail simply because they never understood what it meant to succeed.  What constitutes a successful CMDB implementation?  When you're "done", how will you know if it was "worth it"?

Ultimately, I will measure the success of my lot purchase by the resulting house that I can build on it.  In the same way, IT organizations should measure the success of their Configuration Management implementations by the resulting IT processes that can either be enhanced or built upon the information stored in the CMDB.  The goal of Configuration Management is to provide a sound basis for ITIL processes such as Incident, Problem, and Change Management.  Imagine how nice it would be to instantly know the business impact of a failed IT component when trying to resolve an incident.  This is information that a good Configuration Management process can provide.  Or, think about how much the business would appreciate knowing upfront that the change you're contemplating is going to impact several key customer-facing services.  This information is also available via a good Configuration Management process.

If done properly Configuration Management can provide key information to virtually all of the service management processes.  It is on this basis that its cost of implementation should be assessed and justified.

I didn't buy my lot in order to say I am now the proud owner of $135,000 worth of dirt.  I bought it to build my home upon.  Don't implement Configuration Management in your organization in order to say you're the proud owner of a CMDB.  Implement it to build your service management program upon.

Oh, by the way.  Here's one more thought.  Don't think in terms of a CMDB implementation project.  Instead think about implementing Configuration Management.  The CMDB is simply the tool you use to enable the process.

Okay, I'm now off to go check on my dirt!! 

Y'all be careful out there!

Unfortunately, many IT organizations today start their service improvement programs the same way I started my house plan hunting project – with no objective measures of success. As a result, they may spend a great amount of time and resources only to still wind up with a dissatisfied business customer.

It is absolutely vital to any Service Improvement Program to define objective measures of success up front. To say you want to improve availability is much like me saying I want a one or two story house plan. There are literally hundreds of thousands of plans that fall into that category (trust me on this – I’ve looked at most of them). Without some objective criteria (e.g. the kitchen must have an island and be adjacent to the great room, which must be at least 16’ x 20’) I would spend years perusing plans and not get any closer to selecting one. In the same way IT organizations that start without specific objectives will never be able to definitively declare completion or success.

To avoid this problem, I suggest following the S.M.A.R.T. approach when defining service improvement success goals. This approach requires your goals to be:

Following the S.M.A.R.T. approach to establishing success criteria will not only help you know exactly what you’re trying to achieve, but will also help your customer know exactly what they can expect and when they can expect it. As I’ve mentioned before, this expectation management process will go a long way to achieving quality results in the eyes of your business customers.

Okay, let’s see. My house can’t be any wider than 34’, the master bedroom can’t be at the front of the house…

At the end of the second day I was there I took the train to Secaucus and called the hotel to request a shuttle just as I had done the day before.  Dimitrius (the clerk at the front desk) answered the phone and told me that the shuttle was on another run but was on its way back and would be able to pick me up in about 15 minutes.  I said that would be okay and sat down to read the paper while waiting.  Some time later I realized that I had gotten engrossed in the paper and had lost track of time.  I looked at my watch and discovered that it had been 45 minutes since I called for the shuttle.  I called back to the hotel and spoke with Dimitrius again.  It was clear that he had forgotten me and was profusely apologetic.  He said he would send the shuttle immediately and offered to have the driver bring me a "chilled beverage".  I told him that wouldn't be necessary.  The shuttle would suffice.  Once again, he promised me that the shuttle would be there in 10-15 minutes.  After twenty more minutes and still no shuttle, I flagged down a cab and took it back to the hotel.

The next day when I checked out I filled out a comment card and left it at the front desk.  Later that day I received a call from the service manager inquiring about my complaint concerning the shuttle.  I explained that my complaint wasn't about the shuttle not coming to pick me up.  My complaint was about Dimitrius telling me twice that it was on the way when he knew full well that it was a busy night for the lone shuttle.

Unfortunately, this same scenario is played out every day in companies around the world.  IT professionals are unwilling to tell the business that they can't deliver a required level of service and as a result they over-promise and under-deliver.  As I've mentioned before, managing the customers' expectations goes a long way towards achieving quality service in their eyes.  A well run Service Level Management process will help ensure that this takes place.

The other ITIL process that came to mind as I was waiting for the non-existent shuttle was Incident Management.  One of the guiding principles of incident management is that as much as we'd like things to not break or go wrong, they inevitably will.  What separates the world class organizations from everyone else is what they do when things go wrong.  If Dimitrius had taken my cell phone number and kept me updated on the status of the shuttle, I could have made the decision to take a cab much earlier.  In the same way, studies show that in the event of a service outage, if IT keeps the business informed about the progress being made towards resolving the incident, the business is would be happier with a longer outage than they would be with a shorter one and no information.

IT organizations desperately need to work to communicate honestly and openly with their business customers.  It's okay - and in fact, preferred - to tell them that you can't deliver a requested level of service.  Eventually they're going to realize it anyway and at that point you've moved down a few notches on the credibility curve.  It's always a good idea to under-promise and over-deliver.

I haven't decided if I'll stay at that hotel again when I'm back in the area.  I suspect I'll give them another chance - if only to use the free breakfast coupons the Service Manager gave me!!

One of the most challenging aspects of a project - be it building a new home or implementing IT Service Management (ITSM) - is knowing where to start. Many people will argue that Configuration and Change Management (CCM) is the obvious place to start any ITSM effort. The rationale for this is that since most other IT processes rely so heavily on CCM, it forms the foundation for your going-forward efforts. For example, solid CCM processes will help reduce incidents and assist in problem management. While this is true, I contend you might want to consider an alternative starting point - Service Level Management (SLM).

Per ITIL, "The goal for SLM is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service - in line with business or Cost justification. Through these methods, a better relationship between IT and its Customers can be developed." In other words, SLM is all about figuring out what your customers want/expect and then working to either manage or meet those expectations all while considering the cost. Without SLM, how do you know how much service management is required to meet you customer's expectations since you don't know those expectations?

When properly executed, SLM helps IT organizations work with their customers to identify realistic service level requirements based on business objectives. These requirements should then be reviewed with the IT Service Providers to assess the feasibility and cost of providing that level of service. This information is provided back to the customer who can then assess their needs in view of the costs. That's where things start to get interesting! Quite frequently, customers "require" services without an understanding of the associated costs. I can relate. I "had to have" soapstone on my countertops until my builder told me the cost! A properly executed SLM process, however, can help reduce sticker shock and avoid customer dissatisfaction.

I suggest the following few steps to help ease SLM discussions with your customers:

1. Begin expectation management sooner rather than later - In the same way that you never get a second chance to make a first impression, you can rarely correct a customer's initial expectation that you can deliver all of their requirements fast, good, and cheap unless you address it at the first meeting. This requires you to have an understanding upfront of what you're capable of delivering, which leads to the second suggestion.
2. Make sure and involve your service providers early in the process. There's nothing worse than negotiating a Service Level Agreement (SLA) with your customer and failing to include the actual service providers. Not only will they have no "skin in the game" but they may not even be able to meet the agreed-to service levels (as mentioned in step 1).
3. Help your customer separate the "must haves" from the "nice to haves". This should be done based on the criticality/priority of the associated business service. Do I really need that professional grade stainless steel range in the kitchen when the thing I make most for dinner is a reservation?!
4. Make sure and discuss service levels in their terms and not yours. During one meeting, my builder kept trying to impress me with discussions about the type of plywood used on the floor or the number of nails used per stud. Can you say "boooring"?!?!?

These few simple steps will go a long way to jumpstarting your service management activities on the right foot with your customer and steer you towards the best place to start your continuous service improvement program.

Now, if I can just figure out a way to justify that Sub-Zero refrigerator!!

When I come to work these days (to pay for my new house), I realize that many IT folks are doing the exact same thing.  Faced with a plethora of process models, tools, and technologies, they lose sight of their real objective when it comes to IT Service Improvement - improving the service their department delivers to the business.

As Director of IT Service Management within our Business School I have the opportunity to meet with a tremendous number of IT folks around the world who are engaged in service improvement efforts in some form or fashion.  Inevitably, the conversation winds up centering on the question, "how do we know we're actually adding value to the business?"

In this blog, I will share my thoughts, experiences and lessons learned about leveraging the Information Technology Infrastructure Library (ITIL) and Business Service Management (BSM) to achieve the ultimate goal of IT Service Improvement.  Oh yeah, I'll also keep you updated on how my new home building process is going!!