When I first joined, Liberty had about $1 billion of gross written premiums, the total staff was around 250 and we had four offices in London, Cologne, Madrid and Paris.The business change team was six people including myself.

Towards the end of 2017, we had grown to $3.8 billion in gross written premium, we had 1,800 members of staff spread over 58 different offices around the world, including Australia, and our business change team had grown to 40 people.

The challenges of change

Our change team was embedded within IT. This meant that projects were sometimes sponsored and led by our IT organisation which had an occasional vested interest in the output, rather than taking an independent view of what the business wanted from technology.

We didn’t know how our projects were performing because there was a culture of fear. People did not want to report anything other than ‘green’. When I first joined it was a sea of green.

This does not reflect reality because projects tend to go through a phase of red, amber and then green at points during the lifecycle. That is the nature of change; there is always an issue. We called this watermelon reporting where it is green on the outside but red on the inside.

"We didn’t know how our projects were performing because there was a culture of fear"

We also had poor sponsorship with a young executive and management team without the experience. In fact, PwC recognised that poor sponsorship and poor leadership were some of the top causes for failing projects across the industry.

Without the right leadership, we were not managing our pipeline and sometimes projects would come to us as a surprise. This was not what I wanted. I needed to know what the project was, when it was coming and how much it would cost.

We also had a rigorous change process focused on governance paperwork rather than delivering projects. This was not beneficial to the business and was leading to slow delivery.

We also found issues with reluctant stakeholders, overloading subject matter experts and business change saturation.

"What should have taken six months to deliver was taking between eight and ten months"

From growing so quickly, we found that we were always going to the same core people within the company who knew how it was running and the right way to deliver a new process or system change.

The problem was that these people were being sucked from one project to the other. So, what should have taken six months to deliver was taking between eight and ten months. We were unable to find the right resources at the right times to deliver our projects.

We were also delivering too much to the same teams. As the scale of the company grew, we started to lose control of how many deliveries were going to which teams. For instance, a marine underwriting team could have received three new systems in over three months, which would not go down well with that department.

Senior managers and executives were focusing on output rather than capabilities and meeting their own objectives rather than that of the business. We needed to understand why something was important, the benefits and what the motivation was for doing it.

Building the right team

To address these challenges, we built an independent change team, taking it out of IT and putting it into the business.

It was still part of Operations and reported to the group Chief Operations Officer (COO), but it was distinct from IT and could report independently on projects.

We reported amber and red projects for the first time, but realised that the culture of the organisation needed to change as sponsors took red and amber flags as a personal judgement rather than a true reflection of where the project was at and where it required remedial action.

We also developed a sponsor education program with the help of an external provider (chair of the change management institute). It was a tailored and targeted sponsor education program for senior managers who were informed on what their responsibilities are and how to act as a leader in a forward-thinking company. We still do this today for new and developing sponsors.

"We built an independent change team, taking it out of IT and putting it into the business"

Over time we built a team with the right skill-sets. We still had no sight of the future pipeline, so we needed experienced portfolio managers who built relationships with the senior executives running the company to understand their strategy and ideas for the coming years and helped them shape change programmes to fit their needs.

I stripped out a lot of the organisation’s governance and change processes. We sent 100-page packs to change boards and governance meetings, but these were not effective.

Once we had stripped them back, it was possible to make decisions about whether to start or finish a project with only one or two pages of information. Suddenly our projects were no longer hindered by slow decision making.

We switched from a largely waterfall, Prince II type of methodology and started introducing Agile methodology.

"Suddenly our projects were no longer hindered by slow decision making"

We did this carefully ensuring that we delivered Agile well with 2-4 initiatives rather than what I have seen other companies do where they have an Agile manifesto, which states that they are going to wipe everything out and solely use Agile.

I have never once seen this work yet and so we picked a few projects to do well within an Agile manner and slowly matured and grew the function within change and the business.

When we started off with a team of six people, it was easy to know who our stakeholders were. We had personal relationships with them and we knew who to go to and how to make those changes.

As we got bigger and started to move into more countries, we found we did not know who our stakeholders were, and we started to meet with resistance.

We started to analyse our stakeholders and look at them in a different way. In a team of 20-30 people, we realised everyone sits somewhere on a curve.

"We started to analyse our stakeholders and look at them in a different way"

There are innovators and early adopters, and it is key to know who these people are within your team. They are your supporters and will be pro-change. Next are people sitting on the fence who may or may not be convinced of the need for change. Finally, there are the laggards who are never going to want to change.

We started working with the innovators and early adopters before working with the other groups. This way it didn’t look as though it were the change team forcing a project on them. Rather their own team members were big advocates for change.

Improving efficiency

The other challenge arose from delivering too much to too many teams. We created a graph to show efficiency versus time with the premise that when you deliver a change, the team will become less efficient because they must learn something new. Obviously given enough time the change will result in more efficient teams (assuming a successful project) .

The issue comes if you start to deliver too much change. For example, when a team is halfway through one change and they are forced to take a second change. Then, as they are halfway through change two, a third change is implemented. At a certain point the team just decides to stop and go back to the way they were working because it becomes too much.

This isn’t theory, this is what we experienced. Our executive team said they wanted to see what the breaking point was and how much they could get away with. We got to see that breaking point quite quickly.

"The issue comes if you start to deliver too much change. At a certain point the team just decides to stop and go back to the way they were working because it becomes too much."

We developed a simple tool in Excel to understand the level of change around the world. We had more than 50 projects and I couldn’t try and track these on a huge Microsoft Project Plan when they were constantly moving.

This tool made it clear where I should be looking to identify too much change for a certain team. This helped other heads of departments see what was coming over the next 12 months to ascertain what they could absorb.

Also, we wanted to manage resources particularly business teams and SMEs. We looked at the teams on a heatmap basis to see whether we were using more than 10% of that team to deliver change as typically our business teams were not directly resourced to deliver change.

Every business as usual (BAU) team is focused on their own work 100% of the time. They do not have a 20% capacity for change. For teams showing a red warning, we needed to see if they had resources, or whether we needed to add staff or reprioritise workloads.

Generating new behaviours

Early challenges for the change team were behavioural. If a project was going over budget, we had to decide whether to take something out or ask for more money. We had lost focus on why we were doing the project, the benefits of the project and the reasons for it.

We ended up changing our entire way of thinking from the very beginning of a project. We now look at the project’s benefits to determine whether we were trying to save money or grow the business.

Initially sponsors would claim that a project would bring in $5 million gross written premium, which sounded fantastic, and the business case wrote itself. When I said the Finance Director was going to want to see this on the P&L, the figure changed to closer to $2 million.

"We ended up changing our entire way of thinking from the very beginning of a project"

This started to generate different behaviours within the business, but mainly within the company’s senior management.

Every decision was based on the benefits which meant that if a project was going wrong, which typically every project will do at some point in time, we looked at what we would need to still meet those benefits.

To make this meaningful, we had to have a benefits realisation process. This came down to the Finance Director partnering with the change team so that once a project was delivered and bedded in, benefits could be realised.

A finance person could go to the sponsor and ask for the $2 million dollars and have it shown on the P&L. This built a very different culture around how we manage costs on projects.

We needed to ensure that our business BAU wasn’t being impacted by projects. We did this via prioritisation. We therefore looked at all projects through the lens of value against complexity.

The ‘best’ projects were those that were inexpensive and simple to deliver. Then we worked through to the most complex and costly changes establishing the real value in delivering those projects.

"The ‘best’ projects were those that were inexpensive and simple to deliver"

Sometimes the larger projects were important because they enabled value from other sources, like outsourcing, but it needed to be prioritised.

We also started to look at our project management office (PMO). A lot of PMO’s are seen as a necessary evil; the police of the project management community. We wanted to be different and more supportive of the organisation. We looked at the tasks and issues like risk management, project planning and setting up workshops.

We employed well-paid people to do these tasks, which was not good value, so we shifted these tasks to the Project Management Office. This gave the project managers more time to focus on their core capabilities rather than spending half a day diarising a workshop across three different countries.

As a consequence, we became more scalable and grew the project management team, knowing that we had a PMO team to support them.

As most business teams are 100% built for Business as Usual (BAU), we needed to look for how to increase their capacity to spend on change activities. Therefore, we looked at how to increase their time by looking at quick and easy ways to make them more efficient (lean six sigma type approach).

"We became more scalable and grew the project management team, knowing that we had a PMO team to support them"

By sending in a lean team and looking for some quick wins we were able to free up people’s time to spend on projects and project delivery.

We started to rollout Agile thinking in a more expansive way throughout the company rather than just change team. We wanted everyone to have more knowledge about what Agile was, because a lot of preconceived notions were completely incorrect.

For us to grow Agile as a function across the company, we needed the business team to understand the terminology to begin with. We ran communications programs to start bleeding that out of the company.

Decision making in the company was top down and made by three or four people. We were forced to look at how the decision makers could delegate more to the project teams. This meant that suddenly the projects were going a lot quicker, but they were more empowered and were positive about the change.

Classic project management covers planning, business cases, issue management and risk management but change management is a different focus. It isn’t suited to all project managers because it is about how to change behaviours in people and tracking whether a change is sticking or not.

It is about figuring out what metrics to put in place to determine whether a change has stuck or not and, if it hasn’t, what we will do about it and how can we influence people.

This article is taken from the research report Fund Technology, Data and Operations, Europe 2019. To download the full report click here.

 

Please Sign In or Register to leave a Comment.