Joe Ales & Jason West
Season 1 Episode 10 – Solution Design
[INTRO]
Jason West: Welcome to the Underscore Transformation Podcast this is episode 10, my name is Jason West.
Joe Ales: And I’m Joe Ales.
Jason West: And together, we’re the founders of Underscore. This week we’re talking about solution design.
By solution design, we mean designing the new systems, processes, operating models, and team capabilities that are going to deliver your vision and strategic objectives, and ultimately, your business case. But you’ve got to do this within the constraints of your already agreed design principles. And these solutions have also got to work in the real world, so functional teams and your customers out in the business need to actually buy into these new ways of working, and they’ve got to adopt the change, and also be trained and willing to use these new ways of working. Your programme team are going to need to design solutions within these tight constraints. People that have been successful in managing operations can often find the demands of designing solutions quite challenging. So, let’s just kind of unpack these different elements that we’re going to have to consider as part of our solution design; where’s the best place to start with that Joe? What should we talk about first when it comes to solution design?
Joe Ales: Most programmes, most transformation programmes, will involve changes to people whether it’s the operating model, whether it’s process, technology refresh – nowadays you see you see a lot of transformations programmes getting initiated and enabled by technology refreshes. So these are probably the three key things: it’s your people, your process, and your technology. But what drives technology? Data. So you’ve got to be really, really clear about where your data is sat, what system is mastering what data, especially if you’re going to implement technology over the top of it. These are the sort of things that you need to start thinking about: start thinking about your data architecture, your system architecture. How are my processes are being run today? Hopefully you would have would have done some element of benchmarking along the way that will tell you where have you got efficiency or effectiveness issues among some of your processes, problems you’re trying to solve at this stage.
Jason West: Actually, that’s a good point because when we talk about solution design I think the first thing we should probably say is when to do it. And the time to do it is after you’ve understood where you are today, and the problems that you’re trying to solve. Don’t start with designing the solution, and definitely don’t start with selecting the technology, before you’ve really understood the business problems you need to overcome today, understand the problem, captured the requirements, and really be clear about where you are today. Get that signed off to say “yeah this is what you need to address.” And then start thinking about the solution design. And the level of detail that you need to go into, is driven by being able to populate a business case with a set of numbers that are pretty robust.
You can’t have too many wild assumptions about how much or how long it’s going to take you to deliver this programme, what it’s going to cost to implement, how much process and operating model change you’ve got. The solution design has to be of a sufficient level of detail to build a credible business case, and be able to paint a picture that has a sufficient level of credibility in front of the exec team, to say “these are the things were going to change, and this is a fully costed plan and design.”
Joe Ales: Absolutely. We’ve seen too many examples where organisations have just jumped knee deep into a set of design solutions. They start designing solutions without having done that adequate level of due diligence around your business problems: will this solve how our process is actually working today? How are people organised?
They just make it set of decisions about the future state without really understanding the ‘as is’. So I think this phase of the programme is to help illustrate what end state will look like. There will be some iterations along the way; once you get off the ground, once you sign off the business case, you’ll get a technology platform in the room and at that point you might have some iterations about what about that end state is, because ultimately a lot of these processes will be largely determined by how the technology is able to process or manage those processes.
Jason West: I think the area that you really must start with is your target operating model design because that’s going to drive pretty much everything you have. So, before you get into process, before you get into systems, really be clear about how we organise our operations, how we’re going to deliver services to the business. Really being clear about your vision, your strategic objectives, your design principles and how you apply them to your future operating model. Ask yourself: “If those are the things we need to deliver and this is how we’re going to deliver, what does that mean? What are the key elements that are going to make up our target operating model? What are they going to be accountable and responsible for?”
And then, how does that then breakout into the next level of detail? How does your business partnering, or your centres of expertise, or your shared services or whatever those structures are, how does that breakout into roles, teams first and then roles? And then you can start thinking about processes, but you need to be able to articulate at a reasonable level of detail what the accountabilities and responsibilities are to role at each level.
Jason West: Yes. Again, this idea of RACI, I’m sure a lot of people will be familiar with what that what that means: who’s Responsible, Accountable being Consulted and Informed? This is a methodology that’s widely used in sort of defining processes and so on. We tend to focus at this stage of the programme, in the scoping phase, just on the Rs and the As and being very, very clear about who is ultimately accountable for a particular process. And when we talk about process, what I’m talking about when I say processes is the broadest sense; so your PtoP or recruitment, or defining their strategy for the business. So these are not sort of transactional processes, business management processes.
Jason West: I think the key thing here is that you’ve got to tackle this to a sufficient level of detail, that it informs your business case. You’ve got to get to some numbers on your target operating model design, because you’re going from a model today to a model tomorrow, and they’re going to have different structures, different cost profiles, you need to decide geographically where people are going to be located. You might have an offshore hiring strategy as part of your operating model, you might be outsourcing these. These are all questions need to be taken into account before you go in front of the exec with the business case, because these are going to have a fundamental impact on how work is going to get done, but also what it’s going to cost. So the amount of change within that operating model will then dictate the amount of change that will be required from a systems perspective of programme, a change perspective, but also the processes. Assuming that you’ve kind of gone to that level of operating model design, you need to get to that role level before you get to a business case, really for the business case to be robust, there’s just risk if you don’t.
Joe Ales: There will always be element of a unknown quantity that you’ll need to manage through the programme once you get it off the gate and get it signed off.
But you need to have a really robust story at the very beginning, and everybody bought into it, and as it’s signed off the business case saying: “this is the scope of my transformation, it includes making changes to these roles, for these reasons, because we’ve done benchmarking, we’ve done voice of the customer [We talked about that in previous episodes], our processes don’t work, because we’ve got data sets and different core system of records everywhere, and we can’t tell there’s no one version of the truth to anything.”
That sort of gives you the rationality perhaps consolidate, streamline some of your technology sets and, of course, we’ve got the issues around “okay if we want to build or become a more sophisticated function, or a more effective function, we need to create these capabilities among the function that you don’t have today. Therefore, this is the impact on my target operating model, and because we’re going to digitalise and automate a lot more I won’t need as many of these and I need more of these.”
You’ve got to be able to articulate all of that clearly in the business case and if you do that your delivery will become a little bit simpler. People will understand what you’re trying to achieve from the very outset
Jason West: And the key thing that it’s lined up to your strategic objectives, and vision. There’s a clear line of sight, because otherwise target operating model design can end up actually just being a restructuring exercise and you’re putting people’s names in boxes, and you know it’s an org chart. That tends to be where programmes really get into trouble.
But let’s say you’ve done your target operating model design, it’s being well aligned to strategy, you got your numbers, new structures out of it. You then really need to step into process design. It’s here that that there is a difference depending on the technology landscape that you’re operating there.
Joe Ales: Yeah that’s right, absolutely. So if you want to bring in the difference between cloud and on prem, I mean a lot of organizations are moving towards cloud technology, so there are very there are fewer and fewer examples out there where organisations are investing in on premises solutions. But there are still some. The majority are moving towards this.
Jason West: And vendors aren’t putting their investment in developing their own on prem products in anything like the sort of way they were previously. They are putting a lot of money into cloud.
Joe Ales: So if you if you are implementing an on prem technology solution, then you have got to go into the infinite amount of detail around how you want your processes to be taught, to be executed because these on prem technologies are largely done in sort of more white space, but highly customizable to how you want your processes to be executed.
Cloud technology is less so. Actually, it’s important describe what experience you want in your business processes; who’s going to initiate? Who’s going to approve? What’s the governance around your business processes? But don’t be hung up about designing processes at a really granular level of detail, because a lot of these technologies won’t be able to deliver against that level of detail, because they come preset with their own business processes. So there’s a concept in design: one of your design principles would be actually: “if we want to go with cloud technology I am going to exploit the ‘out of the box functionality’ as much as possible.” With the interest of keeping it simple, so it is important to spend time on finding that experience. And who is involved in this business process? What’s the governance around those business processes? But don’t get hung up about “in step A I’m going to ask individuals to complete the set of data sets” it just won’t work. You’ll waste an awful lot time doing negligible work.
Jason West: So I think as we’re stepping into the technology space now, I think there’s quite a lot of architecture that you need to get to grips with and this is where working really closely with your IT function is key, because you’re one way or the other going to be impacting the core ERP system, the core HR reference system, and the way that you interact with suppliers. So you have to consider any changes in the technology space within the wider enterprise architecture, the wider data architecture, systems architecture. And you’re going to be pulling out bits of functionality, or the very centre of it, and replacing it with something you potentially massively updating what’s there.
Joe Ales: And actually, one of the things that we often come across is if you don’t do this well you’ll just encounter problems later down the line. Integrations will come out of the woodwork, systems then need to be fed where data from, whether finance and the finance system, or HR system. These little systems have been requiring this data set that hasn’t been been scoped out. These programmes are time-bound right, so the minute these new integrations come out of the woodwork just creates a lot of risk on the programme and actually challenges on the schedule, so you’ve got to spend a lot of time really understanding how does the system plug in, fit into the overall services enterprise architecture, and where’s the data?
Jason West: Yes. Start with the data. Where is data mastered? Where’s it flowing? How’s that going to change?
Joe Ales: Master data management is so important here, if you’re a multinational business, a global business it’s so, so important. Even in the small business that actually, the size of your business doesn’t really matter. If you’ve got different data sets in different systems it’s something you need to pay attention to now. More importantly actually since GDPR has come along. That in itself has changed the dimension of how you manage people data and across different systems. And if you don’t have control of your people data across different systems, maybe use this as an opportunity to get your house in order.
Joe Ales: Absolutely and I think one of the other things, not to underestimate as you’re going through this scoping phase, is just how many decisions your team are going to have to make around system design, process design, operating model capability. And are they really prepared for that? Because these are no doubt great operational people, that know how to operate within a set of parameters, and they may well have been involved in continuous improvement activities over the years. But what you’re asking them to do now is envisage an entire new world, as much as you can, unencumbered about by what happens today. That’s a really fundamental shift in the mindset of those individuals; it can be really quite stressful. You’re asking them to go from this operational mindset about 0 errors or however many errors in a million or whatever the lean and Kanban world, to “we’re going to rip everything up and do it completely different tomorrow, and we’re going to need you to imagine another world.”
And they may not have had the experience of many other organisations and we’re going to put them into these positions of “You don’t just need to make decisions, you need to make decisions really quickly with perhaps imperfect information, and by the way you have to deliver on the set of objectives, and make sure that people want to use these processes, and systems.” It’s a big ask.
Joe Ales: And these individuals will find it difficult, at times, to see how it can be done in any other way, so they need a little bit of inspiration I guess. And actually I would encourage, during this phase of the programme, for individuals to experience and meet other organisations; check the art of the possible across how other organisations are managing these things. Just as a way of providing that sort of inspiration that will enable them to think differently. Individuals can get a bit hung up about “well it’s the way we do it, away it’s been done for however many years or however many months.” They might find it a little bit tricky to see something different and especially if the difference will be enabled through technology that they have not experienced before. So they’re a little bit blind to the capabilities of that technology, what capabilities their technology can bring. So it’s important that they become familiar with users of that particular technology, go and and speak to people and engaging with individuals externally. Don’t be afraid to do that; it’s fine.
Jason West: One of the things that we have done in the past that has worked well is you set your design team some homework. Before you get into your design sessions you say “okay you need to go and visit with a certain number of external organisations, and talk to them about their procure to pay process, their resourcing process.” And you give them the structured set of questions to run through, and then they have to come back and present. So, before you even start your design sessions, they’re reporting back on what they found, what they heard, and that worked pretty good actually.
Then the other thing that is just a consistently good practice approach is to set up round table discussions; get people that have been through transformation, that are midway through, and get them to share their experience is a bit of a kind of show and tell.
Joe Ales: Especially if you’re looking to acquire a particular set of technology whether it’s Oracle, SAP, or Workday, whatever it is, ask suppliers to provide you a list of individuals that they would recommend to get round the table with you. Don’t be afraid of asking the question of the suppliers and they will be more than willing to give you good references to speak to. You can really tap into the brains and minds of those organisations that have implemented those technologies before and who had been transformed.
Jason West: A side note though, is do your own research. Go on LinkedIn, find companies that you haven’t been given as references by the technology vendors, and talk to them. Really kind to do your own research on these references is key.
I think we have talked about the importance of building programme management capability within your in-house team that you’ve seconded to the programme. But I think you have to build solution design capability as well, so actually investing some time in training and coaching and development sessions around creative problem solving, around innovation, around design thinking. Give them some tools, and give them some skills around this stuff and really taking a customer centric approach to design. There’s lots of tools out there; there’s some really good things around value proposition design, different personas, and design different systems and processes, different user experience for those personas.
Joe Ales: I mean at this stage of our programme we’re in the scoping phase, so a lot of that will come into fruition in the next phase. This is really groundwork, this is really getting the grounding set and if you do this right in this phase of the programme, the next phase becomes a lot simpler. If your scoping is done well, then your programme is going to be executed more successfully. There’s a better chance of it being successful if you do all of our checklist points really well and giving individuals the skills and capability at this stage, is vital. Get them thinking about designing future state. Get them to think about that at this stage of the programme, rather than waiting until we’re in the next phase, when you got a system integrator in the room asking the difficult questions about how you want your future state to be, and you’re unable to articulate that. It becomes really problematic.
If you get that design thinking in this stage of the programme it’s a lot better,
Jason West: And these individuals are going through a change curve themselves. Give them as much time to do that as possible, so they are already engaged and effective by the time you need them to make these decisions,
Joe Ales: If you provide them with enough inspiration from people that have been there and done it; iIf you give them the opportunity to do that, they’ll be inspired by, and energised by it, to point that it’s you know “the world could be different”, and will be excited by it.
I think this is great options we’ve done a lot of these ourselves away in like you said round table discussions task people to go out and speak to people, having done that and been there and done it, is a good technique
Jason West: And I think also bringing in programme team members, whether that’s the programme manager or transformation leads, functional consultants working on your side of the fence rather than on the vendor side of the fence, that can bring that external best practice and constructive challenge to really inform your permanent design team. But they’ve got to be ready and receptive for it.
But I think the final piece just to think about, and perhaps this is more as you’re building up your implementation team just after your business case is being approved, is really about the individuals that are making up that team. So the personalities of the people: how to build a really effective team. You need to think about collaboration with the team; have you got people that have got active listening skills, are they resilient, have they got empathy? These are all things that you’re going to need as you get into implementation. Actually spending some time in properly forming that team and what has worked a lot is actually bringing some psychometrics into play, and really getting the team to understand the communication styles, the thinking styles of the individuals, and how they can best work together.
Joe Ales: And then just making sure you’ve got a good balance of those with innovative thinking, and of the balance of people that focus on detail, the yellows, reds and blues, greens. Whatever you need, you need a good balance in your team of these different characters and we’ve seen this being done really, really well in a scoping phases as you’re forming your team. The sponsor has visibility of the output of these assessments and psychometrics and actually makes a set of decisions about the structure of the programme team needs to be different because it’s lacking these types of skill sets, these types of behaviours or these types of characteristics.
Do it at this stage before you hit the ground running and the business cases often signed off and you’re at 180 miles an hour frankly. Actually, this stage is probably 120 miles an hour, when you go into the next phase is 180 miles an hour, and be prepared for that. So if you do as much groundwork as possible in this stage it will be more likely to be successful.
Jason West: A really big topic that we probably just scratched the surface on this one. But we summarise there’s some kind of key things to focus on as you’re really thinking about your solution designed. So start with target operating model design, and make sure it’s aligned to your strategic objectives and your vision, and it complies with the design principles.
Design it down to a level of detail that allows you to actually fulfil your business case, and cost down your future operating model is, and then that starts to inform your process design. And the process design, the level of detail will be driven by whether you’re going for a cloud technology solution or on prem.
And then as we step into technology, start with the data architecture: what’s mastered? Where is it flowing today? How’s that going to change in the future?
One that we didn’t mention; if there’s any new data sets that we’re going to need to create, and there will be if you’re putting new technology in, its as new functionality new processes available. Then look at your system architecture; work really closely with the enterprise architects in your organisations: you need those architects to help you through this.
And then preparing the team for this solution design activity. Make sure they’ve got the skills and the mindset, the toolset to be effective.
Fantastic. So that’s it for this week. Next week is our final point on the checklist so that’s going to be episode 11 and that’s business case. Everything has been building up to this point: this is where you’re about to ask somebody for a very large amount of money for you to go and busy yourself for the next few years.
So, thank you again for tuning in and listening. Please remember to like and share and we look forward to next week’s episode.