Recently enVirtua has been providing issue resolution management services on a large IT project.
The problem with large projects is that there are always issues that arise that push back deadlines. As deadlines get pushed back, revenue can be affected as your project fails to deliver on time. This is bad news for any business (or project), so ensuring you have planned for problems and have processes in place to fault find, design solutions and implement the solutions is vital! Key also is having processes in place to document all the issues so that you can identify and understand the root cause of the problems and ensure that these sorts of issues don’t happen again in the future.
Managing all this is difficult and needs quite a bit of effort, which often is not planned for or resourced fully.
On our current project, the client appreciated that they needed to bring in some extra resource to deal with the growing pile of issues and also to help put processes in place to lessen the resource required to deliver their product on time. There is always a balance betrween “fighting fires” and fixing the underlying causes of the issues.
One of the big issues every business faces is that the “fire fighting” normally takes precedence over the underlying problems. Which is not the way it should be, fixing one underlying problem might decrease your “fire fighting” by 25%.
And example is configuration management, a common problem in many organisations. I have lost count of the number of corporate networks I have worked on where the documentation showing how things work is poor or non-existant. It will almost always be out of date (if it exists). This does not cause a problem… until there is a problem. Without an accurate map of the system, it is very VERY difficult for people to try and fix complicate root cause issues.
Creating a documentation process is often a good starting point for any effort to solve issues.
In a previous organisation, we started small with a simple Wiki used only by two engineers. Later some of the management started using the wiki and then followed all the technical people. That initial effort to document via the wiki resulted in a combined effort that delivered a detailed map of the companies infrastructure.
In another organisation, documentation of the infrastructure was not the issue, rather documenting what issues were occuring. This we resolved by implementing a simple helpdesk application, that allowed the IT people to keep track of problems they were solving day to day. Everything from pulling paper out of printers to finding and fixing bugs in software started being recorded. The upshot of this was the IT guys were able to identify trends and focus their “sparetime” on trying to improve areas that were causing underlying issues. It also gave management visibility as to the amount of work being done by the IT team and which departments productivity was being affected the most by problems.
So having ways and means to document structure and issues is key to supporting any technical solution. The final piece of the puzzle is ensuring that you have enough resource (people) and the right resources to solve the fire fighting and underlying issues you will encounter. This is partly an HR problem and partly a process problem. You need useful people, but you also need to ensure that these people have the right tools and the right organisational structure and support to do their job well and in the best way for your business.
Many years ago, I worked on a large support team within a multi-national company. The IT support team at one stage was not balanced properly. By this I mean we had too many people in the team digging deeply into the underlying causes of problems rather than applying quick fixes (band aid solutions) to keep staff working. This happens all the time if management does not carefully select IT people. You need a mix of persoinality and competencies, you need some people who will sit and read logfiles all day to solve one issue and some people who will reboot a server in a hurry as they know it will get the system working ASAP, though not solve the underlying issue.
The other key element in all this is effective management of issue. You need to know when to dig deeper into a problem and when to solve the symptom and move on. In enVirtua’s current angagement, this is primarily what we are getting paid to do. It is vital to the project that issues be resolved quickly so the project milestones are met, but equally root causes need to be identified and solutions to these issues found and applied proactively and restrospectively. This current engagement requires that enVirtua does some quick fault finding on issues that come in via two seperate helpdesk systems and do triage, determining how best to resolve the issue. Also, issues need to be clustered and root cause analysis work is part of what we are providing along with finding the resouces best suited to making improvements to solve issues and maintaining a gentle management role over suppliers to and staff of our clients; despite our lack of real authority over those people.
It has been a challenging project, which has sharpened our senses when it comes to support structures and how they work well. Of course it has meant looking at enVirtua’s internal support structures and identifying some holes in what we do ourselves. Over the next few months we are making changes to improve our customer care and issue resolution processes as a result of working for this client.
To summarise, the “Issue with Issues” is that too often issue management is not something that is carefully planned and managed. It is left till last or not planned for at all as people (wrongly) don’t expect many/any issues to occur. If we had one thing to say to people it would be that issues always occur, always! You need to plan on problems happening and not neglect to have processes in place for when things go wrong. It will happen one day and the amount of preparation you have put into place will determine how much your companies profits are affected.
