Monday, 24 September 2012

Taming the Help Desk

Taming the Help Desk

I  think possibly this is the best article yet. First of I'm astounded such a small team can manage and support so many staff and students! This article first addresses a lot of issues that affect geeks in a tech role to a management role. The language used is informal and very friendly and gets the point across,  From addressing your Geek appearance to transitioning to managing staff some great ideas are expressed.

A key point discussed I can relate to was knowing when to speak and when to shut up as typically there is the overly quite geek or obnoxious geek who doesn't know when to shut up. I have meet a few of these(obnoxious geeks) in my time and they drive me nuts yet still I am a little jealous at there abilities to express themselves even if most of what they are say is crap! as I tend to be the overly quiet geek and miss my opportunity, there's room for improvement.

A lot of decision in the article goes on to describes setting up a help desk, hiring a staff then managing and keeping up moral in the team. Lots of useful ideas advice to come in handy and that hopefully I can apply in the future, some where, some time, at some service desk.

You Want us to Support WHAT?!? Negotiation, Delivery, and Cultivation: The Gateway to Excellent Service Deployment

You Want us to Support WHAT?!? Negotiation, Delivery, and Cultivation: The Gateway to Excellent ServiceDeployment


Right-o first off, Kerberos password, does that actually exist? Doesn't Active directory dish that out a kerberous token when you successfully authenticate when logging into a domain connected pc?

Doesn't matter.

Yes the help desk is important and does really need to be involved in  changes, development and when something goes wrong and they need to be let in on this early. I don't know how many times I have seen a change implemented,  the service desk hasn't been updated or notified and calls are flooding in, your trying work figure out a work around and ya cant come up with anything, so you wander off an have a yarn with a level 3 administrator only to find they have made a change or something has broken but they haven't let you know or you get a blank look as if to say I didn't think it would affect that.

 A lot of time and effort can be saved by communicating with the service desk but that only works if the higher levels in the team also communicate with the service desk as well. The service desk I think also has a really good idea of how users work with the services supplied and can give some really good feed back on discussions involving future services or changes. Being able to ask with a users frustrations in mind how something may be affected.

Developing a Service Catalog for Higher Education Information Technology Services

Developing a Service Catalog for Higher Education Information Technology Services



This case study gives a great incite to how a service catalogue can be implemented for a business catering for a large amount of people. It is almost like a system by step guide. 

I found it interesting where it is discussed around making the content searchable.  As my work places service catalogue typeish website suffers from one the  issues they out line. It categorises services by showing questions a customer might ask, which is very frustrating because you can never find the question you want to ask. The questions are also to long and difficult to skim though the text just becomes too much.  It is really cleaver how they avoided this in the article by refining the categories to board basic request EG Do something? Need Something? Fix a problem? Get information? Buy Something? Etc…..

It would be nice to implement something along these lines and see the improvements or changes in the dynamics of how service requests and incidents come through to a service desk. 

The article outline nicely how the implementation of a service catalogue can change the service provided to a business and the way it can add value to both the customer\user and service provider.

Monday, 17 September 2012

Conger, S., Winniford, M., & Erickson-Harris, L. (2008). Service management in operations. Proceedings of the Fourteenth Americas Conference on Information Systems

Service management in operations.

This was a long read. The article discusses a survey on the implementation of various forms of ITSM in a rang of US firms with IT departments. Generally firms with larger amounts of employes were more likely to use some form of ITSM.  Which is not so surprising trying to organize and coordinate large amounts of people and technology there needs to be something to keep the anarchy contained. the smaller business were less likely to use ITSM, as staff were more likely to to be performing multiple roles.

A statistic I found interesting was that more firms had implemented Change management than Incident management, it wasn't by much. Incident Management was one of the higher adopted process even higher than the service desk, whose logging these incidents?

The conclusion identifies that there is some conceptual confusion on exactly what a IT service is which I agree with, most people with out any IT knowledge thinks there's computers with programs on and they can send email, explain whats IT service is and there eyes glaze over.

I guess the implications for the of IT operations are less efficiency and more downtime  with no implementation of ITSM, changes happen, changes cause effects and incidents are born and help desk people stay in their jobs fighting fires.

Tuesday, 4 September 2012

Mastering IT Change Management Step Two: Moving from Ignorant Anarchy to Informed Anarchy

Mastering IT Change Management Step Two:Moving from Ignorant Anarchy to Informed Anarchy

Its been a while, right interesting article -  a description how a IT support Organisations beginning steps into implementing a change management process.

I like the way the author likens the first steps of setting something like this up to Ignorant Anarchy,

I can see the Authors descriptions very clearly and liken them to a few things I have seen first hand.

With systems having changes implemented and no one being informed and going through a troubleshooting process only to find some one form down the back has changed a setting and not told any one and is the cause of the incident.

Then this morphs into everyone being informed some people caring when it doesn't even affect them tying up the help desk with unneeded queries, but on the other hand in the past they have been affected by changes that weren't meant to affect them but did, it puts you in a  interesting position when you have to reassure them it wont affect them.

I cant imagine working in a large business with 60-75 changes going on in a month it must be anarchy as the authors describes when there is none or trying to implement change management process.

Then bliss once reaching step four "Mastering IT Change management".