About the company
Irish Life & Permanent is one of Ireland’s largest companies, with over one million customers in its home country and annual revenues of around €880 million.
The financial services organisation is the result of a 1999 merger between Irish Life Assurance and the Irish Permanent Building Society, which was bolstered with the acquisition of Ireland’s Trustee Savings Bank – now called Permanent TSB – in 2001.
To drive cost savings from those mergers, the combined company pursued a centralised IT infrastructure strategy, which sees the group IT function provide infrastructure and IT support to each of the individual business units. But according to group IT customer services manager Colm O’Shea, the first few years after the 1999 merger saw the IT function get distracted by data centre consolidation and system integration, and lose sight of the quality of service it provided to business ‘customers’.
To remedy the ensuing customer dissatisfaction, the group IT division launched a service management strategy. Here, O’Shea recounts the challenges and successes that he encountered while implementing service management at Irish Life & Permanent – which, unlike its two main rivals, did not require bailout money from the government in the wake of the financial crisis of 2008 – and explains the value of the service management approach during a cost-cutting phase.
Information Age (IA): Before you started your service management programme in 2002, how was IT and infrastructure support perceived by the business?
Colm O’Shea (CO’S): When we decided to address our service delivery back in 2002, I started by arranging some meetings and engaging the customer. Anecdotally, the feedback we got was unhappiness, even just at the level of people’s PCs being broken and no-one on the service desk answering the phone.
IA: So what was the first step towards service management?
CO’S: We began with the service desks in 2003. We combined them into a single service centre, and made sure we were using proper incident management processes. We focused on the customerfacing piece, making sure we were responding to customer needs and that they were satisfied. Back then, selling the idea of service management was the biggest challenge. Things like logging calls can just seem like extra work to do.
IA: What role did technology play in helping you achieve service management at that point?
CO’S: We focused very much on process and people, not the technology. We were still using a very old problem-logging system but our processes were so far behind at that time that the system didn’t matter. My view is that if you try to use a new technology implementation to enforce good process, then the product will fall out of use after a while.
IA: What made you extend service management beyond the service desk?
CO’S: Pretty soon, we started to realise that the service desk people were bought into the idea of service management, but the rest of the group IT department didn’t think it was their problem. They played the game to a certain extent, but they were still primarily worried about technology. So we hadn’t yet made an underlying change to the way group IT could manage change according to the requirements of the business.
We knew that we needed a group IT strategy, but it takes time to get these things going, so I had gone ahead with moving towards service management without that strategy in place, which was probably a mistake. In 2004, we engaged with Accenture and said we wanted to pull everything apart and restructure the entire department.
IA: What effect did that have?
CO’S: The output was four cornerstones: project management, finance management, team effectiveness and service management. We rebuilt the whole organisation around those cornerstones, and all the managerial roles changed: I was the data centre manager at the time, and I ended up as head of service, for example.
We brought everybody down to Croke Park [Dublin’s largest stadium] on 27 January 2005, launched the whole thing and announced the new structure. On the Monday morning after and every morning since we’ve had a service control meeting where representatives from every team turn up. The service manager runs it and we work through all the service items from the past 24 hours and what the plan is for the next 24 hours. Each team has to be there and has to know what has happened and has to have the answers.
That degree of change happened almost overnight. After that, the model was that in group IT you are either working on a service item in the service management system or you are working on something from the project management office. If you’re not doing one of those, you shouldn’t be doing anything.
IA: And how did you measure the success of that strategy?
CO’S: We took the 17 critical services across the business units and measured the availability of each service across a month and averaged it. They were running at about 99.4% when we started in 2004 and got to about 99.7% by 2006. So we had halved the downtime in those two years. That really helped when we decided to upgrade our service management system.
We had selected Axios assyst, but we needed to spend about €0.5 million to deploy it. I could show the CFO the availability graph, and explained how much we had saved the business with the work we had done so far around the processes and the people. On my fourth slide, he said, ‘That’s it – how much do you need?’
IA: What prompted you to progress beyond incident and problem management into change management?
CO’S: In 2007, we were looking at how we could take these improvements further so we looked back at theincidents for the past two years. We saw that half of the incidents were due to change, and another 20% to 30% were due to human errors. We could have spent millions on high-availability servers, but only a small proportion of incidents was due to technical errors that they could have prevented.
We decided to concentrate more on change. We put a change manager in place and set up a change advisory board, but we needed a way to motivate people [to adhere to change management processes]. We came up with the idea of a service league table, so we took our 17 services and ranked them by availability. We then assigned a team with a manager responsible for each one, and charged those teams with getting their service up the table. But it was not just availability they were ranked on: they would get points for having a plan or making an investment.
That has worked quite well. If there’s change happening to a team’s service, they want to make sure it’s managed properly so it doesn’t affect their score. It’s really got people thinking about service management, and we’ve ended up with service management influencing technology development.
Previously, when a technical guy was deciding how to spend his budget for the year, he would get the kit he wanted. But now he will get the stuff that will get him a better score on the league table. When I drew the graph at the end of that phase, our availability was up to 99.8%.
IA: How has service management helped you cut cost since the banking crisis of 2008?
CO’S: When you think about it, service management is not about giving the best possible service, because that’s not what the business wants. The business wants the appropriate level of service relative to their requirements. We were never going for 99.999% availability because that would be a waste of money. And in a way, a lot of the service management is about efficiency.
If a service desk is operating efficiently, for example, you will actually need fewer service desk people. As part of our service management programme, we consolidated three service desk staff down to one. We can do that because we have good processes. But further than that, it helps you understand what the requirements are and whether you are meeting them, so you can direct your IT spend to where it is needed most.
IA: What is the next phase of your service management strategy?
CO’S: The biggest issues we had last year arose when we put in big new releases of software or new systems: we spent a lot of time cleaning up the muck. So we’ve started thinking about how we can cut down the time it takes between the business stating a new requirement and us producing a service that meets their requirement as expected.
That means we actually design the service right from the beginning of the requirements process to make sure we can meet the levels of service needed from day one. We call this service assurance, but it maps on to what the ITIL framework calls service lifecycle management. That’s where the journey is going next.