It’s becoming usual to install software remotely. Giving you the flexibility to work when you want, taking into account time zones,  a great benefit. You can install something from Europe on a server in the US without causing downtime during office hours. Thereby continue your daily tasks when a large install or database update is running. Wow, only benefits!

No, in specific scenarios it also brings a  bunch of disadvantages. What if a account is locked or you miss specific rights to install the software or download/ upgrade to the latest patch? Right,  I think your first thought right now is… Create a checklist, duhhh, pre requisites, requirements etc… but we stay human so a small mistake is made within a split second and computers stay computers… they keep suprising you!

One of those mistakes can cause a delay that, again think of time zones, might take up a whole day. Thereby the urgency of problems you encounter as vendor might be interpreted with a wrong severity when you notify them with an issue. This in contradiction with an onsite visit when you can directly contact the system administrator, DBA or project manager.

The last thing that can make a remote project a real pain is internet connection performance, slow VPNs or disconnecting remote desktop connections.

From a Westbury perspective, I’ve completed several remote implementations of our SMI Suite. Each one of them with a few hiccups as described above. However  it saved me a lot of travel time and jet lag.

Looking at the future I think we will continue remote implementations by learning from the bumps we have to take sometimes.

Finally it is not only our call… many customers want us to be onsite to share knowledge on the job and give them a great week when we blast them away with our SMI Suite.

Share your ideas of remote installation/ implementations, both pros and cons.

Richard

So 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?

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.

Now, 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

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