16 July 2008

Getting Control of IT Shared Services - Utility Services Part 1

Cheryl Croce

Cheryl Croce
Sr. Consultant
Veris Associates, Inc.

PrintListen Now

In this first article of a series of five, the author explores how to relieve three of the nine common pain points associated with Infrastructure request fulfillment. By doing so, companies can transform infrastructure request fulfillment from a checklist activity to an organizational strategic asset – request fulfillment as a utility service.

Start at the Beginning! Making Requests Make Sense

Did you ever notice it’s the little things that create the biggest impact? That’s the way our clients and prospective customers feel when it comes to Infrastructure Request Fulfillment.

In general, we know we must conduct thorough analyses, provide cost justifications and maintain the allotted budgets for larger projects. However, it’s the requests that stem from daily operational needs and organizational growth that come as the big surprise at the end of the budget year - things for which project allocations do not account.

The IT Pain Points

In the white paper,
The Games We Play: Conquering the Challenge of IT Request Fulfillment, we identified the following common pain points Infrastructure teams and management experience when it comes to request fulfillment:

Shock to the System: The multiple ways in which Infrastructure teams receive requests - e-mails, telephone calls, taps on the shoulder, and help desk tickets.

“Needs” Brain Freeze: When customers forget there might be rules when they want it and they want it now.

Request Definition Wish Bone: Many customers don’t get what they want or need, because the requirements of the request were not collected or provided.

Purchasing Apple: That lump in your throat may be the realization you’ve overspent on purchases for equipment and third-party services.

Spare Parts: You didn’t realize you had the part already in stock. Or, there’s a part you’ve purchased that’s gone bad and you have no idea where you’ve installed it or what the serial number is for it.

“Architect’s” Elbow: Your technical team’s elbow grease is gone, because they’ve expended it. And you have no idea how, when or why. Change Management is missing from the equation.

Testing Butterflies in the Stomach: Testing is such a fundamental activity within System Development Lifecycle, because in general there are test labs. That’s not the case a lot of times with infrastructure related requests. So, a “let’s try this and hope it works” approach may be used when rolling new components into production.

Writing Communications Cramp: As much as we are connected (you might be reading this on your BlackBerry device or iPhone), it’s interesting we’re still not communicating.

Broken Hearts All Around: Customers look at the end result and say, “That’s not what I wanted. Now what do we do?” And when they say “we” they really mean you, which equates to re-work and exhausted, cranky staff.

Perhaps some of you now are nodding your heads, as these items may look familiar to you. Share your experiences with us: What have you seen in your workplace?

Most IT teams are deluged with requests through different means, and a lot of times this concept is not acknowledged. For example, when we interviewed individuals at a client site about how requests were received, we heard different responses. The CIO told us all requests came through the company’s help desk system. The staff members, on the other hand, told us they received requests not only from the help desk system, but also by e-mail, phone call, taps on the shoulder, hallway conversations, and internal meetings with their IT counterparts.

The Requests Cometh

The requests obtained outside the help desk ticket system are often quickly scribbled on post-it notes and in notebooks.

This ad-hoc repository causes three issues:

Inability to Prioritize Work is Shocking! Managers have no true view of where their team members are engaged, and therefore they assume they are free for major projects. As a result, managers didn’t understand why they have low morale or higher turnover, and team members are frustrated their managers don’t understand how to prioritize the workloads to meet customers’ demands.

We Know You Want It Now, But Is the Request Valid? Then there’s the question of whether a request is valid at all. We live in an “I want it now” society. We blink and technology is obsolete. We blink and our company has decided to go in a different direction. Now. Not tomorrow. Not when you can get to it. But now. That’s a difficult expectation to manage for IT. IT is a multiple personality. There’s the side of IT that needs to maintain its architectural integrity and protect its structure from changes that do not make sense for the environment. Then there’s the other side where customer service and fulfilling customer needs is inherent. How do you say no when clearly a request is a square peg in a round hole?

Request Definition - What Was That Middle Part? When IT team members are eventually able to get to the requests recorded outside the help desk system, they generally remember the broad scope of the request. However, there’s only so much memory can provide in terms of understanding what the requirements are. Depending on where the request came from and from whom, team members may be less inclined to go back to ask questions and instead, knock the request off their list of things to do. The end result of this approach is low customer satisfaction.

Fixing the Pain Points

How do you fix these pain points? We recommend the following:

Start At The Beginning. Establish a single point of entry into your request fulfillment process. No exceptions.

3 Es - Educate, Empower and Evangelize. At Veris Associates, we love how a good process can make a difference in a customer’s way of working. However, we also acknowledge process isn’t worth a hill of beans if you haven’t incorporated it into an IT organization’s and customer’s culture. Once you’ve established a single point of entry, educate your IT staff – including the CIOs, Directors, and Managers – about the single point of entry. IT Leadership will need to provide customers with communications on this expectation, especially if it is a new concept. As part of this awareness campaign, IT team members must be empowered to steer customers to the single point of entry.

Remove the Square Peg From The Round Hole. As part of the single point of entry, you may want to add questions to help you determine if a request is valid. For example: Is this request tied to a project cost code? Does this request tie to a business objective? Do you have funding? What is the business need? Do you have business and IT Senior Leadership approval?

Talk to Your Customers – They Won’t Bite! You want to know how to mend a customer’s broken heart? TLC – Talking. Learning. Communicating. Time and time again, we see top ten lists come out stating one of the top challenges IT faces is communication with the business. With the single point of entry, a need has been identified by your customers. This is your opportunity to start the conversation and gather information on what the customer wants and needs. If what they need doesn’t align with what was requested, you as the IT expert have the knowledge to provide them with alternative solutions. In the end, your customers appreciate it. You and your team will have a clearer understanding of what’s needed to fulfill their requests.

Make sure you grab a copy of our latest whitepaper: Games We Play - Utility Services with Veris. Simply register and the whitepaper will be sent to you.

Copyright (c) Veris Associates, Inc. Unauthorized use is strictly prohibited. Comments contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by Veris Associates, Inc. Veris Associates, Inc. reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of Veris Associates, Inc. is final.

1 comment:

ITIL Job said...

Interesting analogies to the "Operation" game of my childhood. It helps connect some of the critical points (read: misses) I've seen in my years of consulting. Can't wait to read more about the Utility Services solution you're describing. Is it something I you came up with or is a solution you observed?