Had a long conversation last week with two ladies at a large company; both carry the title of Portfolio Manager. Basically, they are IT-background folks who work for “the business” and represent the relationship between their respective business units and IT.

Man, did I get an earful!

A solid hour of (polite and professional) venting about IT’s lack of visibility for the business. Costs, benefits, activities, projects, efforts, labor are perceived as a great black hole. The business receives budget reports (and chargebacks), but has no idea what goes into them, or any way to effectively find out.

The result, of course, is frustration - and seeking out alternatives. In this case, the business units have been buying their own IT, “under the radar” for years.

Now, when a companywide ITAM program is on the table, all of these business-owned applications are a great big black hole of their own - IT doesn’t know what they are, where they are, what their value is, what the risks associated may be, etc.

Frustration all around. How to move forward?

Same as always - one step at at time. First we focus on the wins that are big and obvious, like hardware and software that’s owned by IT. Hopefully we’ll be able to show more visibility into real costs from those efforts, so that the business begins to trust IT (and vice versa) just a little bit. Then we can have a dialog about those busienss-owned apps, and at least assess the size of the question and the nature of the risks involved, and mutually make a decision about how to handle them.

Incrementalism - good word - that’s how we got there, and that’s the way out.

—–

Happy holiday Friday. Thanks for coming back to read some more!

Although we appreciate Fridays in general here at Real World ITIL, I don’t know anyone who doesn’t look forward to the Friday of Memorial Day weekend, in particular. Somehow it feels like we’re making “progress” if we’ve made it this far through the year, doesn’t it?

Or is it really more like we feel that the “year is nearly half-over and our ITIL change leadership efforts arent going as fast as we’d like them to?”

Please join in welcoming Todd M. to our blog, who is checking out ITIL for the first time. Feel free to jump in with questions or comments, Todd. We’re talking about the practical implications of doing ITIL process implementations in the real world of corporate America - not just the theory of it. However, if you’d like to know more about ITIL definitions and theory, check out these websites:

The official website: http://www.ogc.gov.uk/index.asp?id=2261, or
The IT Service Management Forum (US): http://www.itsmf.com/

A special hello to Betsy L., too! Thanks for reading along with us.

This has been one of those weeks when Real World ITIL was more ‘real’ than usual, if you know what I mean.

Why so?

If you’ve been reading along for a while, you know that we’ve doing a lot of requirements gathering and process design work over the past few weeks in order to find a way to implement the first few bits of ITIL Configuration Management in this large IT shop. This project is the first step in what might become a multi-year effort to implement all 10 ITIL core processes.

(If you’re new to the blog, you might want to read my last few entries for some background info on our current project before reading further.)

Following the design effort, early this week we previewed a draft of a new workflow for IT Asset Management along with a supporting organizational design for some influential managers. Our intent in doing the preview was to get an early sense of the fitness of the design and also the organization’s tolerance for change.

We also wanted to help the managers continue to adopt the kind of ‘horizontal’ thinking that ITIL requires in contrast to the ’silo-based’ thinking they have held for many years previously. Furthermore, for planning purposes, we needed to know about how long it would take to gain executive buy-in to continue the implementation.

While we can’t reveal any details about the discussion, it is safe to say that the practical implications of restructuring the organization in order to implement process improvements were perceived as daunting. Daunting despite the fact that this project is really only a tiny step toward what an all-out ITIL transformation would require of the company.

Suffice to say that our team had to stop what we were doing to spend the rest of the week helping management understand the details of what the organizational change meant, why it had to be done that way, and what the specific impact of the change would be on their real world.

Some interesting questions arose out of this exercise:

• Who ‘owns’ ITIL in an organization? (think about this one carefully - it’s not an easy question, and the answer is not necessarily the obvious one: e.g., “the CIO owns it”.)
• Who should ‘own’ each of the individual processes?
• How will the various owners interact with each other? (think about this one, too - it’s a subtle issue about the spaces between the ITIL steps)
• Who will fix ‘broken’ process interfaces?
• How will IT work if only some of our processes have been transformed?
• And just what will happen if we only get partway through our workflow transformation and management withdraws its support?
• How are we going to sell these ideas to the senior management team, who all have other pressing things to worry about?

So, picture yourself standing in front of some VIPs, having just introduced some ideas that, small as the changes may be in relative terms, have nonetheless rocked the prevailing world. Now, because the VIPs are beginning to understand, they start asking you some of these questions.

How would you respond? These questions can’t be danced-around or brushed off.

My point is that, even if you are only trying to take one small, earnest step in the right direction toward process improvement using ITIL, the questions get very interesting, very quickly. Even small steps in an ITIL implementation can require major changes. We have to think not only about the core processes but also the spaces between and ‘around’ the processes.

So, in the early stages of implementation, this is what Real World ITIL really is. We who implement ITIL live questions like these on a daily basis. In the case of the present project, I feel confident that we’ll have good answers & do just fine on the implementation.

So, if you’re just starting out with ITIL as Todd is, realize that it’s more than just studying the theory and passing your Foundation certification exam. You have to have good responses to questions such as these, which responses represent ideas and plans that are rooted in business requirements, which are sensitive to the company’s culture, and that are also limited enough in scope that you can actually achieve them.

Do you agree? Have you had the same experience? Let’s hear from you!

We’ll reflect on some of the above questions in future blog entries. In the meantime, put your feet up & relax, will ya? It’s FRIDAY after all!

Have a good weekend, everyone!
Scott

—–

Since you’re in you’re in ITAM, and the knee-jerk reaction is to say “hey - let’s put a stop to that right now - we can’t have business people out there making their own decisions about IT!”

I think this gets to the core issue that internal IT departments struggle with: namely, the business does have a choice. And if IT doesn’t execute well - in terms of delivering services that the business wants, in a timely and cost-effective way, then the business will look elsewhere.

Outsourcing is one way that happens. And of course there’s a whole spectrum of “outsourcing” ranging from a temp contractor for a few days, to the huge “today you have a new badge” takeovers.

But another way is “rogue IT”. The business can say “hey, we have goals to meet, we can’t/don’t trust IT to help us get there, so we’re going on our own.” The result is servers hidden under desks, or off-site/hosted apps.

So what’s it have to do with ITAM?

Lots:

• the obvious question is “how do we track assets that we don’t know about, and that the customer wants to hide from us?”
• and the related political battles that will happen when you try to bring those rogue app’s/infrastructure into the IT fold. Maybe you could chart a compromise course - something like “we just want to track it, not take it over” so both IT and the business get to plan for obsolescence / upgrade cycles / disaster recovery. Obviously, IT has some bridge-building to do here.
• but you still have to address the root cause - which is that the business doesn’t believe that IT is the “best” supplier available for it’s needs.

So we’re right back at that core issue - people in IT tend to not think like business people. And the (false) assumption is that the only “competition” to internal IT is traditional outsourcing.

But in fact, IT does have a myriad of competitors - each of whom has a dedicated sales and marketing department, and spends great effort in understanding what the customer wants and needs, and to delivering on those wants and needs cost-effectively.

So look around your IT department’s org chart - where are the sales and marketing people? Trust me, your competitors have plenty of them.

—–

Welcome back to Real World ITIL!

Thanks to those readers who have left postings, including Don, Mari, and “IT Consultant” (is that you, Joe?). Let’s keep the discussion going!

Special thanks also to “randyy” for linking to this blog - it’s a great way to form a larger ITIL community. Randy: I tried to respond to your recent blog entry on using MOF to map organizations to processes, but there was no input link.

Also, to follow-up on the change leadership thread from earlier in this blog, we read a great article this week on how to do ‘Change Through Persuasion’. It’s in the February 2005 issue of Harvard Business Review. I recommend that you read it if you can find a copy.

With these messages from our sponsors done, it’s now time to get back to our story…

It’s been a few days since I’ve had time to update this blog because we’ve been busy on this ITIL implementation with interviewing stakeholders to gather requirements. This is pretty time-consuming stuff, but essential. After all, you can’t really design an effective workflow (or its supporting technology platform) unless you know what both the business and end-users need in an ITIL-based system.

Is this right thinking or not? Let’s hear your opinion!

In the meantime, here’s what I think:

One might argue that, since ITIL is essentially an industry standard, we should make the organization do ITIL processes rather than customize ITIL to the organization based on their requirements. This approach might seem to make sense at first glance.

For instance, if you have a bunch of people gathered into functional “silos” who are all doing redundant processes, why keep any of their processes at all? Why not just completely trash what they’re doing and make ‘em “do ITIL” instead?

Well, the reason is that ITIL by itself is not a detailed-enough model to meet any particular business need. See, each of the functional siloes at this place (that is to say, functional teams in this particular large IT organization) has a reason for its existence, and that reason fulfills a specific business need. That’s why we need to gather requirements from each silo-ed group ? to ensure that our ITIL solution meets this client’s specific business needs.

What did we find? First, a little more background info on this project:

We’re starting our ITIL implementation by consolidating multiple IT asset tracking databases into a single database. Each of the 12 functional siloes at this site has its own set of asset databases and an independent workflow. We began by mapping-out their current state asset management processes and comparing them to ITIL.

What we found was that each of the 12 departmental flows could be separated into two linked sets: (1) a business-specific set of process steps, which linked to (2) a ‘core’ set of process steps. The core steps were nearly identical in each of the 12 siloes.

What do you suppose our next step should be? Let’s hear from you!

Have a great week, everyone!

Scott

—–

In my previous article I suggested that Service Level Management (SLM) was critical to service management in general because SLM provides the measurements necessary to facilitate continuous improvement. I haven’t received opposing feedback so I’ll assume most of you agree with this assertion. Then again maybe no one’s reading the blog, or you simply said “No s*@! Sherlock.” At any rate, I also promised some advice on how to get started with SLM in my last posting.

Based on the assertion that SLM is critical to establishing a measurement for continuous improvement, I would start by making the ability to measure service your primary focus. In other words, how can you quantify the quality of IT service that your organization provides?

To start you must determine what you consider to be services. This will constitute your service catalog, and can be a difficult and time consuming process. That said, there’s no reason you can’t start small.

Services should always be defined in your customers’ terms so that they understand what you?re measuring. When embarking on a SLM initiative try to determine the most critical services first. What IT applications or systems are most critical to you corporation? What systems will have the most detrimental impact if they are not available? Identify these and start from there. Once you’ve identified some critical systems/services (from the customers’ perspective of course) it’s time to set some guidelines for measuring those services. Essentially there are two types of measurements typical of SLM. These are response time and availability. Response time deals with the time taken to react to and resolve interruptions in service, and availability involves measuring the percentage of time a service is available to customers.

If you’ve never set such measurements for responding to or keeping critical systems available, then I would suggest setting easily achievable targets initially. Of course your customer should have a say in this, but it’s best to begin slowly and increase the aggressiveness over time - continuous improvement remember. Once some targets have been set for some critical services, you must create the process for measuring both the response time and availability. This means that each time a service interruption to one of the critical systems (services) you’ve identified occurs, you must be able to record; how quickly someone began working on the incident and how long it took to resolve from the time it was recorded. Most help desk software has these capabilities built in. Next you should be able to record the start date and time of any interruption of service and the date and time service was restored. These date/time combinations will provide the ability to track availability.

Now admittedly I am simplifying the SLM process quite a bit here, but we’re just getting started. I’ve ignored the term Service Level Agreement (SLA) - the agreement with your customer on service definitions and measurement. And I’ve ignored the internal (Operating Level Agreements) and external agreements (Underpinning Contracts) necessary to facilitate the SLAs - more on those later. Following this simple approach however will give you a good basis for beginning to measure the service you provide and lead you down the path of continuous improvement.

—–

Did your internal IT audit identify key issues with your Enterprise IT Change Managment program? I’ve found that following a systematic approach helps identify the key deficiencies, establish minimum requirements and allow an effective implementation effort. One thing to remember throughout your development program is to make sure that you define the crucial processes first.

Some basic guidelines to follow include:

• Identify basic requirements: Remember that the core requirements of Sarbanes-Oxley require that the associated business processes, policies and procedures are defined, documented and followed. This really is the hard part.
• Tackle the most critical business issues first: These are the ones that the auditors are going to focus on. You’ll have time to fine tune the system at a later date.

• Use established standards: ITIL provides a good starting point for identifying the critical business processes. CobiT provides a solid method for measuring your progress.
• Identify minimum performance levels: You won’t be able to get everything done on the initial effort. Establish what is most critical and focus on those efforts first.
• Automate and integrate: Change management can be a complex and time consuming process if not properly defined and implemented. The effective implementation of a technology tool can help automate your change processes. Integration to your ITAM and service management systems is also essential.
• Establish report requirements: These fall into three categories - 1) Day-to-day operational reports; 2) Change management program reports; and 3) Executive level management reports.
• Measure progress: You need to take the time to evaluate how effective your enterprise IT change management program is. This process will allow you to further strengthen the program.

I’ve helped companies use these processes to go from no Enterprise IT Change Management program (evidenced by numerous write-ups during their internal audit) to an effective program in less than 6 months. In fact, a recent audits at each company couldn’t find any issues with the change management program - they use CobiT as their measurement tool. At one organization we were able to resolve 4 of their 16 audit findings.

Over the next few weeks, I’ll expand on each of these areas and the standard processes used during the development of several successful Enterprise IT Change Management Programs within Fortune 1000 companies.

—–

Hi Guys-

I am posting a quickie, interrupting my previous discussion thread, which I will get back to.

The thread is on Proving the Value of IT. Please forgive me if I state the obvious. I was talking to a CIO client of mine with 400 IT staff, and he was emphasizing what a large and complex business they were, and how that made things difficult to change.

I suggested another perspective. What if you viewed yourself as a small and very agile consulting and IT outsourcing firm, serving 4-5 different complex customers? One in a finance and back office vertical, one in a marketing & sales vertical, one in a customer service vertical, one in a manufacturing vertical, and even one (a small one) in an IT services and consulting vertical. After all, a 400 person firm should be pretty agile.

He visibly relaxed as he began to think of his part of the business differently. His customers had a different set of problems, and he had his own set of problems in HIS business. I suggested that he only offers two services to his 5 different customers–technology consulting, and outsourcing support. So, treat them as two separate business “lines,” with different strategic goals, resources, and performance metrics.

I asked how his consulting business was doing against its goals. He said, “its hard to answer without spending some time to think differently.” I asked which part of his IT business was more strategic, and which part was more commodity. He said, “most of the “outsourcing” business is a commodity, and most of the “consulting” is strategic. So how much of the organization’s focus is on commodity work, and how much on strategic? You can see where the line of reasoning is going…

How about you? Have you committed a senior consulting like resource with deep CRM experience in your industry to act as an advisor and liaison to the sales organization? To be the trusted advisor to the VP of Sales? Ditto for the other areas. How about for IT? If you provided significant, quantifiable strategic value to your customers, and were only in the 50th percentile of efficiency on the commodity business, how would IT be viewed? Probably pretty favorably.

Food for thought–let’s keep it simple!

—–

During my last couple of consulting engagements, I have noticed more and more companies are using virtual servers in their development environments. If you aren’t familiar with virtual servers, it is at a basic level, a server that shares computer resources with multiple virtual servers. Each virtual machine is isolated from the core operating system, and from other applications and virtual machines that might be running on the system. Therefore, if a buggy application were to crash, it might bring down the virtual machine, but it will not have any effect on the machine’s main operating system. I can see this as beneficial in lowering hardware costs and allowing you to test multiple environments from one server. But do the benefits really outweigh the cons of this type of environment?

My experience with a virtual development environment has been a poor experience with unacceptable response times. This could easily be attributed to too many virtual servers on the host server or how it was configured. However, one main reason we go to virtual environments is to consolidate servers. Those in favor of a virtual environment always argue that a virtual environment reduces hardware costs. Yes, you have fewer servers that you buy, but your host server must be beefy enough to run all virtual machines operating systems and processes as well as the host server’s. Software costs also increase in a virtual environment. Consider the scenario, where you have two virtual servers on one host server. You need to purchase an OS license for the host server as well as the two virtual servers and the software that allows you setup a virtual environment which is more than just buying the operating system on three dedicated servers. Finally, using the scenario above where you have two virtual servers on a host server, if your host server crashes, all three servers are unavailable.

I may have a negative attitude towards virtual environments, due to my own experiences, so please share your experiences.

—–

Sitting in the hotspot at DFW gate B9, contemplating the ever-present challenge in all ITAM projects: “where’s the ROI?”

An offhand comment by a client last week was one of those that you blow on past, then the significance only dawns on you later. For me, it was in the shower this morning - guess I should place a higher priority on personal hygiene!

Anyway, here’s the situation: this client is a large, reasonably mature IT shop - in fact there are posters all over the offices recognising the fact that the big IT magazines have recognized them for excellence for several years running.

So their “basic” ITAM is already in place.

But there are always holes -

and in this case the evidence came out because one of their key software vendors - one of the top 5 that you’d recognize - is planning to release a new version of their ITAM product set. The client assumed they were coevered by maintenance - in fact, last year the company negotiated an enterprise-wide maintenance agreement for all the products, that limited price increases to 4% annually. Pretty good deal.

Except that this particular application got left out… apparently the contract negotiation team either forgot, or didn’t know the app was in the environment. Impact? Still TBD but the initial quote from the vendor was a 67% increase the in maintenance cost for this year. Funny… right before a big upgrade, hmm?

So there’s some real hard dollar ROI for better integrating your ITAM from the departmental silo’s where it lives today, into a single enterprise-wide view. What’s the dollar value of the price hike?

If they had, for example, a single company wide application inventory, before doing that negotiation, this would not have happened. The negotiation team would have known to include this app as well.

This client may still be able to avoid / negotiate around that price hike - but to me it begs the question, “what else don’t you know?” And that’s where a lot of your ROI will be hiding.

Time to board… see you out there.

Scott

—–

Next week both the Public Company Accounting Oversight Board and the SEC will release statements to address complaints from businesses that new rules are too costly. This stems from the fact that current obligations of both auditors and corporate staff result in duplicate work by both groups. Current estimates show that the costs for a SOX review are averaging more than 4 million per company. This is significantly more than the SEC originally estimated. In response to this overture, the SEC will release new guidance to encourage auditors to exercise better judgment and increase their reliance on the work of corporate employees as the audit firms review company systems to prevent fraud. Additionally, the Public Company Accounting Oversight Board will issue policy and technical procedures to appease businesses and reduce auditing costs.

Depending on the degree of compromise that the SEC deems acceptable, accuracy in reporting, the underlying value of SOX, may be negated.

The reality of the situation is that auditors were required to review controls even before the 2002 ruling. The controls have been glossed over by all parties due to unwillingness and the costs of validating them, thus leaving shareholders and companies’ reputations to bear the burden of front page tragedy.

The bottom line is that whether or not the SEC enforces controls in reporting, the problem and liability still exist. Businesses that want to lower auditing costs should address the real issue at hand. They should invest in themselves and establish an enterprise framework that provides the controls needed to accurately report through measurable processes. It is only after a framework is established that the issue of accurate reporting vs. costs can be resolved.

—–