Developing a vision for major change

In the second part of this InsuranceERM and Milliman roundtable on systems transformation, industry experts discuss how they define and manage a major systems refresh, how they deal with software vendors and the 'waterfall' and 'agile' approaches to development

Scoping transformation projects

Chris Cundy: Do you find it easy to define the scope of a project? Is it always clear about what the endpoint is going to be?

Pat Renzi: You must have the vision because, for a large transformational project, it can span three-plus years, and I do not think that you are going to know exactly what that plan is going to look like for three years. You have to be willing to change it along the way – not from a scope creep perspective – but to make sure that you are achieving your vision.

Martin Burke: A somewhat more nebulous but no less important point for me is: what is it going to feel like when you have actually gone through the change?Then you try to get some specification or view about that upfront so you can reflect back on it and think, 'Why is it not like that now?' I was at a conference a while back where someone presented the concept of an OSSA, instead of an ORSA¹.

Chris Cundy: What is an OSSA?

Martin Burke: An own success and solvency assessment. That involves specifying upfront what success looks like and saying what is going to change in a measurable way. I have not really managed to implement it in anger just yet, but I think it is a good idea.

"Scope creep tends to occur where there isn't sufficient planning and definition done at the beginning of a project." Martin Jarman, RSA

Going too far

Chris Cundy: Do you recognise the risk of perhaps going too far with transformation?

Stephen Coombes: That is called scope creep, is it not? It is a constant battle to prevent that happening and I come across it frequently. Even in the last week or so, I was buying two software packages and there was a third one that 'we simply must take because it is complementary and it is part of the suite.'

Martin Burke: You made the point at the start that transformation never really ends. I think that is the intractable problem. You are constantly looking at where you are and thinking, 'I would not start from here, but this is where I am.' You get there somehow, on a road you did not particularly plan to use. That is just something to get used to and to live with, I think.

Zaneta Kovaliova: It is quite easy to lose your focus and deviate from your original objectives, so it is important to be really selective in terms of the changes you make on your journey. There will be lots of people who will come and ask, 'Can we have this, can we do that?'

Martin Jarman: Scope creep tends to occur where there isn't sufficient planning and definition done at the beginning of a project, and then you are not quite clear exactly what you want. Then the project meanders its way forward.

Measuring the value

Chris Cundy: What sort of challenges do you face around putting the value of a transformation down on paper?

Zaneta Kovaliova: It is important to define the benefits of the change programmes and what we are going to achieve at the very beginning and you need a mixture of quantitative and qualitative benefits. Will we save X amount of cost? Will we provide better and faster information?

Chris Lewis: Do you find that the qualitative is 'nice to have', and that it's the quantitative impact which is all important in decision making – i.e. unless a project is expected to pay for itself in X years, you are not going to do it anyway irrespective of any other non-financial benefits it may bring?

"When you are dealing with vendors, it is important to pull them into your space" Martin Burke, MSIUL

Matthew Croft: I tend to find that people are very comfortable with business cases that are around hard metrics. Where they get less comfortable is when you are trying to justify something where you are going to get better analysis or help the pricing team improve pricing. Things like that are nebulous, but actually very important. That is where you end up having to do the sell and really try and get your stakeholder management buy-in before you present your business case.

Chris Cundy: Are vendors and consultants always clear about the benefits of the new systems?

Martin Burke: When you are dealing with vendors, it is important to pull them into your space, not just to leave them to demonstrate what they want to sell you. It is more, 'Here are my problems. Here is some of my data. Why do you not try to do something (i.e. solving a specific problem) with that in a way that reflects the value of your product back to me?'

Matthew Croft: I am relatively new to the modelling space, but when I have bought applications on the finance side, it seems much easier to go to analyst firms and talk to lots of people in the industry about their experiences. On the modelling side, there is a much smaller user base. I think there is more risk around some of the modelling and risk software than perhaps in other spaces I have worked in.

Jack Buckley: There are a lot more companies coming in now and trying to look at what options they can give to the customers. But, often, as they are trying to sell something to you, it comes back to Martin's point. How do you get them into your company and understanding what you want? Specifications are not always perfect, and they can miss key requirements. Keeping that discipline to stick to the KPIs [key performance indicators] takes a lot of courage.

Pat Renzi: As one of those vendors, we would not enter into a transformation project unless our project team was completely embedded with your project team. It just does not work if you say, 'These people are building the software or implementing, and our team is going to use it.'

Chris Cundy: As an actuarial risk team, you are always used to responding to business needs and things come up that you never anticipated. How do you cope with that situation when you are trying to manage a project?

Stephen Coombes: We have decided several times to move from a waterfall approach to delivering technology to an agile approach. It is about users and programmers working closely together to identify what is actually possible and testing small prototypes to see how they work. This has the advantage of cutting out some of the obfuscation and delays that can occur between users and IT departments going through the traditional route of relationship managers, analysts and requirements documentation. I do not know how many other people have used that approach, but it certainly worked for us in terms of delivering improved results more reliably and swiftly.

Matthew Croft: I have used it on the business intelligence reporting side of things, where you have just got lots of data and are trying to understand data – there it works very well. Our IT area has tended to be more comfortable with a waterfall approach, but are now beginning to embrace agile developments.

Pat Renzi: Our development team is completely agile.

Matthew Croft: You are finding more and more people that are going that way. I talked about people wanting to see some 'jam' early on in these projects. Waiting two years to get something in a traditional waterfall approach does not get political buy-in. The world changes too fast.

Pat Renzi: As we see with Solvency II, you can define what your specifications are going to be but the regulations change before you have ever implemented it, if you are using a waterfall approach. Also, it comes back to the resource issue. We have a very difficult time attracting highly talented developers in a waterfall. They want to work in an agile environment, because it is much more interactive.

Experiences of transformation

Chris Cundy: Generally, has transformation been a good experience for you?

Matthew Croft: I am very passionate about what systems and processes change can bring in terms of transformation projects. They can move business forward and change your functions and way of working in a really positive and good way. Are they always good experiences? They can be pretty painful experiences, but ultimately I think the prize is worth it.

Martin Burke: I think it has been a good thing and a bad thing. The problem is that you are not always building on the same base. As we talked about earlier, you end up with the internal political changes and management changes, and suddenly what you were doing is unfashionable, or there is just the desire to change it. The changes you successfully implement turn out not to be forever after all.

"First, be absolutely clear about your objectives, and second, get the very best people." Stephen Coombes, Sun Life Financial of Canada

Martin Jarman: That is why these long-term transformational projects are always risky. I have seen plenty of instances where investment in a project is not utilised following a change of approach and/or a change of culture.

Chris Cundy: What advice would you give to somebody who is embarking on a major transformation project?

Zaneta Kovaliova: Really spend time on the planning stage and preparation. Provide clear objectives. Secure an executive sponsorship. Have a communication campaign in place. There is an expression that successful change is about knowing your path, why and where you would like to go and winning people's hearts.

Martin Burke: Be committed to the point of being irascibly pig-headed about it, but also acknowledge that there is a tipping point at which you may have to rethink what you previously thought about it. Always have some scope for compromise, but do not compromise too soon.

There will always be naysayers, both covert and overt, who do not agree with what you want to do, for maybe some of the right reasons and maybe some of the wrong reasons. You have to deal with the people side of things constantly, but that does not always mean you should divert your course.

Stephen Coombes: First, be absolutely clear about your objectives, and second, get the very best people. In my experience of delivering projects, those two things make the biggest difference, perhaps especially the second. I have been through long and extensive projects where we have hired contractors and we really have not made the progress that we should have done. We should have been a lot more ruthless, really, about moving on, replacing and demanding higher standards.

1. Presentation by Peter Brewee, CRO at Delta Lloyd Life Belgium, speaking at Towers Watson's ERM Forum, October 2014

Part 1 of this roundtable can be found here