I used to work in the IT Section of a London borough. I now still work for the same council, but in the Finance Department, doing IT type work supporting the council's financial system.
The IT Section has recently got a new head of service, who is looking to make his mark, by intoducing I
TIL to the organisation. He also thinks that the same principles can be introduced to other parts of the council's business, especially where they have a 'service desk' approach. To that end he invited people from my new department to attend an experiential training course alongside his staff. I volunteered to go along.
I was a bit apprehensive about going along because I feel a bit disloyal about leaving my old job, but it was actually OK.
The way that the course worked was that we were split into teams. Some people worked for an organisation in the retail sector, but most worked for their IT support company. The staff in the retail organistion were split between business managers each responsible for two companies in the group and one person who was effectively the CEO of the organisation. The IT support staff were organised into a Helpdesk team, a Technical Specialists team and two Service Managers. It seemed we were all put in groups according to our normal jobs. I was in the Technical Specialists team.
The way it worked was that there were five rounds during which time the Business reported problems with their services that were affecting their profits to the Helpdesk then the Technical Specialists team had to answer an IQ question and pass this solution onto the facilitator to bring the service. The questions were all in a book and the number of the question to be answered was determined by the server at fault and the number of companies affected by the problem. In between each main round was a debrief, where our facilitators told us what was we were doing wrong and a session where we could prepare for the next round in terms of organisation or by upgrading servers etc.
Needless to say, but the first round was an unmitigated disaster. My were getting to grips with all the infratsructure diagrams trying to workout what questions to answer and even when we managed to work that out it was very difficult to work out what the answers were as everybody was talking over each other also we had the Service Managers asking us for progress on the various problems. We had no real idea what problems were high priority and needed our immediate attention and which ones we could put to one side. Even if we were able to come up with the solution it still was not enough to solve the problem as we needed to give the facilitator the name of the Service affected (things like Inventory Management, Customer Services etc) the question number and the answer. We had no idea what the services were called, we knew the names of the servers affected which all seemed to be named after celestial bodies. It turns out that the Helpdesk had this information but had neglected to write it down on the post it notes they had been using to log the incidents on. The first round was very stressful indeed. There was a lot of shouting and headless chicken/blue arsed fly-ness
Several improvements were made for the next round Helpdesk gave the incidents a number so that they could be more easily tracked and wrote them up on a board. They also wrote the name of the service on the post-it note. This was a result of communication between Technical Support and Helpdesk - letting Helpdesk know what information was required to resolve the call. The Helpdesk gave themselves specific roles - taking the call, writing the incident on a board and passing the call to Technical Services. We gave ourselves roles of a runner who was responsible for passing the solutions to the facilitator, people solving the IQ problems and people working out from the various diagrams what questions to answer. The Business worked out what were the most important services for us to fix, so that we could concentrate our efforts accordingly. Also, when we had resolved an incident we passed the post it note back to the Helpdesk who were building up a knowledge base so that they could resolve the same issue at point of contact if the same problem appeared again.
In the second round we did a lot better. We did have a problem where there were lots of issues on different servers and we were coming up with solutions, but to no avail. It turned out the problem was not with the servers but with a network hub that they were all connected to. As well as actually answering questions to solve problems we can pay for consultancy where the facilitator gives us the answer, but we have to pay for it. However, if the issue is causing a big problem it is worth it. Also just as in the real world, it is important to make sure that you find out what the consultant actually did, so the solution is known if the same thing happened again. In this situation the best thing would have been to identify the problem was with the hub and pay for the consultancy to fix it quickly.
By the third round we had got to grips with our infrastructure diagrams and booklets. We also looked at performance information from the previous rounds and worked out which servers would be most effective to upgrade. We put in mirrors to provide redundancy etc. Also the Helpdesk were given an infrastructure diagram so they were able to help technical support by identifying where problems might be with hubs rather than specific servers. As a result of this spending the IT company lost money in the third round, but the business made money.
In the fourth and fifth rounds we did really well with the better infrastructure a lot of problems were not occuring at all and because we had a good knowledge base by that point most of those that did were being resolved by the Helpdesk. Also we had spent so long staring at all the problems that we either knew the answers or had decided that we could not work it out and had to pay for consultancy. So it actually turned out that we did not have very much to in Technical Support. Or rather we were able to think strategically about preventing problems or looking at the questions in a more relaxed environment when we were more likely to be able to come up with sensible solutions. It was a LOT better than in the first round.
At the end of the fifth round we did have a bit of a problem where the infrastructure had chanegd but had not been properly documented, so we were finding answers for the wrong questions because applications had moved to different servers or something. By this point my brain had stopped working. Anyway the lesson was that our change control was not all it should be. Despite this blip we still did really well in the last two rounds. We were actually the third group to do the workshop and we performed the best out of the three, which was particularly pleasing as the first group was made up of IT managers.
What I got out of the training was the importance of having specific roles but working together to a common role. Understanding your role and how it affects other people and the roles they perform. Also the importance of having proper procedures in place and of sharing knowledge. From the point of view of technical services, the fact that it is easier to come up with solutions if you are able to concentrate and are not being interrupted all the time having to deal with things you have dealt with a million times before because the correct buffers are not in place. I would say the importance of prioritising workload, but I actually think it is better if a lot of the prioritisation is handled by the processes that have been put in place. Finally I think it is important to try to find ways to stop problems from occurring in the first place. In this way, it can seem that you are not working as hard, but a better overall service is provided and less heart attacks result.
This all seems quite obvious, but the workshop brought home in a very graphic way those points, that I kind of already knew anyway. Also, I was not the only one. I was in a room full of IT professionals, who seemed to be learning the same lessons too. Although even if you had all the processes set up right at the start there still would have been a round on round improvement as the knowledge base improved and improvements to the infrastructure could be put in place.
All in all, it was a very enjoyable and informative day and obviously inspired me enough to write a very long blog about.
