Season 1: Episode 13

“Transformation is, at its heart, a reconfiguration of power, so people are thinking ‘what does this mean for me?’” This week we are joined by another special guest, Nick Ranier, a senior transformation leader with extensive experience of enterprise wide transformation. Nick shares his experience of running transformation portfolios across a wide range of settings. He also shares his perspective of why culture, organisation and people are critical to the overall success of any transformation initiative.

Season 1: Episode 13 – Business Transformation, A View From the Top – Interview With Nick Ranier

Jason West: Welcome to the Underscore Transformation Podcast. My name is Jason West.

Joe Ales: My name is Joe Ales.

Jason West: This week we are joined by Nick Ranier, a senior transformation leader with 25 years’ experience across the energy, defence, engineering, and distribution sectors. He was a member of the bunker that set in motion the build of the UK’s two new aircraft carriers, and he led the development and operation of an award winning campus for a world leading defence security and aerospace business.

Nick and I actually previously worked together, Nick was heading up the corporate transformation portfolio office, and I was leading a multi-year HR and business planning transformation programme. It’s a real pleasure to spend time again with you Nick and thank you very much for coming and agreeing to take part in our podcast. Today we’re going to be talking about the scoping phase of business transformation. But before we get into that it would be really great just to hear a bit about your background, in your own words and just where you’ve touched on transformation in the past 25 years.

Nick Ranier: I won’t go back through the full 25 years, but I’ll certainly go back a few years. Really the background and the basis for my interests of working in transformation comes from HR. Being in HR management director initially for British aerospace, and then over to a company called Alston on the transport and system side. And I think all the time as HR Director, you’re you looking at the course of your capability baselines, organisational baselines, you referentials, you’re doing your governance across the organisation, and there’s things to adjust. As new leaders come and go they will have new ideas, they always want to change things. So I think from very early on I’ve been involved in transformation and change, and then as an HR Director transitioning into Thales, where we worked together for many years, genuine pleasure Jason I can say that officially on record, generally was a good time actually I think we worked on classically dynamic growing business. But that took a lot of effort and work; a lot of it was organic, some of it was through acquisition, and I think the organic stuff was really interesting around my side – maritime services – and again international work, unifying management leadership teams, and then below that, optimising and unifying structures looking at the operating models.

So all of that gave me an interest more in programmes and change management; I realised that was really what I wanted to do. So from there onto the carrier, into a bunker as you described, it literally was a little bit like that, as we were going through concept and development phase of that programme and left that to set up the campus at Crawley for a couple of years. And then from there into transformation with Thales at the corporate level looking after the portfolio; and then from there it was a fantastic platform for working with a number of clients in multi industries ,and that’s what I’ve been doing ever since.

So yeah, I’m very interested to talk about this topic with you, from for my practical perspective.

Jason West: What was it like making that transition from operational HR director to transformation lead?

Nick Ranier: I think that’s a really great question, because as an operational HR you’re in the function, leading a function, normally that needs to change itself, so whilst you’ve got a transformation oversight role, really you’re more concerned about making sure your organization balances its business continuity and delivery and service delivery, with that of the transformation needs. Therefore, as an operational HR leader or indeed any operational leader – and I’m sure we’ll talk about that in the course of this this discussion – switching to transformation, all of a sudden you’re the person having to offer that framework to the organisation in which they manage that balance.

I think the other dimension that you need to really be aware, of course, is the strategic one: the goals that you trying to achieve are normally from multi centric, as in multi programme, perspective not just the single large single programmes, but all of the bits they add up to. Making sure, also, in that agenda you look at the culture and how that evolves, and develops in line with what you want to do operationally and strategically. So I think this really is all about frameworks, and guidance, and stakeholder management, and facilitating the governance. Within the function, it’s about delivering and owning all of those changes and benefits.

Jason West: One thing I’m particularly keen to understand, really, is your perspective coming at this more from the overarching portfolio level. So we’ve done a lot of work at programme level, and making significant change happen within individual functions. And the scoping checklists that we created is very much written from that programme perspective; the target audience are kind of HR, finance, procurement leaders that need to transform their functions. But obviously, what we’re not really covering in that is that portfolio view, so I’m really keen to see where the similarities are, where the differences are. So as we kind of delve into the checklist, we did start with what we thought was the most important thing, which is sponsorship – so executive sponsorship of the change – and we’ve seen lots of issues in sponsorship in various programmes. But when it works, it’s fantastic, it makes everybody’s life easier. I was really keen to understand what your perspectives were on sponsorship; what makes an effective sponsor? And what are the sorts of things that people should avoid?

Nick Ranier: So in sponsorship they obviously own the business case, and the key to good sponsorship is that these individuals are available to the programme. I think there are examples of sponsors, and you may see them at state steering group meetings, and that’s basically their intervention. But I think what you want from a sponsor is that availability, that ownership, and also that they are prepared to actually go to the level of the organisation that requires some interrogation. So if there are problems issues, they actually they take the time out just to dip into that. Just sitting in a steering group occasionally, reading reports and making judgements is OK, okay but the active sponsors is really what you’re looking for, the actively engaged sponsor.

Jason West: And is there is there a difference if somebody is sponsoring an overarching transformation portfolio, if they are the executive sponsor which you would assumed would almost certainly be the CEO, maybe the CEO in certain cases, but does that require different things at the portfolio level?

Nick Ranier: It does. Each programme will have its own steering group, it’s a suggestion, you don’t have to do it like this, and there are options but normally within the programme you’d have your own gates, your own process, and your own steering group, which is fine. If that is the major moving element in the organisation at a given time, then that’s absolutely fine. But I think normally, and within the company are currently with, for example, an energy business, has, I think, 700 programmes operating at the moment. Now, I’m not suggesting that any one person could understand the dependencies associated with that. But what I think most prudent businesses need to do as part of their governance, is just on a piece of paper, and it can be done, is plotting the value chain on the horizontal – it could be simple, so it’s just inbound logistics, operations outbound logistics services, and then placing your MD and sales, and marketing efforts, and development efforts, as well into that plot line and then draw the businesses down the vertical. And just make a little note of where they’re active on that on that value chain. And I think then you can see it at a glance. So, for example, HR is normally tinkering with capability, they are normally transforming themselves. Procurement will always be doing something around key commodities, sourcing new products for new markets, whatever it might be; there will be some maybe some new concept, work new development, where new services development work which is a hybrid between business as usual.

But there’s a transformation element to it, which is to say that the business in its current configuration, with its current resources, would not be able to deliver that change, so you need additional resources, additional effort, and it has all the components for a transformation of strategy operating model and culture. If it’s just a simple change, then I probably for simplicity wouldn’t track at that level, but obviously you have to track at some level. So I’m talking at you, but essentially what I’m trying to describe is a plan on a page. And you can give some maturity to those, so for example, if you’re doing work in production with the operating model – you’re introducing an ERP elements or improved material flow element – just mark that on the chain on the map. If that then extends into distribution and into services, then continue to draw that line, so that you can see the extent of the operating model and the business model and you can see the significance of all of all the changes worked together. And then you get a sense of what’s going on in the business, what’s the cadence of all that is, what it’s all adding up to, and how your programme fits into that context, and what it’s adding to those other programmes as an enabler. And what it’s adding to the strategic vision. So what I’ve just described sounds really complicated, but it’s not. Once you’ve got that piece of paper, you just need somebody – a portfolio lead or a responsible executive – somebody that could do that work from the programmatic perspective; pulling that information together and having that discussion with the board on a regular basis, making sure that those strategic dependencies and that direction of travel is managed.

Jason West: Yes, so just having that real clarity of where we’re going, where the value is in this business, what we’re doing to improve it, and how all the different moving parts do actually fit together.

Nick Ranier: If they do. Sometimes they conflict of course. If you’ve got restructuring in one part of business or you’re needing to optimise certain aspects, and yet you’re expected to grow and develop services in certain markets. There’s always challenges and there’s debate and arbitration required and that’s really where the executive board and the CEO needs to step back and decide what slows down, what speeds up, what drops off, and what comes in. And that should actually be moving, actually should be a dynamic. If you’re looking at the same thing, month in month out over a year, you’re probably not having the right conversations.

Jason West: Yes, and I guess one of the challenges for a sponsor at portfolio level is the arbitration, as you mentioned, but if they get sucked into too much of the detail of individual programmes, they could end up stepping on the toes of the executive sponsors of those programmes getting too much into the detail.

Nick Ranier: And that’s why, sometimes, you do want your sponsor, as senior as they are, to dip into their own programmes, to understands certain levels of detail. I’m not suggesting they sort out every conflict of priority, and resource issue. But they do sort out issues where, for example, some businesses that are pilot organisations aren’t ready, or are not making progress towards readiness. So business readiness is a key component of all this, to make sure that they can undertake whatever they are expected to do, and that should be facilitated by the sponsor. Normally a programme manager has seniority, has influence, but really the call needs to be made by the sponsor who is actually engaging with the pilot business and actually facilitating them to allocate the necessary resources and effort to make it happen as it should. Test whatever’s going on, whatever you need to test in terms of “is it successful? Does it need adjustment” Then you’re ready for a larger, wide scale deployment, at that point the exact board would get involved, certainly, when you’ve got a multi geography, multi business line, they would just need to make sure “are we ready and what other things might that impact, or effect, in terms of the year? And for the business sales and financials? And also, the other transformation efforts?”

Jason West: Yeah, all those resource requirements for making all this change happen at once, making sure you don’t damage business as usual as you’ve got multiple programmes trying to get various new systems and processes live.

Nick Ranier: Absolutely, and the business rightly so should always (well there’s different differing view about this) but my view is the business always has the priority. So, if there’s a critical business delivery, it always has priority over the change and transformation. It’s not unusual to see steps taken to reverse that, but I think it has a detrimental effect: it creates almost dis-benefits to check for the changes you’re trying to create. It harms the branding of that development, or product. The business has to make the call, but they just need to have and articulate the right reasons for any delays or changes or issues.

Jason West: It’s interesting that you touched on that real active sponsorship, and it’s something we very much advocate, especially when you’re looking at “What’s the actual problem we’re trying to fix with this transformation? You’ve got your exec sponsor, but do we agree that this is a problem that’s worth fixing? And how do we actually go about defining that problem before we rush into solution design?” So I’m interested in your perspective on the sorts of approaches or tools that you’ve seen work around that kind of problem definition space.

Nick Ranier: So certainly, it starts off with a sense that something is not great or not optimised, and I think then all of a sudden people then start to dive in to try and start to define that problem. And I think that the team that does that work, the capability of that team is important. So if there’s a problem within a functioning, procurement for example, recognise their benchmarks and parametrics aren’t where they should be, or they feel they should be making a greater contribution to working capital or to the margin, so they will then start their investigation. But I’d say in terms of that phase, the business analyst role is really key. I know it seems like a strange thing to say, but there are lots of views that are circulating around about what the problem is, and very often those views are diluted by the lack of data and information. So having fantastic BAs [business analysts] who are engaged and fantastic at what they do, who own it, literally, what they’re trying to resolve, and then constantly feed that information into a sponsor, who then feeds into colleagues, and that then gets tested and adjusted. And whilst we do need speed, it needs to be done properly, because then everything builds on the back of what you think is wrong and what needs to happen. So like I say, my learning has been to get the best business analyst you can on the job. You don’t need a lot of them, I’m not talking about armies of business analysts, just based on the scope and the scale, resource it commensurately with great people.

Jason West: Really great business analysts are very hard to find. A rare commodity.

Nick Ranier: They are, because they answer very precise questions normally. And what you want is somebody, who him or herself, is challenging what you think the problem is, and taking potentially a slightly different perspective on it. But a perspective with data, with information, with insight that’s been gathered from leaders and staff alike.

Jason West: Yes, and that piece on data and insights – you mentioned benchmarking – have you have you found that’s being useful as you been defining problems? And where do you go for that sort of benchmarking data?

Nick Ranier: If you pitch up without the benchmark you’re going to be sent away again to get some (I think you will know that from your own experience). And again the benchmark data can come from a range of courses, I remember certainly expert HR, Saratoga, so there are a few reference points and benchmark providers out there. But those listening to this podcast within their own functions or businesses, will know for their industry or sector who they are.  I’d stop short, perhaps, of using the consultants associated with that data – you don’t need to do that – you just need to draw on the database, there’s no strings because you should be able to do the analysis for yourself.

Jason West: Absolutely. The key thing is getting access to the data, as you say.

Nick Ranier: It really is. Very often you can do some peer work with people from other industries and so casually ask the questions, but really it’s best to use verified data. Compare and contrast that with your current state and direction of travel and look at the gap you’re trying to close

Jason West: It tends to be essential to getting funding for the rest of the scoping project, actually being able to say “we’re here against the global benchmark, and now we’re at twenty five 25th percentile now, if we got to average then there’s X million on the table, can we have a bit more cash to figure out the next stage?”

Nick Ranier: People shy away from, because normally you do the benchmarks and the FTE ratios are where a lot of people start. And I remember when we were starting to look at those in Thales, for example, they weren’t great (it’s significantly better now, probably) but at the time we were saying “do we really want to say this? Do we really want to say that’s what we’re running? And with the best in class are running live in terms of the FTEs or is it the effort of the organisation’s objectives your sales or whatever?” You have to gird your loins, if you don’t mind me saying that, and then just say it just say it is.

Jason West: Yeah, and we’re back to sponsorship; having those hard conversations.

Nick Ranier: It is and they will shape the case around that in a way that makes most sense for consumption by the executives, and then it gets into further shape, of course, for approvals. But it just needs to go through that maturity – doing the internal checks, getting of you on that, comparing the benchmarks, getting your view on that, shaping the case of the gap, and where it potentially would need to go. Shaping that and then crystallising it into a business case. You don’t just dive straight into business case; actually taking time to gather evidence, and socialising it and checking it at every stage.

Because going straight to the business case is normally just too big a surprise for the organisation to handle. All of a sudden you appear out of nowhere and say “we need five billion, it looks like this, we think we’re going to get these benefits.” And of course, it’s too much. So you need to just carry people with you as you go.

Jason West: One of the areas that we find we get quite a lot of push back – to your point on that requirements gathering piece – is where you’ve got a function, and it doesn’t matter if it’s finance, IT, procurement, HR, they all tend to be really quite resistant to engaging people outside of their function, and engaging people close to the customer, and the revenue stream. And our own perspective is if you’ve not really engaged a diverse group of people, you’re not actually going to properly understand the problem you’re trying to solve, and there could be some pretty serious gaps. I don’t know if you found that in in other places and other programmes and what you might have done to overcome that sort of resistance?

Nick Ranier: Really transformational change is actually, at its heart, a reconfiguration of power. Therefore, every time you have these conversations the bulbs are flashing in somebody’s head about “what does it mean for me? In my department? In my team?” So that’s the first filter that you’re getting. And then the second filter that I find is that the people who asked the questions are asking functional requirement questions, and they’re getting functional requirement answers. So that person said: “I don’t care what you do with it, but it must print to that printer” or something like that which is a functional requirement. So what you’re looking for is a business requirement. And if you have business requirements, try and deal with the upfront with the power issues, by the way that you present and introduce your session; say “this is very much an exploration. Nothing has been decided. We know we’ve got these problems in the organization. I think we’re seeing it as very much the collaborative effort to fix it etc.” So those are things that you can say just to ‘soothe the brow.’ You then start asking business questions and expecting business requirement answers, and I think that’s key. If it’s a new CRM solution, then the way you articulate your growth plans and ambitions into which markets, with which products, in which services and therefore the CRM solution needs to capture a certain pipeline, in a certain way to give you this information.

That feeds this prospecting chain of events, from business development, through to marketing, through to the sale. I think that’s a very structured business conversation to have. What you don’t want to do is talk about touch reports that they’re going to get or mention again the colours of the pie charts. But it can happen; you see it all the time, hundreds of functional requirements. Then from the business requirement that will then allow you to source ideally something that, if it’s not out the box, it will be relatively close to it. Because as soon as you get into a high level of functional requirements and certain levels of detail, all of a sudden you’re into a customised product and then you’re in a whole world of trouble, regarding just getting a minimum viable proposition out the door. So just starting to work with something very quickly, and then working in agile sprints, whatever you do to then upgrade and evolve the product through phases and over time, that’s probably the way to go about it. Again, based on what value it’s giving to the business in this kind of current configuration and white increased value you could get from enhancements and changes based on that business value question.

Jason West: Yeah, we talk about it in terms of capability requirements. I’m assuming this is analogous to your definition of business requirements, in that a capability requirement can actually be a requirement for system functionality. But it could equally be requirements around changes to the capability of people, the operating model, it could be about process, it could be about policy, and actually restructuring your requirements gathering sessions so that you are capturing that broad sweep of “these are the capabilities we need to deliver to the customer,” whoever the customer might be. Not limiting it just to the technology functional requirements.

Nick Ranier: Indeed. I can certainly understand the capability question and I think especially when you’re in HR information space, there are limited options, there always have been. And when I was at one client they went through this process in which they were reconciling their global headcount numbers, for example, using spreadsheets. But this is a company that’s growing 10-15% a year, so there are successful business, but sometimes as we all know, you have to talk about the capability that gives us a consolidated report or automatically produces a consolidated report from all of the regions, and you have to talk about some of those things. So while obviously it doesn’t directly align to a business strategy or benefit, obviously there is benefit to the fact that you have that reporting available, and you can then leverage it for whatever purposes you wish to. So there was a lot of detail that was discussed, but then it did get a little bit over-egged, frankly, and I think there does come a point where you just need to you do draw your line, you get specialists in, then you start to do your contest to decide “okay, what solution then gives us or  delivers those business requirements, organizationally and systemically?” And then you that’s when you should start to get into that second level of detail.

Jason West: Yes; something that we found over the years is whenever you go out, and you engage the business, you do get a huge amount of requirements; hundreds of requirements. Because often it’s the first time anybody has turned up and said “what do you think? What do you want? What do you need?” And you actually have too many, and if you were to accept them all you’d end up with a programme that last years and years and years (and they last years anyway but you know it would be 10s of years). So we found that, actually, there’s some really important decisions that you have to make during the scoping phase, about what to accept in scope and when you’re going to accept it in: is it phase one? Is it phase two? Is it phase three? And we’ll get more into this, I’m sure, as we discuss and governance, but actually putting some real design rigor and real thinking behind: which one of these are we going to accept? Because not every requirement is valid. A former colleague described it as a “penny in a slot.” Everyone’s got a penny and everyone has their requirement, but they’re not all valid.

Nick Ranier: Yes, and they all feel obliged to spend their penny, of course, because they see that is as important demonstration of their contribution, of their commitments. So they make a point for point’s sake sometimes (that’s, perhaps, slightly unfair).

Jason West: But I’m sure it happens, I’m sure it happens. We’re going to switch gear slightly, and we’re going to talk about change. Because we’ve both held operational roles in the past, and there’s been far too many occasions when the first you hear about something is an email saying; “you must turn up to mandatory training for this new system/process.” Group said; and it’s always group’s fault. And then as a lowly user, or as a manager or director in a business unit somewhere, you just get told you have got to go to training. So we come with those scars on our backs, and we’ve experience the message that says; “good news, we’re rolling out tomorrow, you might get some training if you’re lucky.” But what we’ve found is that doesn’t actually work that well. The result tends to be people don’t adopt new systems, or they do it grudgingly, and badly and you can end up with all sorts of policy breaches and just people ignoring stuff or using back office work arounds. We’ve always advocated for really preparing for change right up front; so assume that your transformation programme is going to get approved and you need to start some work on your change management, before you actually start implementation as part of the scoping. I’m just keen to get your perspective, as somebody that’s worked extensively in change. Is there a preferred approach? What’s the minimum requirement you’d see as that change readiness, before you actually get to finally signing the business case off and getting started?

Nick Ranier: Broadly speaking, you’ve listed in your really insightful document some of them; you’ve listed Lewin and unfreeze and refreeze, so you’ve got the three steps of Lewin. You’ve got Kotter in there as well, and you’ve talked ADKAR as well which is the Prosci, a commercial solution that’s very popular. But what they are all talking to though is these phases; so at the highest level you’ve got a “design, develop, and deliver” type technical process going on. Underneath that, you need to complement and integrate into that an “embrace, adopt, and sustain” cycle. So when you talk about embrace and adopt, while the development is going on, that’s when you really, theoretically, should be doing your first engagements. Sometimes there’s sensitivity in transformation around change; if you’re designing a restructure or an operating model, and obviously you’re working with leadership, be you might not necessarily be working with the wider organisation, because you’re setting hares running. The changes and adjustments that will come out are real, and as I said before, it’s a reconfiguration of power, and indeed there may be other consequences that we all know all too well about. But let’s imagine it’s a development and deployment of something like Cooper in procurement, which is in direct materials, or its Workday or SuccessFactors, whatever it might be; ideally once you’ve got the business case successfully signed off and approval for the resources, and a plan, then you would start your early engagement.

Senior leaders, and probably selected managers, are already aware of what’s going on because they’ve been consulted and discussed, and they’ve been engage with. But in terms of the wider workforce, the impacted communities, you then start definitely need to start to talk to them about the direction of travel, the time scales, the type of help and support they are going to need and what they are going get to manage the transition. In parallel with that, frankly, just before that I always like to do a high-level change impact assessment as well. So you look across the impact on the community, you see where the most impacts are going to be, what capability is changing, what does the headcount profile look like in different parts of the process or geographies involved? Do we need to consolidate activities? Do we need to federate activities? All of that change impact then moves into a change action plan; this is classic stuff, but important to do. And often forgotten. And then you also align to change action plan; the comms plan will then be guided, and influenced, and informed by that change action plan. So where there is sensitivity within certain communities, then you should be aware of that, and that doesn’t stop you doing anything; you have to go and be transparent, talk to them about changes, what that means, and how they’ll be helped and supported through that process.

You’re doing so you do you change management, and of course, all of this is basically communication updates, engagement updates, managing FAQ; all classic stuff. I think the bigger the change, the bigger the story needs to be: the more people impacted, the more story you need, and less technical detail, because it’s the only way you can touch hundreds, sometimes thousands, of people. The comms are essential, and having a fantastic comms person to help you with that as well. Again, a bit like business analyst roles; a great comms person will absolutely transform your transformation. Use the channels of your business; so where I currently am (Shell) they like they use Yammer a lot. So Yammer is a social network, an internal social network, and you’re encouraged to join. I’m a member, but I’ve only been there four months, and I’m the member of about 25 communities. So it is really hard, it’s a tricky thing to onboard actually, but that’s the way they do it. And the Yammer channels are a major communication tool, we also use Skype for business, so you can reach out to individuals, teams or groups on that, and people are pinging you all the time. And it’s just a way of working, and all companies will be moving in this direction, particularly as the millennials come into the workplace, and takeover more senior roles; you see this kind of internal social engagement revolution going on quite rapidly now.

Jason West: I think the key thing there is: it’s a conversation.

Nick Ranier: Yes, and through whatever channels you use. And don’t let geography get in the way of that conversation. If  the channel is helping facilitating that, then fine.  If it is not then get it done face to face.

Jason West: And it’s at least that true, two way communication, rather than just emailing people or just pushing messages.

Nick Ranier: Again, large scale change is tricky business and that’s why you need a great comms person who gathers together the themes, grabs those things and provides responses to those things. And make sure, actually, that change community, because that’s their job while the technical team get on with the product development and deployment, the change community’s job is to onboard all of these points, that are emerging from the impact on communities, where possible, and actually addressing those points and concerns. Then finally you go for through cycle, then finally, you get into “are you ready to onboard the changes?” So we need to do some training, we need to do some piloting with early adopters, whatever it looks like, all of that needs to be done. You need help people to help you through UAT, the testing phase. So all of those elements then you need targeted comms while you’re dealing with the impact community. There’s always a few within that impact community that needs to be accelerated through, because they’re the ones that do the testing, that do the early adoption, that test our checklist solution for validity, gives the confirmations to the leaders, who then gives affirmation that they’re happy that this is the right thing for the business to do, and that they will onboard it. So you’re doing that early engagement, and all the rest of it with those super users and testing communities, getting leadership affirmation on readiness and then you can start your major training, and then follow through into the go live preparations. Go live cutovers, and whatever you call hypercare support, whatever it looks like; just making sure that’s meaningful, so change has a role. Sometimes it’s good to step back in the hypercare phase, and make sure it’s sustained, and really lean into that fate.

Jason West: Yeah, absolutely. I think that gives an excellent overview of all of the things that you really have to think about and plan for as you’re scoping this out. This isn’t something that just waits until the end when you have to train people, it really brings it to life, so thank you for that.

Nick Ranier: Well, that’s where I live everyday, in fact just today, I was disappointing some people with some training they hadn’t heard about or realised. So we all get caught out, and I was doing what I just said not to do. I’m literally reaching out on Skype at the moment, and making apologies and frankly recovering that situation, making them feel good about it. We’ve pushed back training by a couple of weeks, and we’re talking to sponsors and execs while we’re doing it and we’ll get it right

If you know you’ve screwed up, then carry on with the screw up. Just stop, take a breath, it’s okay. Ask for permission, unless it’s really desperate, in that it’s an event that has to happen because of certain arrangements. Take that breath, take the time out, get it right and then go again.

[Intermission]

Jason West: Before we move on from the broad topic of methodology. I’m keen to get your perspective of project, programme, portfolio methodology. It’s something that we focused on in the checklist, because there’s a real misunderstanding, I think, within a lot of functions; in finance, HR procurement, less so in IT because they have been leading these sorts of things for quite some time.

Nick Ranier: Weak on the change though, great at the technical development, fantastic. But the change management is still here still weak so it’s this integrated nature of things that’s challenging.

Jason West: Yeah. We’ve found that just describing what is a project, what is a programme and what’s a portfolio, and the differences between those three things and how they actually all link up together, has been a bit of an eye opener for quite a few people that have been actually sponsors for years on these things, but not really fully aware of exactly what it was they were sponsoring, and what the different accountabilities were. I’m keen to get your view, and you shared it already on the IT side, but how effective are functions in actually employing these sorts of methodologies? And if there’s a gap, what could be done about it?

Nick Ranier: I think everybody would agree that functions, generally, will avoid any kind of tool or framework, they basically rely on a calendar and some basic Excel, and just go were marching off towards the light, as they see it. The way that we provide a framework to businesses is quite important, and normally within themselves, they are not going to do it. So you actually have to be managing outside of the function that’s undergoing the change, or the business undergoing the change, or the organisation or the corporation that’s undergoing the change, be outside of it. I think that there is definitely a case for managing a light type of programme management organisation; if you’re running multiple programmes e.g. if you’ve got an SAP running, you’ve got operating model change running, you’ve got a sale sales transformation programme running, some product development going on, footprint consolidation; all of these different things – that’s a portfolio. You’ve got all these very different things happening, which is back to my original point of put them on a bit of paper, so you can understand that withing these two sites, one site is  going to close, another site is going consolidate, so you don’t bother deploying an ERP to it in three years’ time because there’s going to be nobody there. These basic things sometimes get ignored. That’s the portfolio elements. And within each of these, as I said if you bring an ERP or procurement programme, the programme itself is the sum of the different paths that would need to change within a function. So if procurement are doing some capability changes, there are onboarding a direct sourcing tool or whatever it might be, a component of an ERP, SAP for example on the purchase to pay; those changes would be the programme and the projects are those individual workstreams. And what you would need is some somebody just sat outside, just doing a light version of programme management. So, there’s more and more aversion to managing programmes, I have to say, people are not welcoming or onboarding methodology, they are actually receive increasingly resisting methodology.

So, I think so it’s got to be the lightest form you can make it. I’m MSP qualified, management portfolio qualified, but it’s very rare, if ever, that I deploy a full MSP suite. They do it in defence, with the consequences that they’re trying to manage an unmanageable baseline of things. I’ve got all these schedules of risk and dependencies, and the issues log, and the actions log, and the schedule and they’ve got all of these acting out the resource profile, the work breakdown, organisation breakdown. Trying to manage this baseline of things; can you imagine? But most organisations are totally resistant to that. So it’s basically, you need to schedule, you need some basic management of risks, issues, and dependencies; sometimes it’s called a RAID (risks, actions, issues and dependencies; or sometimes its risks, assumptions, issues and dependencies) the blend can change depending on what an organisation would like to focus on. But certainly having an idea of the schedule and reporting the schedule, and associated risks, is still an important thing to do. How an organisation uses that, so for example if you’re going through an HR transformation and they’re doing a reorganisation or onboarding a new system, and doing some consolidation of support services, or customer services, that management, as you know better than I do, was done for all of those customer groups. And you just need a representative from the business working with you in the team, normally on a shared job basis, and they would then carry back the schedule messages, the risk messages, and the various things that need to be managed through communication, and the natural meeting cycle within the business. You don’t walk around with the schedule bashing people over the head with a rolled up piece of paper.

Jason West: I must admit, I similarly did an MSP qualification and kind of went “I’ve now got some language to explain everything that we’ve been doing for the past five years. This is kind of fascinating.” But actually, if we did all of this week need an army; we’d need to have an army of planners and schedulers; we’d have to have project managers everywhere, and life just, unfortunately, isn’t quite like that. It’s interesting; people are kind of resistant to it. If you’re building up a £2 billion aircraft carrier, I’m sure it’s brilliant, but it’s a real challenge if you’re transforming a function. It’s got to be appropriate hasn’t it.

Nick Ranier: Absolutely. If you’re building a physical asset or a product it lends itself much more to detailed planning, than it would for transformation and change, because of the dynamic nature of what you’re trying to change. For something physical, once you’ve got your design, your bill of materials, resource profile you could basically get on with that production, can you get on with it. But of course organisational change doesn’t start with cut steel. It starts with communication, with people about what’s changing and all of that emotion and feedback coming in.

Jason West: Yes; I do remember talking to some programme managers in the defence space explaining our requirements are going to start off really small, and then get bigger and bigger and bigger as we go through the programme, we are just going to uncover more stuff we don’t understand yet; we don’t even know we don’t know it. And the look of horror on their faces.

Nick Ranier: But you have a job. So, the organisation has gone through the process we talked about earlier on; it’s decided on a case for change, is committed to that case for change. In that process, hopefully, the people you talk to have been involved. But I think a key service to them, is something I call “weak signals.” So, I think within all of this panoply of tools and methods, at the heart of it you just need to make sure that a weak signal of an issue – so there’s potential industrial relations issue there, or there might be a design problem there, or our current infrastructure won’t be able to support this performance or the required performance of the system, whatever it looks like – there will be a point in time where an issue or risk emerges, and then your experience then comes to the fore.

You start talking to your sponsors, stakeholders, impacted communities about that “weak signal,” about how it could grow. And I think getting them engaged on things that are not tomorrow’s issues, but I think having those conversations about the look ahead is really important. That’s actually good and sensible programme planning. I think what’s very frustrating for businesses is that, despite all of this effort, they’re constantly being surprised. Things are constantly changing at the last minute, things aren’t declared until everybody knows that is not the case anymore, e.g. “we’re going to go live next week,” and everybody knows it’s not going to happen. So what is planning all about then, if you’re constantly disappointing us, telling us things that don’t seem to be the case?

So having those forward looking conversations around very simple schedule topics, but talking to them about particular issues or points they need to be aware of within their area, that if we can tackle them now won’t be an issue in three months’ time, but they will be if we don’t deal with them.

Jason West: It is an interesting one, because there’s the balance between structure and plan, versus creative problem solving is probably more towards the end of creative problem solving in the transformation. But if you don’t have the schedule, and plan, and the structure; if you have none, then if the problems are too big, too complex to actually manage.

Nick Ranier: Yeah it’s the balance; not being a project manager who’s driving something just because the book says that it should be driven. That’s just not going to work.

Jason West: It’s that difference between project managers and programme managers, they are different breeds. One can become the other, but there’s a fundamental difference between them.

Nick Ranier: And there’s a role for both. Just assign the right type of person to the right type of project or programme. If it’s very crystal clear, monocentric delivery, as in one thing with no particular major influences that you can deliver, then a certain type of programme or project manager will actually drive that and get that over the line. But certainly, where there are dimensions of culture and process changes in strategy, problem solving, creativity, conversations all the time around schedule.

Jason West: Yes, and a huge amount of influencing and emotional intelligence, and getting people to do stuff they don’t actually really want to do.

Nick Ranier: I don’t know if there are people screaming at the device they’re listening to this on, saying “you need it, it needs to be a lifeblood of programmes” and I couldn’t disagree. But so often, they’re not telling us exactly what is happening. So as long as they’re not so sophisticated, that we’re able to tell the right story, at the right time, then that’s task schedule.

Jason West: Have a schedule, but don’t over engineering it. Recognise that is has its limitations and that there’s plenty of grey area.

Let’s again switch gears slightly and think about the endpoint; so actually working with the with the senior leadership team of the function, or in fact the enterprise at the portfolio level, to really define what is our vision? What does that destination look like? How are we going to describe it? And what are those milestones along the way, those key objectives? And then the design principles that are going to keep us on track? What does a good vision look like? And where have you seen things go off track if vision, objectives, and design principles haven’t perhaps been thought about as effectively as they could have been?

Nick Ranier: So my preference, really, is to work with the strategy, I have to say. The vision statement is a bold statement of intent, but I think when you start to look at the strategy, as in; “we want to grow in the South American market by 10% in the next two years, in this product or service.” That’s the strategic objective, and I think you can start and some of that will be delivered through business as usual, and the elements. And already, when you’re doing your strategic planning you can start to get a sense of what won’t be delivered through business as usual, and if it won’t be delivered through business as usual, then how do you bring that additional capability and resource to the business, or an additional service that it needs? So that would be step one. I think that within the strategic planning process there should always be a review of what can be achieved, as I say, by existing resources, and additional services, and then start to work through that additional piece as a potential change management plan. I do take your point about alignment to the vision, but it’s just when you’ve got these strategic objectives, at least normally, there’s an element of measurement associated with the service, or there should be. So you’ve at least got a reference point for your programme, so you can actually say “based on the current path for sales, we’re going to reach 80% of that target, and not in that market and therefore what does other 20% look like? Is it additional business development resource? Or is it the fact that we haven’t got the right products or services now? Or is it that the sales team isn’t big enough, or is having trouble engaging? It is not right it’s not integrated, not nationalised enough for that market?”

Whatever that looks like, you would need to introduce that as a change management. Now, the sum of all these bits, so preferably doing the same thing as finance, and HR and operations, that they will be doing the same thing. I think those gaps in terms of their strategic ambitions would then start to form the bedrock for your change management plan on a page. You get your plan on a page, and then from that you would then start; some things will already be in motion within the function. I guarantee it. If they’re making progress, then that’s fine but if they are not making the progress then probably needs to back the structure of the framework, I talked about, and so step in and lean into that. Offer them the framework about how you start to really properly design out the changes they want to make, how you compliment that with the change management effort required to deliver that, and then start that journey. And then before approval, just check it against the other things that are going on; make sure there’s no clashes of timing, cost, or dependencies. All of the functions will have two or three year plans, hopefully baked into budgets.

One of elegant way to do it, I think we saw this as well in Thales, certainly with other companies, is that you have this sun chart in the top right of the page which describes what we’re trying to achieve for the business. Then then there’s another layer of around the sun chart which has the metrics contributing to that vision by function, and then you have the kind of shafts of light emerged. Withing each shaft of light, a function is describing its journey as two or three years is getting along time for transformation. Now, most companies have got the appetite for one or two years so let’s imagine it’s a couple of years and we show really strong benefits in year one as well. So those charts are quite practical programmes and projects and you got the second layer which is talking about making sure that the all of the benefits are recognised, and measured, and tracked, and then all of that hopefully will add up to this glorious brightly lit vision.

Jason West: I have to remember what those charts are called; they have a name.

Nick Ranier: I don’t know I just called him sun ray charts. Pictures are definitely really useful and again, such a good communication tool; good if you’re able to share it. And sometimes you can’t because some of those elements on the chart of are sensitive, some elements are very much within the domain of leadership and that needs to be managed in collaborated and delivered in that way. But it does help and inform how to define the messages, the coherence of the messages across the business. They don’t want 15 different messages of each of these sun rays, they want the combined message of what’s happening around the business and impact on communities. Then obviously, within each of those rays of light would then need to be worked with as we’ve just described in a specific session.

Jason West: Right, so you’ve set your vision. You’ve got your nice sun ray charts; whatever it looks. You know where you’re going and what the plan is to get there; that kind of high level plans.

Nick Ranier: Yep, so which sponsor sits where, which resources are allocated. What they’re heading towards, things that they need to be aware of, colleagues they need to make sure they keep in touch with and contact with to manage dependencies. You’ve got a portfolio managing the whole, you’ve got programme managers managing the parts, you’ve got project managers managing the individual deliverables. Transformation and change can be something of an industry, and it’s just that the care is required to make sure it’s not overcomplicated, people aren’t overburdened, and that the cadence of all of this is such that the business can get on board with what is coming towards them.

Jason West: And that brings us neatly on to how you structure your decision making around all of that. How do you govern that that complexity, that industry of change that’s going on?

Nick Ranier: So back to my point about strategic objectives; every business is already running some kind of – well, not just business I’m not just talk about commercialism, but government as well – but they all should be running governance bodies. They will be governance bodies looking at enterprise risk, governance bodies that are looking at the organisation of design, roles and responsibilities of directors, the various committees that are operating will have mandates – they need to be looked over. There will be governance bodies governance sitting on these, and then in terms of people, there’s performance and reward; there’s the compensation committees. And then lastly, of course, there’s policies, procedures, and processes that run within maybe the quality team, but not only there, and they’re making sure there is good governance and process around the way the policies and processes change and adjust.

So that’s business as usual. Then all of the sudden, you’re adding into that mix, all of this transformation governance. My advice, always, is back to your plan on the page, regarding what’s changing in the business. There’s obviously a plan on the page for what’s happening as business as usual. And then sitting above the two parts, there should be all of those committees; they should be discussing these at the same time. So within your risk committee they should be discussing the daily business risks, of how the operation is running. But also, they should be discussing the transformation risks, within people in the organisation, within the process and policy committees. Whatever those structures look like, that review and do the oversight, they should integrate as much as possible the transformation efforts coherently into that discussion.

So I’m being idealistic there, because I know obviously not all companies can do that;  some of your SMEs and smaller business customers will be saying “come on, get real. Do you think we need to deal with that.” But what I would say to them is; you will be looking at all those parts as some point in your governance and management cycle, and in that same meeting, in that same forum, ideally, you would introduce the notion that things are changing. What are the impacts on the things that you’re discussing as part of your business as usual? So you may do them all once a month in the management committee, maybe do all of those things once a month in 20 minutes at the end of the meeting. But you should also have 20 minutes in that meetings to talk about transformation, and then the meaningful impacts and effects on continuity, and also future plans and changes.

Jason West: It’s a fascinating idea, actually. Because in a world where everything is changing faster, then how can you not integrate these transformation governance until into business as usual. Does business as usual exists?

Nick Ranier: Business as usual exists, as long as you understand the scope of business as usual. It includes business that will change, as long as you’ve got that in your head: that your oversight is over the whole effort of the business, in that things that people are trying to make changes within, and also the things that were just trying to do on a daily basis. It just makes practical sense, because we’re so overloaded and overburdened with transformation, generally speaking. And we always complain about it, saying “did they make that decision yet? No, it’s next hopefully the next steerco.” And you have to wait another two, three, or four weeks and it can be frustrating. But as soon as you use the natural cycle of the business, carve out some time, and you’ve got leaders that understand that they need to protect time for these subjects, and discussions, you’ve got a chance of a coherent decision being taken.

Or you can run it on its own, in a dark corner, of course, as the sponsor. Which happens, and you can make progress in that way, but there are consequences to that. I just think that certainly, as you move towards readiness, you should start to integrate the conversation; certainly at that point if, not before.

Jason West: That’s really interesting.

Nick Ranier: I think that’s going to be people screaming “get real.” I think it’s always important to say in this complicated world with this 4th industrial age upon us, where we’re just getting used the 3rd age, where everything was connected within ourselves; now, everyone is connected beyond ourselves. So all of those influences tipping into the business, customers able to engage directly with business, change requirements in a heartbeat. You’ve just got to work with the cadence of natural increase, and manage the consequences of a flawed deployment.

Jason West: So, the governance is going to be there making a set of decisions on things: products, solutions that the programmes are putting up for review and approval. Hopefully you’re not pushing all of that stuff up to the executive steering committee, otherwise it’s probably going to take you some time to get things approved. But the actual process, the capability to design solutions, is something that often ends up falling to really good operational managers. So when you go in to these transformation programmes, you’re often just setting up process ownership for the first time and introducing that as a concept. Hopefully not, hopefully that does exist. But generally, something that we have found is that one of the biggest challenges is that you need to take people who are excellent at executing operation plans, and then having to get them to change their mindset to architecting, to designing, to thinking a bit like a system engineer, about how if you change this one thing over there it affects something else. It’s really working through the consequences of that. And it’s something that we’ve found is a significant risk to a lot of programmes, is the key people that need to make those decisions are actually not all that well placed. Because they don’t have the experience, the knowledge, or the skills to do it. So if you could have a magic wand and we could kind of sheep dip people through this development programme, or this training, or whatever it’s going to be, what are those core things you would hope that your process owners, you design leads, would have? What can we do as a transformation practitioners to make our own lives easier, but also to make the transformations that we run more successful?

Nick Ranier: Again, I come to the bitter conclusion that the internal subject matter experts, for want of a better term, because these are the people that you’re turning to, invariably don’t have time – unless they’re released which can happen – but they just simply don’t have the time, or the energy, or the behaviour to work with you in the appropriate way. I think again, we’re back to transformation and capability – and I’ve talked about the business analyst and comms, just a few people that once they appear everything changes. It’s really dramatic. And I think the same applies to the functional consultant type role. I think that if you’re working with some production people and trying to figure out what the ERP would need to do, having a great functional consultant do knowledge transfer is often best. It’s more expensive, but it’s quicker and it’s more effective, and they ask the right questions, and they know what information has been gathered, and is it sufficient, and what needs to be gathered, and the quality of that is. They just have this sense; it’s a tricky one I’ve seen both sides, but certainly the SAP exercise I saw for a client, they provided functional consultants into the finance area, to really understand what was going on in some of these purchase to pay, quote to cash processes. And having a functional consultant working with SMEs within the business, extracting knowledge and then extrapolating the ideas, and giving a functional consultant some ideas on where the future of that process could lie, is really important. And then translating that into functional requirements, and translating that into specification, is a process best led by people who do that.

I think to save money, very often, we do try and work with the internal resource and some of them are actually surprisingly good at turning their hands to that that. Invariably within two or three years you find them actually doing that job somewhere else. But I just think that working with consultants is the smart way to go, and if your scheduling, if you’re conscious of the schedule that will get you results, because they will do the work in the prescribed time. It’s not 9 to 5; they’ll be in early, they’ll be out late and work with the SME in the day and they turn that into whatever it needs to turn into. And they will do a great job of that.

Jason West: So make sure in your business case, you have enough backfill for those SME roles, so that they can spend time on this, but also line them up with functional consultants that really understand what’s happening out in the wider market, what technology can do, and they bring that external challenge, and they can challenge constructively.

Nick Ranier: Generally, I mean I don’t want your experiences has been, but for certain phases of the project you’re looking for them to be virtually available for two or three days a week, at certain phases and then they drop off while some designing is going on. Then testing comes after that, and suddenly they are there five days a week on that. They do drop in and drop out the profile, but as they go through, these SMEs, they start off with functional consultants, then work with the test managers and specialists. Then it’s go live preparation, so I think just assigning people to them, to work with them, to guide and help and not just from a technical perspective, but also making sure that any change management measures are coming out as well. Any insights on changes to working practices, policies, all of that stuff is also extracted from those individuals and tested as well, with leadership of course. I think it’s a case of working with them and taking as much as you can from them, because they will give you something.

Jason West: It’s it’s something that we’re seeing quite a lot, it’s more in the HR space than it is in the finance or procurement space, because HR has been on the cloud journey longer than certainly finance – procurement is  not that far behind HR for certain areas. But when you move to these cloud products, it’s not like the old days where you’d spend two or three years implementing Oracle and it would stay the same for the next 10 years. These things update every six months, and you never go live with the full range of functionality that you’ve bought on day one. So there’s always a road map, and the organisations that have been successful have bought this functional consultant, this solution design capability within that function, and they drive that road map and they continue to develop and evolve, and grow and transform. The ones that struggle are the ones that were perhaps too reliant on external consultants and they didn’t build the capability internally. And they are the ones that get stuck; they tend to be afraid of the product that they’ve bought. They’ve had consultants come in, changes happen, they’ve got a new operating model, they’ve got new processes, they’ve got a new system. But it doesn’t quite work as they expect it to, or want it to, or need it to, but they are lacking the tools and the levers to pull, or the skills to make the change happen. We are sadly seeing this more and more, and I think the more we can do as transformation practitioners, to bring this capability into these programme teams right at the start, so that you actually start building it in scoping, then the more likely it is that that transformation will stick. There’s no easy answer to that, we haven’t got a solution just yet, we’re working on it. But there’s a definite need from what we’re seeing out in the market.

Nick Ranier: It’s an interesting. And as well because regions doing the process with the same outcome will obviously, within there will be cultural and social practice, have differences within regions as well. I think having somebody sat with you at the centre, who is also knowledgeable enough to know what’s going on, in other places as well is important. It’s not just their local experiences, but about what they know of the wider business, so these are quite special and rare people.

Jason West: Yes, that’s a good point. For the larger businesses, you have to have your global process owners, but they need to be supported by country process owners, or regional process owners. And that structure is something we actually had at Thales. And getting that embedded and making sure that enduring facet of the function that you’ve transformed, is critical to the ongoing success of whatever benefits you’ve managed to achieve. It’s too easy for stuff to degrade: the programme team goes on to their next client and things kind of slowly drift apart, if you’ve not really cemented that capability within the client. It’s an interesting one; it’s a thorny problem.

The final point now, is really business case. You’ve done all of this work; spent the past three/six/nine months, maybe longer, really scoping out this transformation. You’ve engaged the business, you got your sun chart, you’ve got your vision, you’re really clear on your governance, you’ve got enough of a plan together, that it hangs together. And now you need to present a business case to the board, and ask them for a large number with many zeros. So, what are the mistakes you can make with that final presentation of the business case?

Nick Ranier: For the business case itself, in terms of the structure, I think companies and organisations, government departments, are really good at producing business cases. I think they do it a lot and they are very complete documents. The main issue, really, is of the benefits that are stated in the business case. How are we genuinely going to track those benefits? For example, if you are going to generate savings, what’s the methodology to track savings through the PNL into the PNL, so you can actually identify that those savings. And actually, that’s the industry that you need to engage in. So I think my reflections on the business case is, as long as they are rounded documents that do describe the scope very clearly, articulate “what am I in charge of? What am I responsible? What am I here for?” As long as that’s articulated very clearly, and then below that scope obviously there’s a work breakdown that’s associated with costs and the profile, there’s risks associated with that, current issues. All of those should be articulated in the business case. But again, you’re starting to get into several pages now, and people are meant to be able to read this thing, and understand it, and onboard the messages it’s giving you, and make approvals appropriately.

I say whatever the culture of the business cases is, then let it be so, as long as it has those key elements. But what’s often missed is the way that benefits associated with the business case are tracked and I think it’s probably the weakest part of transformation change management is that is that part of the process. When we were at Thales, for example we were trying to track savings in the PNL, we were actually told halfway through the journey, rather than having clear rules from the outset. So there were a number of methods and ways that people thought they were finding savings in the P&L that were discredited or redistributed and began it became a real industry to do that. So it’s probably not what you’re looking for Jason, apologise, but I think my own reflections on the business case is that they are normally pretty good, and as long as the scope if clear, and you understand who the sponsor is, and that individual understands intimately what he or she is expected to do, the resources they have at their control, the period of the business case is baked into budget, so if it’s one/two/three years those figures are baked into budgets (yes they do need annual review, of course).

But, as I said, it’s really the definition of the benefits and how they are tracked, not just after one or two years but within months; within sort of three to six months maximum; you then start say “right, we’re not expecting the benefits. But we are expecting to understand how you’re going to identify and track them, and then see that progress.” So that’s kind of the thing that lot often gets missed is the business case is then filed away, costs move away, time scale move away for the good reasons that we’ve just talked about, and people are trying to shuffle away from the benefits. Because in some cases it can be embarrassing. A good transformation won’t allow you to do that; if necessary it will transparently re-baseline the programme, revisit the benefits, and make associated decisions on that basis.

Jason West: Funnily enough, I’m in the middle of writing the next checklist, which is on the Build Phase and one of the points that are made on that, is that you don’t just take your business case and put it in a drawer. That’s one mistake, but another mistake is that you just extract the costs from it and you just going to forget about the rest, and you turn your costs into your programme budget and off you go. But if you don’t really pull those benefits out, and put the accountable people in place and say “okay you’re the person that’s going to deliver these things, make it happen, that’s going to feed your design.” It just doesn’t happen otherwise. You’ve got to make individuals accountable for the individual benefits in your business case.

Nick Ranier: Projects I’m working on now, people are saying to me; “where’s the original price? Where is the business case?” And nine times out 10 I would say I haven’t seen it. It’s not a criticism, it’s just what happens: it goes to the finance department they rip off the finance info and transfer it onto a spreadsheet, and make sure the spreadsheet is translated into whatever software they need it translated into. And then the rest of it, as I say, becomes a legacy and archive document. It should be very much a live product, and actually the business case should become a programme management document, so everything that is in the business case, should be in the body of the programme management. That’s document that describes for the sponsor, or for anybody that joins the programme, what the programme is trying to achieve, how is going to do it, what their role in that is. When it’s done, and I do it, and I’ve done it here for example, is worthwhile doing but you do get to ask some questions about the original business case two years after; “so what about that benefit?” And there’s a bit of a dismissive laugh, which is a shame sometimes because it says it all about where transformation can lead you.

Jason West: Yeah, absolutely. No wonder there is a degree of cynicism. Well, it’s been a fascinating hour and a half we’ve been talking. So thank you, again, for all of the insight and experience that you bring. And there’s a lot of interesting new stuff in there as well. I’ll have to find somebody to violently disagree on one of these things. But it turns out there’s probably some truth what we’ve been saying.

[OUTRO]