Why major change projects fail: Interview with RBS' Sofie Blakstad
When projects are driven by the "wrong people for the right reasons"
"We typically blame project delivery for project failure," says Sofie Blakstad, CIB Programmes Director at the UK's RBS bank. But "the 'real' problem usually lies well before the project has even been initiated."
In this PEX Network interview, a transcript of a recent podcast, Sofie describes common reasons that major change problems fail, including the wrong motivations for starting the project in the first place. She also discusses the importance of getting the "right" executive sponsorship for the project, how important it is to derive the project benefits from your organization's strategic objectives (and then translate them into operational metrics), and how approaches to change have evolved in financial services over the last two decades.
Sofie will be speaking at our upcoming Innovation and Business Transformation in Financial Services conference taking place this October in London.
This transcript has been edited for readability.
PEX Network: It’s sometimes said that process practitioners can lose focus of the outcomes they want to achieve when they get lost in methods and tools. Would you agree that’s a trap that’s easy to fall into?
Sofie Blakstad: I think losing focus of outcomes is risk for all change professionals. It is especially true when the change team isn’t directly engaged in quantifying business benefits of the change and aligning them to the overall business strategy.
This can happen for a number of reasons. Sometimes, it is because your change function is buried in technology. Technology is one of the traditional places to put "change". In the case of a process team, it can happen because the change team is part of a larger delivery team which operates independently of architecture (which means there isn’t a direct link between the business strategy and the execution).
More commonly, though, it is because projects aren’t being sponsored or driven by the individuals who will themselves benefit from the outcomes. In many organizations, a large number of projects are simply driven by the wrong people for the right reasons. This results in the projects not achieving their business benefits effectively.
It is very often true of technology driven projects, in particular, but we have also seen process change typically being driven by logistics or a cost control function where the business impact is secondary to the desire to reduce staffing or cost in general.
In my experience these lead to temporary savings where you see the staff dip and then ramp up again. However, a full business driven engineering can achieve much more sustainable benefits alongside enhanced customer experience and, of course, faster time to market. This is the triple crown that you are really after.
PEX Network: How do you start to shift the focus so you are looking at the big picture?
Sofie Blakstad: It is about structuring and maintaining the relationship between your organizational strategy and how your project lens changes your process and capabilities.
That often means taking a long hard look at how you drive projects. We always talk about senior sponsorship being critical to the success of process optimization. That is absolutely true. But you also need sponsorship for the right reasons and by the right individuals.
The sponsor needs to have the right level of vested interest in the outcome of the project and what it will mean for them in the BAU ("Business As Usual") operations. Fundamentally, your sponsor really needs to be accountable for the business strategy in support of which your project is realizing benefits.
If you have a sponsor who knows the project is the right thing to do for the organization but doesn’t have a vested interest in operational success, you’ll suffer from a lack of engagement and a lack of expression of the architectural strategy into the benefits that the project brings.
The second key is delivering the right benefits, which sounds obvious but isn’t always. You must derive the benefits map from the organization’s overall strategy. This is in contrast to what we tend to do, which is to retrofit the strategy into the business benefits.
Once a problem statement has been created we often come up with all sorts of wonderful ideas and we say ‘how does this fit the strategy?’ But the questions we should be asking are these: how can we express our strategy in terms of capability change? and what are the priorities for the organization?
If I were visiting your core business objective and looking at how you break these down into benefits you can identify what success really looks like and by expressing these as critical success factors for your project and maintain that focus throughout your delivery.
The third key is to ensure that all of your project’s critical success factors also become BAU performance metrics to be used as sustainable improvement metrics by the BAU team. This has the benefit of ensuring that your project’s success factors are sustainable as the organization moves into continuous improvement.
I hear a lot of staff, for instance, say that the success factor of a project is to have changed the process. That is not the success of the project. The success of the project is delivering the business benefits and the capability changes. If you can’t land those benefits into BAU metrics, then they are probably not the right benefits. It also means you are probably not achieving success as far as your strategy is concerned.
I find that is a very good measure: Can you land your critical success factor as a BAU metric into the BAU which you can use as performance measurement for the people doing the process day to day?
PEX Network: You have been working on process and technology projects in banks like UBS, Citi, and Lehman Brothers since the 1990s. Currently, you are working at RBS. Have you seen a difference in the way that financial services organizations approach process excellence change over that time period?
Sofie Blakstad: That is a good question and thanks for reminding me how long I’ve been doing this! Obviously I can only speak of my own experience and what I saw where I was working.
First of all, investment banks in the 1990s (during which time I was at Lehman Brothers) saw themselves very differently to today. There was much less integration of technology with the business. Criticality of technology was only beginning to be fully understood. And process was a word you rarely used - it was only associated with form filling rather than what you or I would describe as business process.
Outside of technology the concept of formal change process was rarely used and a structured methodology for things only applied to what happened with the bits and the bytes (i.e. the technology).
I was involved in that when I was at UBS working on Y2K [a widely feared software problem in the lead up to the year 2000] there was a distinct shift towards viewing change as change - even outside of technology. This was happening in parallel with a much closer dialogue between technology and non-technology functions. One of the advantages I had when I was at UBS working on Y2K was to drive a lot of that change and also experience it happening.
This was a fundamental culture shift from regarding technology as the people who did the "nuts and bolts" to being very much a part of the organization’s success and the future of the organization. That was probably the biggest shift of the mid-to-late-90s: moving from technology as a service provider to technology as an integral part of the business and the business processes.
That is when non-technology functions started to see the benefit of structured approaches to change and, in part, when they started to adopt what you and I would recognize as a structured life cycle for non-technology change. But even then, any process change was either a technology requirement or happened to be something that people did. It wasn’t really thought about in terms of process and it was usually processes wrapped around technology.
Personally, I did a fair amount of optimization without really understanding what it was. It worked and it supported business improvements but we didn’t analyze why or how it worked.
There was a bit of a push for doing Six-Sigma after the GE Story became popular but most banks who tried to adopt it weren’t really prepared to make the investment that was required. Certainly we didn’t see anything as big [in the investment banks] as the way that Jack Welsh at GE had done.
I also believe that the banks at this time weren’t prepared for the cultural shift needed to make Six Sigma work. One of the key successes that Jack Welsh achieved in GE was the big cultural shift and the focus on listening to everyone. The banks certainly didn’t operate that way; there was still very much a command and control atmosphere in investment banking when I was working there in the 90s.
However, things began to change: Lean Six-Sigma started to merge with the service industry and there was a parallel shift in banking towards thinking much more holistically about how service functions supported the business (and in particular technology). Then, following the dot com collapse organizations were much more aware of the value of technology as well as the risk.
Paradoxically, although the shift toward technology moved the focus more onto the capability of the technology and the business process, it also educated a whole generation of non-technical people in the basics of structure and process thinking. Even though they may not have been aware of what they were talking about process thinking was fundamentally what they were learning.
I think this was really fundamental in paving the way for process oriented organizations towards the middle of the noughties (2000s). There was still money left to invest and experiments with Six-Sigma in the early noughties had gone badly in some of the organizations I had worked for which meant that when we readopted the approach later on we actually had to avoid using terms like Six-Sigma altogether because people were so put off by it.
What really drove it home in the mid to late noughties was the ever increasing imperative to reduce support costs and increase successes. There were some pioneers who were out there and doing it successfully but banking is a very conservative industry and it takes a lot of critical mass to get these things moving.
All of the successful programmes I’ve seen - whether you’re looking at someone like BNP Paribas - or some of the more recent programmes many banks have all started with small proof of concept programmes which were all very process focused and have yielded immediate results. I was lucky to have the opportunity to work on some relatively large programmes and achieve some tremendous results on a larger scale. However, without the proof of concept it is difficult to persuade an organization that the benefits can be achieved. This is especially true in a conservative industry like banking.
Nowadays many organizations are probably moving to be more conservative than they were then in many ways. There has been widespread adoption of the McKinsey approach and that is particularly effective in operational support functions. It is a tried and tested way of making incremental improvements.
However, I am not seeing as many large scale reengineering projects which are labeled as such. Some of them are hidden as business change – "we are really doing the engineering but we call it something else" - or they have labeled the projects technology change when actually what you are seeing is process change. There is a lot of merging of the disciplines across process, technology and business change, whereas we used to see much more segregation of the concepts.
We can trace a lot of the nervousness about having large scale pure reengineering projects basically down to a lot of organizations having had their fingers burned by ambitious large scale reengineering projects which really haven’t delivered. We can trace much of that non-delivery back to the sponsorship problem I mentioned before where sponsorship changed or programmes started off but were overtaken by shorter term priorities. As we all know, the programme is what gets blamed and not the change in politics.
PEX Network: You have recently written a book exploring some of the reasons that major change programmes fail to meet their business objectives. Why did you decide to write this book?
Sofie Blakstad: I have a background in academic research on major change programmes. I was doing a doctorate on the topic so a large part of the book was drawn from my research. My research on major change programmes spans a wide range of disciplines including major infrastructure change as well as business transformation.
Throughout that research I identified some scenes which turned out to be strong predictors of project failure. By failure I mean that they didn’t meet their business objectives.
We typically blame project delivery for project failure. In fact, through my research I have discovered that the "real" problem usually lies well before the project has even been initiated. That were very much the focus of my research. I found, for instance, that the number one cause of project failure is a political motivation for initiating the project in the first place absolutely independent of the type of project.
Meanwhile, projects most likely to succeed are those that are initiated with a motivation of increasing profitability and just making more money. If you start out with a clear objective that is purely financially driven, those projects are almost all successful. So by looking at the motivations that drive these projects and that drive the initiation of these projects, you get a much stronger predictor of whether or not they will succeed.
Complexity is another factor that contributes to project failure but its effect is not as strong as motivation [for initiating the project].
In presenting the correlation between certain motivations and certain failure factors that we see happening over and over again, we can help strategists, architects and senior managers avoid these common pitfalls. I present a correlation of analysis that demonstrates how the sorts of problems that arise in projects can be dependent on the motivations for starting those projects in the first place. It’s a useful tool for people starting out projects and questioning the motivation for the business cases that they are building and how they map to their businesses strategy.
I also developed themes that we have talked about just now about how to drive a strategic change agenda supportive of a business strategy by building a solid and unambiguous benefits framework all the way from the strategy through to post "go live" BAU performance metrics. That is an amalgamation of the research I have done as well as my experience working on change projects both in the process space, the technology space and in the business space.
I have also have some examples of how to do it right and how to do it wrong which I hope people will find entertaining and useful. Some of the biggest stories we know about are quite often things we can learn from rather than just laugh at so I am hoping it is both instructive and entertaining.
PEX Network: Taking it back to something you mentioned earlier which was the importance of shifting the culture. We often think of process excellence as long term requiring a change in culture and the way people think. Do you think there is an increasing focus perhaps within financial services on changing the culture and on taking a longer term view?
Sofie Blakstad: Yes and no. That is a good answer isn’t it?!? Yes, in terms of culture and core business values. Core business values are what we tend to describe as culture in terms of the way that banks are looking at a longer term view.
Most of the organizations I see around me are working towards embedding their overall strategy and their core business values in the strategy change agenda so that is a positive thing. There is much more focus on business architecture driving change and less of a piecemeal approach (depending on the organization).
It does vary organization to organization quite a lot and certainly some are much further down that journey than others. I would say that HSBC has done tremendous work in that space recently, as has Barclays with their Gamma project (although they’ve gotten bad press about it).
However, this is still very strongly counterbalanced by the need to realize short term benefits and cost cutting, which is where the "no" part comes in. This is still the biggest factor undermining a longer term strategy.
It is a really difficult issue because in most cases senior executives’ hands are tied. They are forced to invest in change supporting the increasing number of regulatory rulings and really cramping the ability to land strategic change. Budgets are tighter than ever and none of us are getting more money. None of the banks are making a huge amount of money so that is a huge limiting factor. Longer term investments like large scale process optimization are falling victim as is culture change.
So although there is a strong drive for culture change, there’s a level of investment required to make it a success. Look at an organization like ANZ (Australia and New Zealand Banking Group) in the South Pacific, for instance. They did some fantastic things but it was a huge investment. Organizations, particularly banking organizations in the West, can’t afford those sorts of programmes today.
This is where we probably need to revisit the approach we worked in the noughties (2000s) where we looked at the key pain points and strategic priorities with smaller scale projects that can realize more immediate benefits and really take a more proof of concept approach and drive a lot of this stuff top down through the management layer rather than the holistic approach.
Although, I think the holistic approach is always the most successful one, it really requires a significant investment, significant education, significant time spent on it and very few organizations have the appetite or the ability to invest in these days.