Joe Ales & Jason West
[INTRO: You’re listening to the underscore transformation podcast your practical guide to business transformation]
Jason West: Welcome to episode four of the Underscore Transformation Podcast, my name is Jason West.
Joe Ales: And I’m Joe Ales
Jason West: And together, we’re the founders of Underscore. Now transformation initiatives require changes to processes, people, and systems; and if the wholesale replacement of systems is in scope, it can be all too easy to become overly focused on the tech. Especially if you’re running a procurement process to select Tier 1 cloud ERP or HCM technology; so that systems like Oracle Cloud ERP, SAP S/4HANA, SuccessFactors and Workday. These are really big, complex systems that cost millions, and have a really profound impact on how your business operates. So, it’s easy to become fixated on technology requirements and really forget about the people and the process aspects of transformation as you’re scoping out your programme.
With the pressure to select the right technology partner, how do you ensure you don’t become fixated on the technology? What’s the best way to approach that Joe?
Joe Ales: Good question Jason. I think really the organisation needs to understand its capability requirements in their absolute broadest sense. So, do we have the right people, with the right skills, with the right capabilities? Are our processes right? Absolutely technology takes us in the right direction, but ultimately what we need to understand is what’s the business ultimately trying to achieve? And are our people, processes and tools aligned to achieve that?
Jason West: Yes. I think there’s a piece, that when you look at the people it’s not just that competencies, their skills, and how they’re structured. It’s what is the culture we want to have in the future? Not just what we have today, so how is that going to change and what’s the requirement to change it? It is very easy to become very fixated on just looking at technology requirements, but what’s the best way to approach this kind of broad view of capability: these people, process, and technology requirements?
Joe Ales: One of the techniques actually that we have adopted, with our clients and projects we worked on, is one of the first things we need to do is understand what’s the taxonomy that the organisation is using and determine how it works across the various functions. So, how is the organisation attempting to execute their Procurement-to-Pay processes, their ordered cash processes, their hire to retire processes, and making sure actually, in a global organisation is there commonality around that? Actually, getting to the bottom of that sort of construct of the business, and how the business operates. And then getting a bunch of people involved in diagnosing whether the organization is delivering those effectively or not.
Jason West: Yes, so having that structure and actually having, perhaps an external structure, looking at your processes. Especially if you are a global organisation and you know you might have different processes in different countries. Having that external taxonomy to make sure that you’re covering all the bases, even if things are different in one place to the other, you’ve got a common language to talk about your requirements in that kind of structured way. That’s been quite useful.
Joe Ales: It has; it just removes a lot of that angst about “in my organisation, in my business unit we do it this way”. It takes away that noise and allows the organisation to then focus on: “Okay do we have that capability in our business to execute this process, or this activity?” Whether it’s traditional processing in the broader sense, it’s not just a transactional process, it can be developing business strategy. Having an external taxonomy actually removes a lot of the angst within the organisation about “well my business works better this way,” because I used these common processes or systems. Having something external just takes away a lot of that noise and allows the business to sort of really focus on the key capabilities.
Jason West: Yes, absolutely. And you touched on it there, and we’ve spoken about it in previous episodes, and I have a feeling we’ll probably speak about it again, is the importance of getting a broad sweep of people in to talk to them about these requirements. So not just the people that work in the function that you’re looking to transform, but members of other functions. Perhaps you’re transforming HR, get finance people in the room, sales, operations, programme management, retail, whatever. Getting those different views.
Joe Ales: You need a real broad perspective, because actually, business activities are executed by multi-functional teams, always. If you’re starting to determine what are the capabilities, what are the requirements we need in our transformation programme, if you don’t include the perspectives and the views of the broader business you’re just going to become very insular in what you’re trying to achieve. So it’s absolutely vital that you engage as many of the business operations and have as broad a representation in the business as possible when you’re really trying to define how do we do things today, and what’s wrong, and actually what capabilities do we need to build, to allow the business to achieve ultimately what it wants to achieve?
Jason West: Absolutely and you know countries are a really important element to that as well. So, if you’re a multinational business then the way you manage people in Germany is quite different to the way you manage people in Brazil. And getting those perspectives and points of view in early, as part of your requirements gathering, just reduces that risk that as you’re midway through implementation, then suddenly someone stands up and says “you know what, have you thought about works councils?”
Actually, getting that really mapped out in advance, means that you really understand the problem absolutely, that you’re trying to fix. But it reduces risk overall. And I think there’s also an element about having a breadth of seniority or people of different levels in the organisation involved. Because what managers and directors will view as being a real requirement will be perhaps different to what somebody operationally, on the shop floor, or who actually managing process day to day. And both are equally valid and equally important.
Joe Ales: Absolutely they are. And actually, a lot of the pain in poorly designed business processes are not felt at the top. They are felt way down in the organisation, so you’ve got to absolutely take the view from the exec in terms of what business problems we are trying to achieve? And we talked about that in a previous podcast, but actually when we were going to requirements gathering at this level of detail you’ve really got to get into the nuts and bolts: how does this impact the hiring manager or line manager on the shop floor who’s trying to deal with a multitude of tasks and activities? Ultimately if processes are broken, or systems are broken it’s these guys that are ultimately going to feel the pain. So yeah, involve as many people up and down the organisation, and across the organisation in the country, cross countries. Like you said, to get a real balance of views.
But there is a risk that you’re going to end up with so much information and data, that you then have to sit there and spent, probably a little bit of time, trying to prioritise: “what’s going to be important in our transformation programme? What are we really going to be able to achieve in this finite amount of time that we’ve got, with this finite amount of cash and budget that we’ve got?
[Intermission: you’re listening to the underscore transformation podcast this podcast is brought to you by underscore the transformation capability specialists to find out more visit underscore-group.com.]
Jason West: I think that’s a really good point, because you want to go really broad, you want to have that problem: you want to have as many issues, requirements, and the biggest possible set of data that you can. And then push it through a filtering. And that filtering is really where your governance structure comes in. So even right up front before you’ve even thought about designing anything, making sure you’ve understood who your process owners are. They are the people that are going to review these requirements and they’re going to make a set of decisions about what we actually take on, because not every requirement is valid.
Absolutely capture, it write it down, but then make a conscious decision right up front about “are we going to accept this into scope or not?” and document it, ideally, if you possibly can, because you’re making real design decisions to a degree, just by deciding what requirements you’re going to accept in and out of scope. By the time you’re making those decisions you probably need to have thought through; “well what’s our vision? What objectives are we trying to meet? What are our design principles?”
So there is that kind of interplay between, absolutely gather the requirements, but the point where you starting to filter them, you need to have done an element of design thinking already. And at least you’ve got those vision objectives and design principles in place.
So, when we think about those requirements, I think one of the things that can often get missed is that this is what is driving your programme or what should be driving your programme. So the real needs of the business, the customer of your function, is absolutely central to what it is that you’re trying to deliver. Linking the requirements with that clear line of sight through to the ultimate business benefits that you’re going to deliver, that go into your business case, that you commit to the exec as you ask them for however much – ten, twenty, thirty million pounds/dollars/yen (probably not yen, might not go very far) – whatever that amount of money is that you’ve got, there are clear benefits that you can then track backwards to a requirement that says “we’re doing this thing, whatever this new system/process/change in people structure is going to be, for these reasons, because it’s going to deliver this benefit, and that tracks all the way back to these workshops that we ran, with this group of people, that said this is really important. And we pushed it through a governance process, they signed it off. The exec steerco signed it off, and that’s why we’re doing it.”
Joe Ales: Absolutely, it brings clarity to what the programme is trying to achieve. It removes ambiguity. And if you do this right, if you do the requirements capture right, if you describe what capabilities you are going to create or develop on the back of this transformation programme; in projects scope creep is a major, major problem in programmes because once you’ve got a transformation engine, a project team with a vehicle to design and deliver something, organisations are quite quick to sort of come in and say “wouldn’t it be great if we could also do this?” Having this done well up front allows you to structure your programming in a way that says “No. This is what the program is trying to achieve.” Any changes to that – and absolutely there will be changes to what you set out to design, ultimately there will be changes along the way – but when you have that sort of structure, documented decisions about what am I going to do, and then if you come in halfway through the programme (because the business will evolve these projects, they are sometimes two years long, and the world changes a lot in that time and naturally things change) but it just gives you that bit of structure documented decisions etc. about what this is what we said we were going to do. By all means we could do XY&Z, but are we going to compromise anything that we said we are going to do?
It is really, really key. And again, we’ve noticed organisations have not paid enough attention to this, and fall foul of it. So anyone listening to this should really sort of take note about how important it is to have this group of people help you define what solutions you need, to develop in your transformation project.
Jason West: Absolutely and your requirements are alive: they evolve over time and that’s fine. But they have to be documented, and you have to control what you’re taking in and out of scope, and really document those decisions, as you move your scope around. And we’ve seen that a lot in certain organisations that kind of use the word “agility” or “agile” to basically mean, “well we’re just not going to write anything down.” Its not really how it’s meant to works and tends to become a bit of a problem when you get to testing.
The other thing that we’ve seen and some “watch outs” for the programme sponsors out there, is where you have one organisation or one team that are scoping out your programme and then you have another team running the implementation – and that’s not unusual to see – but the capabilities that you need to implement a transformation aren’t necessarily the same as you will need to scope it out. Scoping is very much about understanding the problem, designing high level solutions, building business cases, building coalitions; it’s about selling a vision inside the organisation. Implementation is very much delivering on that, it’s making sure things happen in the right order, and the programme gets delivered on time, on budget, and the benefits get delivered. But there’s fewer people in the market that have the capability to scope a programme as there are to deliver them. So where you do have these kind of handover between a scoping team and an implementation team, really watch out that the implementation team doesn’t just kind of take all these lovely requirements and then go “I’ll just decide to implement what I’m going to implement, because that’s what I’ve always done.”
Joe Ales: Absolutely. Paying attention to the handoff between teams is really important, because there is always the danger that the team that are implementing don’t pay as much importance to all of that work that was done to help the find the capabilities that the scoping team would have done. And actually, the other point is, if you enter into a race – because it is a race; a transformation projects are a race against time because there’s budget on a line etc. and whole bunch are people really excited about the future – more often than not organisations are faced with challenges around costs for the programme, and the burn rate of the programme. Am they start making decisions about taking things out of scope, that were fundamental requirement in terms of capability at the outset. So you end up with a situation where teams say “let’s take that piece out,” but actually, no you shouldn’t take that out, it was so fundamental to the business case decision for this investment.
Sponsor really need to pay attention to the transition. The other thing that we also need to be mindful of – sponsors out there – is if a new sponsor joins (again projects last over two years sometimes, so it happens), and I think we’ve spoken about this in previous episodes, but as a new sponsor comes in; a new CFO or CHRO joins the organisation, don’t just take for granted in terms of what it is they were trying to deliver today. Actually go back to see what was the original requirement, to see and do the alignment piece: “are we delivering what we said we were going to deliver before my time?” Make sure that you do that reconciliation, because ultimately you end up delivering a transformation programme, and the last thing you want to do is rock up to the organisation say “ta-da there’s a transmission programme that I’ve executed” and the people that were involved in the very beginning of the project turning around to you and saying “yeah, that’s all well and good, but it’s not doing what we had set out to do at the very beginning.”
Jason West: So where a transformation programme could easily have over 1000 capability requirements that it’s managing as part of its scope – because that’s changes to systems, people, policy, work instructions – how detailed do you think programme sponsor needs to get, into that list of hundreds of requirement?
Joe Ales: Sponsors will hate me for saying this, but while they don’t have to get into the depths of it, they do have to have a real clear view of what is this transformation going to actually deliver? What are the products that we’re going to get out of this transformation? For example, out of this transformation we are going to come up with a set of new hire to retire processes, or our target operating model is going to change, or we are going to implement new bit of kit new, better technology that will allow the organisation to do more self-service activity. Perhaps we are going to digitalise our process a lot more, or we are going to change policy AB&C, we are going to change the culture of the organisation by doing XY&Z.
So you have to be have to be very, very clear that these are the products, these are the outcomes we are going to get from all of this capability stuff that we’ve that we’re going to have to deliver.
Jason West: Absolutely. So if we if we think about key messages and takeaways, it’s engage the business, and ask for advice as broadly as possible. Write it down.
Joe Ales: Yes, capture your requirements, and consolidate them.
Jason West: Make a decision about which ones you’re going to bring in and out of scope – are you going to accept them all? Actually use those requirements as a live, living, breathing document to manage the direction and scope of your overall change. And really don’t rush into solution design; actually understand what you’re trying to change first, before you get to designing stuff. Use your requirements as you test: does this thing meet the requirements that we captured and ultimately measure it during your benefits realisation.
And if you do have different teams involved in scoping and implementation, make sure that the implementation team fully get to grips with detail of the requirements, and they commit to delivering against those. And as sponsor, you need to get into some of this detail – not all of it – but you need to be across it, and you’ve got to absolutely trust the team that you put onto this programme, that they’re going to be across the detail and that they’re going to deliver what they say they’re going to deliver.
Joe Ales: Yes, and one final point is a watch out: don’t defend what you do today. When you have these workshops, if you have any individuals making comments or criticising the way things are working, don’t defend it. Use it as an opportunity to allow people to air their views, their voice and you genuinely hear what they have to say. You might not necessarily agree with, but don’t defend it because it just doesn’t set the right tone for these requirements workshops and requirements gathering.
Jason West: Absolutely. Next week we look at how you prepare for change during the scoping phase, and the fact that actually you need to do work on preparing to change as part of the scoping phase. So we hope that you found this episode useful and we’d love to hear your feedback, so please contact the show via our WhatsApp group or via our website underscore-group.com and if you enjoy the episode please remember to like and subscribe via your favourite podcast directory.
[OUTRO]