Diagnosis Of Common issues Affecting Many Organizations Today.
"Firefighting", "too busy" and seeing repeat problems time and time again are all symptoms of a stressed or innefficent IT Service Management environment. Specifically, these include:-
*Stress - too many incoming problems generated by the production environment for the number of people available to handle the problems
*Innefficiency - correct amount of people available but those people are not trained/practicing best practice
*Lack of knowledge, appreciation and understanding - The people and teams who support the production environment are not structured correctly around the ITIL process descriptions, which are there to underpin the IT strategy (which should have a clear line of sight to the overall business strategy). The people lack experience in identifying multiple and/or repeat problems. The incident management process is not closing down and categorising incidents and known errors correctly - so you need to look further up the "food chain" to the Service Desk and level one support team operations.
1. Take the temperature down.
The goal here is to attack the worst offending problems first, eradicate some of them quickly and "buy yourself" some valuable thinking/planning time.
If you don't do this you will move from one fire to the next.
- Identify where the sources of pain are regularly coming from. Track the "Top 10" problems by impact on the business/operation and also by frequency of occurence. Produce these reports and trend them by week, month, quarter and eventually year.
- To do this effectively you will need to correctly label your problems by categorising them properly (severity / priority / impact / cost of occurence / cost to close down etc).
- Focus more support team activity on understanding exactly why these occur in the first place using true root cause analysis techniques. More people onto temporary assignments. Use overtime. Backfill 'regular' roles with temps. Create new "task forces" designed to attack these problems.
2. Make elimination a part of everyday life.
The goal here is to build into the day to day operation all those activities that need to take place to effectively DO Problem Management.
- Examine the Service Desk, Incident Management and Problem Management functions. Look at the flow of different types of incidents through these functions and (i) ensure that simple incidents are in fact resolved early on (say by the Service Desk), (ii) check that the incident management function is correctly categorising your problems. Without this the volume of problems being pushed through to Problem Management will always stay overbearing.
- Establish (if you have not already done so) a separate and independent Problem Management team. It should be independent from the Service Desk and all support teams. Give this function some 'real teeth' and management support. Empower the people who work in this team to "do whatever it takes" or "no door is closed" when assertively trying to eliminate problems from production. Enable the team to talk to and freely communicate with suppliers, internal support teams and managers to drive forward the Problem Management agendga. From this description you can see that strong communicators and relatively assertive people are best for this role.
- Track progress every day. "What gets measured - gets attended too". Publish daily, weekly, monthly and quarterly reports - not just on how many different types of problems you experienced - but what the teams did to prevent future recurrences.
3. Establish the continuous improvement mindset across the IT organisation.
- To deliver world class service, you need world class delivery processes/tools and most importantly people. It's people who make the ultimate difference.
- Hardwire the results and achievements of Problem Management (I.E. reduction of repeat and high impacting problems) into everybody's in-box, across IT, in the correct way.
- Help people understand how they "fit in" to what Problem Management are striving to achieve. E.g Project managers can deliver new releases with minimal (but known) errors and assist by improving future deliveries through improved testing and/or original build quality.
- Let all the project managers KNOW how their release did, say, for the first six weeks after the release. There are many more examples across the IT organisation.
* KEY *
- Recognise and reward progress. It's people that make service happen - not tools or technology. So make sure that management recognise and reward people for a 'great job' done. Afterall every problem permanently resolved means a cost saving to the business/organisation in some way. It also means that attention can shift to the next problem on the list. Recognition also reinforces the reality that Problem Management is vital and sends out the right message to other teams within the IT organisation.
THINGS TO AVOID
- "Hero" mentality. Too many people actually get a buzz out of firefighting and actually enjoy the adrenaline rush it creates! Watch closely the next time some major incident occurs. There are probably groups of people huddled over PC screens busily discussing the problem - often far more than should be involved. It's infectious and eats up a tremendous amount of the organisations time. Time is money. The "Hero" mentality also physically drains people (adrenalin effect) and they will often be troughing their performance level for hours if not days after a major incident.
- Upsetting the Technical folks. Technical specialists do not enjoy Service Management people wandering around and 'poking their noses in' where it's not really welcome. Problem Management have a tough job to perform - so it's vital that they strike up and maintain solid real-life working relationships with the other teams. Firm - but fair. The Techie folks should be subtly reminded each week/month (via reports) that if it was not for Problem Management then they would actually spend more time on repeat (boring!) incidents. So Problem Management must be seen as a benefit to the organisation/business as well as to the internal Service/support/techie teams. Having said all this sometimes you have to break down doors when the heat is on and this means being demanding and/or going over people's heads to get the job done. Be careful when Problem Management need to use these cards.
- Upsetting Suppliers. In the long run, most Supplier managers are agreed. You don't get anywhere 'bashing' suppliers with the perverbial stick. The best approach is (a) have sound contracts in place to fall back on [note - if you have to refer to the contract every incident - that's a sure sign that the relationship is in trouble!], (b) nurture true business relationships based on mutual respect and an understanding that you are trying to deliver the best you can for the same organisation/business and (c) People who have been previously bashed are far less likely to step-up and risk getting bashed again. I.E. You never know when you need a particular skills set or person in the future.
- Solving the whole organisations problems. The function is not the agony aunt of the business or the technology department. Ensure that Problem Management have a clear mandate and scope so that it is not used as a scapegoat for legacy issues/political agenda's that are found in most organisations. Keep the Problem Management team focussing on reducing business impact of repeat problems.
Bottom Line:- Problem Management is vital. It saves money. It prevents time wastage. It's difficult to set-up and establish. It needs the right kind of people working within it. Right skills, right knowledge, right level of authority.