Archive for the ‘Implementations’ Category

Carlsberg don’t make customers… part one: the process guy

December 11th, 2009

weirdscience28Naturally we spend a lot of time thinking about our customers, past, present and future. And naturally all our customers are eternal delights to deal with and we never have any problems with them whatsoever. Not never.

But we do tend to find that certain implementations go more smoothly than others and we’ve done a little soulsearching about why that is. The conclusion we came to was that, for whatever reason, we – and our customers – walk away from the implementation with the most satisfaction when there is a certain make-up of people on the customer side. In fact, if we were to build our model customer from scratch (say, by putting bras on our heads, hacking into a secret government computer and feeding it pictures of customers we admired) then there would be, at the very least, four key individuals in key positions.

We thought it might be interesting to share with you each of these four archetypes – the Process Guy, the Tech Guy, the Budget Guy and the Department Head – and see if they ring any bells. We’ll start with the Process Guy and get to the others in the coming weeks.

*disclaimer: while I’m referring to all these people as “guy” and will use masculine pronouns, it should not be inferred that there is any gender bias to our depictions of the ideal customer. I’m just not prepared to write “he or she” every time, and – rightly or wrongly – the accepted workaround is to default to the masculine.

————————————————————————————————————————————————————–

The Process Guy

The Process Guy is usually our first point of contact at any given customer. He’s the one who has a problem to solve – either he’s not able to get any reporting out of his ITSM platform at all, or, if he is, it’s a laborious process that usually means he has to ask someone on the BI team to generate a report, and wait a significant amount of time to get the report back.
Process Guy has a fire in his belly! He’s interested in process improvement, he’s familiar with ITIL and he is desperate to drive forward solid initiatives that will make a real difference to the way the IT department is run.

Interestingly – and perhaps surprisingly – the Process Guy often knows a lot more about the tech side of things than you might give him credit for. Maybe he used to be a ServiceCenter admin, maybe his background is in IT and he’s come latterly to the process side of things. He may well understand the problems with the ServiceCenter / Service Manager database with regard to reporting. He probably understands what an ETL layer does, and have experience with BI tools. In the instances when he doesn’t have all the technological details himself, you can guarantee that he’s buddies with the Tech Guy (who we’ll come to in part two) and makes sure that between them they know everything there is to know.

The Process Guy is the visionary. He can see not only the problem at hand and the potential solutions to it, but also the bigger picture and the reasons to want to improve the performance of the IT department.

He wants to take control, not rely on a BI team to generate his reports when he knows that (with the right tool) he could do it himself. And while he’s technically savvy, the thing that drives him is the end-game: the ultimate benefit to the business of process improvement.

Next time: the Tech Guy

Tom

SaaS and ITSM and eccles cakes

November 6th, 2009

I hate to dispel the myth that writing for Westblog is nothing but being fed eccles cakes by scantily-clad Revs girls, but what with the economy and all, those days of hedonistic abandon are long gone, and, actually, writing these posts can sometimes feel like a bit of a chore.

Eccles-cakesSo happy is clam who discovers that someone else has written a really interesting piece on another blog, all about SaaS and ITSM, that can be brazenly hijacked and plagiarized for the purposes of Westblog… um… that provokes interesting thoughts about the things it mentions.

SaaS 3.0 and ITSM, Match Made in Heaven!!, is the piece, found over on Service Sphere’s blog. Aside from the Guinness World Record™ for longest blog entry in history (seriously, I’ve read Salman Rushdie novels in less time), the piece is notable for the fact that it takes a long hard look at SaaS – the topic on everyone’s lips, seemingly – but only from the ITSM standpoint, which itself raises some interesting questions. After all, is the fact that we sat up and took notice of this piece an indication that other ongoing and general discussions about SaaS seem a little disconnected from ITSM? Is that because yes, of course it’s easy to see why it makes sense to have your word processing app or whatever in the cloud, but ITSM software is not the same beast as MS Word?

After all, you can send your mother a CD (or is DVD these days?) of the Office suite and reasonably expect her to be able to install it herself, with maybe only one or two panicked phonecalls about having read the entire user agreement but not quite understood all the technical terms. The same is patently not true for Service Manager 7. My preconception – and in this I may be completely wrong (it has been known, just ask my wife) – is that any software that requires significant deployment or installation assistance, will require it no matter what the delivery method of the software. And if that is the case, is that reliance on specific personalization at odds with what we think of as the SaaS model?

Well, I’m not the person to ask, because I don’t know enough to be able to present a cogent argument. If only there was some sort of link to someone else’s blog covering this very topic…

Tom

PS Does anyone else reallllllly want an eccles cake now, or is it just me?

Coming out of recession…Now what?

September 28th, 2009

bullAccording to the economical gurus, the world is coming out of the recession. After a year of cutting costs, doing more with less and outsourcing IT services, what should be the best strategy for IT executives moving forward?

Obviously, the reckless pattern of costs savings has lead to huge gaps in IT processes. Especially the maintenance of IT applications has been hit hard during the recession. In the last 9-12 months almost all companies have reduced the contracts with consultants dramatically, IT services have been outsourced and support and maintenance contracts not renewed. On top of that, internal IT resources have been cut back or reorganizations have taken people away from maintenance projects. But also new, innovative IT projects have been postponed. I’m pretty sure everyone can think of one project this year that was already approved but never executed or was killed during implementation.

However, since our gurus allows us to see some light at the end of the tunnel (which could easily be a train coming towards you from the other site of the tunnel!), what should be the recommendations for IT executives?

Allow me to come with some suggestions:

  1. Fill out the gaps of your IT processes by implementing new processes, new application to support the processes and by hiring resources in critical spots
  2. Gain competitive advantage by updating your website with new features such as: news feeds, newsletters, event calendars, case studies, photo galleries, customer support features, product catalogs, blogs, social networking capabilities, and SEO improvements.
  3. Invest in the future by hiring young, talented people and by training the employees that kept your business running for the last 12 months.

Just some suggestions. Let me know your ideas.

Floris

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