Posts Tagged ‘ITSM’

Luck or wisdom?

August 20th, 2009

luckImplementing a service management solution within a customer environment is an easy task.  Install the software, tell the customer to use it according to ITIL, import some employees, CI’s and Services and Bob’s your uncle. Nothing to it.

Alright, alright; it’s slightly more complex than that. You’ll have to try and gain insight into the processes that are in place, you’ll have to discuss the requirements and wishes of the customer and flawlessly translate them to the set up of the tool, you’ll have to train the user community and you’ll have to communicate with all of the stakeholders in the organization throughout the implementation process.

So, assuming you went through all these steps and made no major mistakes along the way; is success guaranteed? Unfortunately, no. Some of these projects will end in partial success at best and will live uneventful lives.

What then is the key to success? Tough question. It’s really a combination of knowledge, experience, patience, determination and, for a part at least, sheer luck. Let me focus on the latter, because the first four are obvious. To what extent does luck play a role?

Luck, or positive circumstances beyond our control, can make the difference between a project ending in success and a project just ending. Let me illustrate this with an example from a recent implementation I did at one of the biggest insurance companies in The Netherlands.

Due to circumstances, I was lucky enough to be involved in an implementation project for the Insurer for the fourth time in 13 years (or so). The previous three projects had all ended with a mild success; nothing fancy, just okay. This last project was somewhat different than the previous three, because this time it wasn’t a merger or an upgrade but a whole new implementation of Service Desk 4.5, SSP, Report Manager, Change Calendar and Service Desk Monitor. Why? Because 4 years ago the Insurer outsourced their IT department and switched over to ServiceCenter.

Roulette-Wheel_HRNow, the outsourcing contract had been terminated and a renewed Service Desk implementation was required. Enter Westbury. The luck factor starts here. Literally no-one within the Insurer had been satisfied with ServiceCenter and its functionality (due to the outsourcer’s implementation mainly, not due to the tool itself). The way this works psychologically is that you start to remember the good old days, when streets were paved with gold and the sky was all pink and fluffy. Their good old days were the Service Desk days. And now it was back. Praise Jesus.

This feeling, shared by most in the project group(s), meant that there was an enormous sense of positivity with everyone and a real drive to make the project a success. This really started off a chain reaction. Because everyone was positive, they were very flexible in accepting the limitations of the project and the tools, and because they were flexible we were able to move forward within the projected time frame and within the projected budget. This in turn lead to more positivity.

Added to that was a project manager who played a very active role in the project and really fought like a lion to get everyone on the same page and protect the scope of the project. Also lucky because you can never choose your project manager.

The result of all this: A project that ended on time within budget and with a happy customer.  And with an additional project and the purchase of 50 additional Service Desk users. And with this blog entry.

Is there a way to influence this luck factor? Yes, maybe. By making sure the customer is aware of this factor and by driving home the notion that enthusiasm for the tool implementation as well as a very active and dedicated Project Manager are just as important as the other factors that determine the outcome of a project. Still, the luck factor cannot be overlooked. Hopefully you are lucky enough to find it on your path.

Jack

The hidden costs of BI

August 19th, 2009

The Aberdeen GroupIn a recent report (registration required) the Aberdeen Group described the success rates of enterprise companies (which it groups into Best-In-Class, Average or Laggard) in Business Intelligence projects.  Some of the result are very interesting to share.

For example, the report identified the four top hidden costs of Business Intelligence as:

  1. Year-after-year budget increases: The typical best-in-class company sees a drop in year-after-year BI budgetary costs. Average and laggard companies, however, can witness increases in BI expenses that range from 2 percent to 9 percent.
  2. Cost per user: Best-in-class companies lower per-user costs by 4.3 percent whereas average performers and laggards often see increases ranging from 1 percent to 7 percent.
  3. Time to complete projects: Best-in-class achievers complete BI projects, on average, within 14 days. Average performers take nearly three times as long (approximately 39 days) to complete a project, and the typical laggard company takes more than 12 times as long (177 days).
  4. Modifications to BI software: Altering a BI program takes less than a day for best-in-class companies; three days for average performers; and up to eight days for laggard organizations.

Or as author David Hatch put it:

“The overall cost of ownership is not about the costs of purchasing the software,” Hatch says. “The real cost factors are the hidden or the soft ones that have to do with indirect and ongoing factors.” Hatch contends that a justifiable fear of such factors hinders adoption. “People are finding [that] the resources the company needs to acquire to properly implement, deploy, support, and maintain a BI solution are far greater than the solution providers lead [users] to believe or that [users] assume on their own.”

Interesting, because that is what Westbury has seen over the last years in dealing with BI projects for HP Service Management. But a report of the Aberdeen Group isn’t complete without some recommendations. On what areas should companies focus in order to improve the success rate of their BI projects?

Aberdeen suggests that investments in the following areas will maximize results from a BI initiative:

  • Data integration and cleansing: “Companies are finding it difficult to bring data together from multiple, disparate sources,” Hatch says. Investing in tools for data management can be of help in this regard. Best-in-class companies are twice as likely as their counterparts are to institute data integration and cleansing capabilities.

Westbury recommends: make sure the back end of your BI environment can be used by non-technical people

  • End-user requirements: “You really have to stop and think about why…so many companies have deployed tools that so many aren’t able to use,” Hatch says. Companies must understand that end-users — especially nontechnical, non-data-guru types — may need different approaches. Hatch advises companies to focus on end-user needs before deploying a solution.

Westbury recommends: make sure you talk the same language as your end-users

  • Training: Top performers are 37 percent more likely to invest in extensive user training on BI solutions and 40 percent are more likely to have formed formal user committees to encourage adoption. Additionally, best-in-class companies are twice as likely as laggards and average performers are to sign up for vendor-provided services.

Westbury recommends: the more accessible your BI solution is for the end-users, the better your processes should be around training

  • Operational BI: Successful users of BI use the technology on an everyday basis rather than merely getting a summarized spreadsheet version of performance and high-level trends. Hatch says that operational BI seems to be gaining traction as companies look to make comparisons over shorter time spans rather than just examine large-scale trends.

Westbury recommends: integrate your BI solution with the supported applications, so it is readily accessible for your end-users

Great to see our own own experiences in working with the HP Service Management software backed up with a solid research like this one from The Aberdeen Group.

Floris

Diabetes and ITSM: a common case for daily monitoring

July 23rd, 2009

Monitoring is embedded in the daily life of a type 1 diabetes patient. Checking the blood sugar levels with a test strip and meter helps the patient determine whether his blood sugar levels are just right, too low or too high. It is a routine that is repeated before every meal and snack. Any time a diabetic feels “strange”, light headed or hyper, or has a sudden mood swing, the blood sugar levels need to be checked as well.

The purpose of measuring blood sugar levels is twofold. First and foremost, it is meant to prevent a situation in which high or low blood glucose levels may cause severe symptoms that need to be treated right away. Depending on the glucose reading, a patient must take corrective measures to get the blood glucose levels up to par. Second, checking blood glucose will help a patient place fluctuating blood glucose levels in their correct context. High or low glucose levels may not appear from out-of-the-blue. Analyzing the context of a blood glucose measurement will help a patient learn how aspects such as insulin injections, food, activity levels and stress impact their blood sugar levels.

So where’s the link to IT Service Management? Monitoring a service desk serves two purposes that are indeed quite similar to the reasons for measuring blood sugar levels.  First, it enables service desk managers to take corrective measures in order to prevent undesirable situations from occurring. Second, it helps managers understand the context of the metrics that are retrieved.

Consider, for example, a scenario in which your daily monitor indicates that a business-critical workgroup is assigned an unusually high number of calls. This may have dire consequences; the number of calls past deadline may increase, SLAs may not be met and customer satisfaction may decrease. Detecting this trend, the service desk manager can now ensure that calls are assigned to other workgroups or request additional staffing to help deal with the workgroup’s unusual workload.

Moreover, as Susan Sanderson  correctly observes in her book “Introduction to Help Desk Concepts and Skills”, metrics must be evaluated in context since variation from standard levels can be the result of a wide range of factors. Analyzing the reasons behind the increasing pressure on the aforementioned workgroup may lead the service desk manager to conclude that the higher number of assigned calls is the direct consequence of a Change implemented in the organization’s network infrastructure the previous day. Rather than requesting additional staffing as a permanent measure, more staff may only be required for resolving the issues resulting from the Change.

How will monitoring your service desk help you in your daily endeavors? What daily metrics do you want to obtain? Consider these questions and share your ideas with us by posting a comment.

Get started with monitoring your service desk using Westbury’s  Service Desk Monitor. Westbury’s Service Desk Monitor is a lightweight application for retrieving daily metrics from your service desk environment and distributing these metrics to a wide range of audiences via RSS. Interested? Leave an ‘I am interested’ comment and I’ll contact you.

The “red-headed step child” of a HP Service Manager implementation

July 2nd, 2009

Chances are that if your company is using HP Service Desk or HP ServiceCenter, that you are contemplating a move to HP Service Manager. Such an undertaking will undoubtedly be coupled with a review of existing IT Service Management processes and the way in which HP Service Manager will support these processes. Having learned from experience, most companies recognize that there is no need to reinvent the wheel and are therefore minimizing customization and sticking to the out of the box configuration as much as possible.  However, and this is a surprising industry trend, most companies are still paying little to no attention to the reporting requirements from HP Service Manager. Without a proper reporting solution and strategy in place, your HP Service Manager implementation cannot succeed as you will have no way to properly measure and communicate IT’s performance.

Common themes that accompany the (planning of the) implementation of HP Service Manager include the sensible improvement goals around:

  • Business and IT alignment
  • Quality of IT services
  • Transparency of IT services to IT customers

Given the above themes it is therefore surprising to see that getting the right information out of your HP Service Manager implementation is often an afterthought. Or as one seasoned ITSM consultant put it, ITSM reporting is often dealt with as the ‘red-headed step child’ of any ITSM implementation. “We’ll deal with that when we get to it” however by the time you ‘get to it’ you’ve got your hands too full to properly address the issue.

At Westbury we are constantly running into customer scenarios where all the focus is aimed at getting HP Service Manager up and running and yet reporting often seems to be an afterthought. Interestingly enough, that same ‘red headed step child’ suddenly becomes of utmost importance the moment HP Service Manager’s live date approaches . The reasons are obvious:

  • At a minimum IT wants to provide at least the same reports as existed before the move to Service Manager
  • Additionally IT managers & supervisors need insight to better oversee, drive and improve the performance of the various support teams and services they provide
  • Going forward the IT department would like to prove its value by objectively demonstrating improvement in the delivery of IT services
  • Customers  of IT will demand insight into the delivery of IT services and will require increasingly more in-depth reporting from IT

We in roles of ITSM are being asked to do more with less and to improve the delivery of IT services to our customers. This means we have to be smarter as to how we go about this. Let’s all agree that it is not about what we put into the ITSM processes and tools, rather it is about what we can get out of it.

Be smart, look at the overall picture.

David