This is a follow-up post to improving your chances of success with an ITSM project.
One thing I want to clarify is about the topic I’m expanding upon: improving the chances of success – so that doesn’t mean I’m going to try to address how you should go about an ITSM project (which will depend on your current position, skills, budget, and organisation).
I’m interested in improving the chances of success, like you might say ‘improving the chances of cycling home safely in February’ might be ‘have good lights, don’t drink alcohol beforehand, wear reflective clothing, avoid busy and narrow roads, or roads with vehicles travelling at high speeds’. None of these things guarantee the outcome I want cycling home, but they do improve my margin of success.
On Monday I blogged about objectives, and how important they are. It occurs to me that another use for a good set of objectives is at the end of the project, as a way to judge if you’ve achieved the things you needed to at some point in the future.
Today I’m going to blog about what I consider to be akin to a mortal sin – complexity.
Complexity seems to be a very common personal trait amongst managers. However, without question the best and brightest people I’ve worked with have been the ones with the insight to make things simple.
An example is when someone says ‘I have come up with an Incident Management process’ (I’ve blogged about Incident Management before).
Often, with a flourish, a flowchart is often produced. I’ve nothing against flowcharts (Serio has some pretty nice ones for example) but Helpdesk and Service Desk managers do seem to be intoxicated at times by them. These flowcharts twist and turn, doubling back on themselves, looping and branching, applying different (and obscure) status values before coming to an end. In my experience these are almost always unnecessary and destined to be ignored by Incident Management staff who are getting-on with the business of resolving Incidents and dealing with customers.
Instead focus on customers, restoring service, how we organise teams, how do I develop a sense of quality and ownership, how do we assign between people, how can I develop my team leaders, who owns the tickets, what responsibilities do people have. Be outward looking.
More than anything, keep things simple. If you have a team at the smaller end of the scale, don’t regard this as a problem – instead view it as an advantage by making your procedure and processes simpler. Adopt an attitude that your staff are trained correctly and know how to do their jobs. If problems become evident early on respond to them, but don’t try to anticipate problems in advance.