Joe Ales & Jason West
Season 2: Episode 4 – Design the Future
Jason West: Welcome to the Underscore Transformation Podcast. My name is Jason West.
Joe Ales: And my name’s Joe Ales.
Jason West: And together we’re the founders of Underscore. In season two, we are focusing on implementation, and the challenges that surround designing, building, and testing your business transformation. In today’s episode, we are discussing architecting your solution. The deliberate act of setting out changes to processes, systems, and people to meet an agreed set of objectives. So, Joe, where do we start?
Joe Ales: Well, before you do any detailed design, you’ve got to really have defined what your destination is. And we’ve talked about this in the previous season, actually in quite a few episodes, but you need to know what’s your vision? What are your objectives? And they are front and centre of what you’re trying to achieve. You mustn’t lose sight of that when you’ve got a nice new shiny machine, or new site, or shiny system in front of you, that you’re now trying to make configuration and system changes to. You’ve got to remember what was the reason, the rationale for the transformation you’re trying to execute? And design principles, we talked about as well, making sure they are there, they are well defined and agreed before you start getting your hands dirty and playing with systems.
Jason West: Yes, agree what the problem is that you’re trying to solve, before you start designing things.
Joe Ales: Absolutely. Don’t do things in dark rooms, don’t get into a dark room making a series of design decisions, that affect just you. This is a mistake that many organisations make, isn’t it, when they’ve got a system in front of them, they try to get the system, or they try to make changes to business processes, that impact just their function, instead of looking for business problems they’re trying to solve.
Jason West: And then once you’re really clear about what it is you’re actually trying to fix, before you get into the detailed design of new processes, new systems, new team structures, all that sort of stuff, then you really need to have defined that high level solution design. That blueprint, of what it is you’re going to change; being clear on “we’re going to make changes to these strategies, these policies, these processes, these elements of systems, these ways of working, these team structures.” And all of that needs to have been well documented and signed off as part of the scoping phase of your programme. But if you don’t have these things in place, please don’t rush into doing a detailed design before you’ve really thought about it, because it’s going to cause you problems. It’s like trying to design on the fly. If you were building a house, you wouldn’t start with the roof. Yeah, exactly. You wouldn’t be pouring foundations before you designed anything on a bit of paper. Maybe in Grand Designs, then sometimes it turns out great houses, but the couples aren’t often married at the end.
Joe Ales: The other thing, especially with cloud technology actually, or on premise technology, they force you to think about this right up-front as you’ve got one opportunity to get it right. With cloud technology it is slightly different, isn’t it, because they have this sort of concept of approach and iterative design, gives you the perception that it’s okay to get it wrong the first time. Let’s just do some iterations to the design, it’s a bit like agile thinking, agile methodology. But actually, the reality is you’ve got to have done the groundwork. Don’t be misguided that you’re going to have lots and lots of opportunities to make a whole set of design decisions, because you’re not. You’ve got to have done all of this work right up-front: what is your end state? And your iterative design is just to refine the elements of that original thinking that don’t quite work. It’s not an opportunity to continually redesign something as your stakeholders get involved and start asking you questions about the design decisions you’ve made.
Jason West: And you need to have quite a lot of clarity, as you go into those sessions, around you structure, your operating model, who’s going to do what? Are we going to have shared services in every country? Or is it going to be regional? Is it going to be a global, central shared service? Will it exists at all? And being clear about the data structures that underpin the processes and the systems. If you haven’t done that thinking before you get into a room and start designing systems, you’re going to have a lot of problems.
The other thing, and I’m highly aware that we’ve become guilty of it ourselves, is don’t rush into designing systems. Or talking about systems on podcasts it turns out. This is much broader, and it’s really natural, given the amount of complexity and money that is being spent on putting in a nice bright, shiny new system that your process owners. Your programme team just become fixated on the technology, and forget all that end to end: the processes, the work instructions, the changes in peoples roles, all this really important stuff.
Joe Ales: Yes, transformation is much broader, isn’t it. I mean the technology piece can be a catalyst for it, without a doubt. But actually, this is much broader. It’s changing hearts and minds, changing ways of working, changing cultures around the organisation. So, this is not just about getting into that room, playing about with some switches on a system.
Jason West: Let’s assume for now that your blueprints, your plans, they’re all in good shape. They’ve all been really well thought through, they’ve been signed off as part of your final investment decision, before you got to this stage – the start of implementation – then surely you must be ready to get started now?
Joe Ales: Yeah, but where’s the budget? Where’s the cash? You need to look at your business case, so you’re now ready to go and pick up the business case: where did the investment decision come from? And what benefits were stipulated and outlined in the business case? And again, we talked an awful lot about business case in previous season. So, dust it off again. Hopefully it would have been too long ago, between business case being signed off, and you being in this position to be to start architecting your future state. Dust it off again and put those benefits front and centre of your design thinking.
Jason West: And really make sure that the team members, the process owners, your design authority, those people accountable for making design decisions, are absolutely aware of the benefits that they need to deliver as part of their solution design. I think it’s got to be part of that kick off meeting that you have; that initial kick off meeting with the programme team where you describe the business case. Hopefully you just reiterate it; they should have had a lot of input to this business case up to this point, but you need to really describe it to them again. And in that meeting, assign benefits to process owners; be really clear they are accountable for delivering these improvements in ‘order to cash’ or whatever it might be, the recruitment process, whatever those key metrics are that are driving the benefits that you’ve promised to the exec make people accountable for them.
Joe Ales: Yeah, I mean process ownership, in itself, is a whole different ball game isn’t it, that is so important. Ambiguity in a project about who’s accountable for delivering a certain outcome not just at the programme level, but down at process level, it is clear that you have to have clarity around that, as ambiguity in it will cause you problems.
Jason West: Absolutely, and that’s kind of the process level. You touched on the programme level; you really do need to make sure you’ve got an individual who is accountable to the sponsor for the overall delivery of the business case. That business benefits.
Joe Ales: Yes, that programme lead. They are going to work alongside the programme manager, programme director. It’s going to be them ultimately accountable for embedding that transformation across the various workstreams, and it’s going to be them accountable for the outcome of that transformation.
Jason West: Yes, it’s that permanent member of staff, and they really do need to be on your payroll, rather than an external consultant or contractor that you bring in to do this. They need to attend every single design session, they need to be in those playback sessions, they need to be heavily involved in testing, and they are there to really ensure that the processes, the systems and the people elements of the change would be well designed. If they’re going to meet the required benefits, then they need to live and breathe the business case. They need to represent it into the programme. But some of the challenge around that is that they don’t necessarily all have a broad spectrum of experience of other organisations, people in these transformation lead roles. So they might have a reasonable view of what good practice looks like, but maybe not; and in a lot of cases they could well be new to this whole approach of architecting, of design, and being able to coach other process owners through making the trade-offs, between one set of design decisions and another.
Joe Ales: Yeah, you’re right actually, because that is the risk of having somebody that’s been in an organisation, and who has an awful lot of corporate knowledge, and this is an important point. The person that is spearheading this programme supported by a number of different roles, and we talked about key roles before in previous episodes, as well, for delivery of a successful programme, that person has good corporate knowledge of the organisation, they’re trying to push this change through. But there’s an awful lot of good practice out there so we’d encourage any of these individuals to go out and reach out to other organisations, that have gone through similar transformation challenges and experiences before, and ask “what does good look like for them?” And actually, bring that thinking into your into your organisation and drive that through your extremely to actually. The other thing is to encourage work stream leads, as well as process owners to do the same.
Jason West: Yeah absolutely.
Joe Ales: You’ve got innovation being driven into your design that’s been probably explored and elsewhere, don’t reinvent the wheel cause you don’t need to.
Jason West: I think the other thing is that it’s important that the transformation lead is on the payroll, and really holds themselves to account for delivering the benefits, they could often need that support. So you touched on earlier, that’s where the programme director, programme manager, the external person is coming in or even a actually getting some external advice, very specifically around solution design and into those design authority type meetings. You need somebody that’s got that blend of operational experience, and programme and transformation experience, who’s been there and done it before. But you don’t necessarily have to be full time.
Joe Ales: Absolutely, and having somebody alongside you who can identify where the trapdoors are likely to be is so important. Because these individuals, these programme leads wouldn’t have had huge amount of experience doing this elsewhere. So yeah, tap into those experts out in the market to just get that different perspective, I think you’re absolutely right.
The other is that there is always a risk that individuals are trying to solve business problems, that affect just them, and the pains they feel. And they will start going round in circles, and trying to die in ditches over things. So having that external perspective, just sometimes just helps bring a little bit of common sense, I guess, into your design thinking.
Jason West: Yeah it is so easy to get trapped in rabbit holes.
Joe Ales: And I always say: let’s not focus on the minutia, let’s focus on something that’s designed for the majority, not for the minority. Let’s find a way of dealing with the minority, because those nuances and those things exist in a business, that you need to take account of. A particular business unit might work in a certain way, for example, and don’t ignore that. But don’t design your end state to account for the complexity that’s driven out of that business unit for their particular reasons. It’s just things like that; and it’s easy, it’s really easy to, in design workshops and design sessions, when you got multitude of people in a room, with different perspectives, and different ideas about what good looks like, it’s easy to go down rabbit holes.
Jason West: Yeah. I think it’s also easy to for teams to get focused on boundary conditions, and designing for the 1/500 chance that somebody might do something, that needs control. Or you putting too many approvals, or too much governance around something. And just taking proportionate approaches to risk can kind of go out the window as people start saying “oh wow we can do all this amazing stuff, we can put in all these automated controls or this oversight, because we’ve never had it before. Our previous systems wouldn’t allow us to do it.”
Joe Ales: The other thing is remembering that you’re not putting something in for your own use; you’re putting something in for somebody else to use.
Jason West: Yeah, it’s that customer centric design. And I think that’s actually a really good point to talk about. Actually taking a customer centric design approach, rather than a system design approach is really key. In the world of SAAS, now that most people are implementing a system these days are going to go for a cloud solution, more or less, it’s been great on one hand because you can be up and running really quickly. But it does suck that time and attention into focusing on systems, in a lot of cases. That speed to deployment is great on one hand; on the other, though, you’ve only got limited time to think about all the other stuff: those off system processes, the policies, the work instructions, the how-to guides, the user experience of this new system, with its processes and its new ways of working that you’re going to bring in. And you can spend less time on the change because you actually have less time to spend on the change. So really thinking about that customer centric design, before you get into the systems piece is really, really important.
Joe Ales: It is easy to design things to solve your own problems. If you’re running a finance transformation programme, or an HR or procurement programme, you are ultimately trying to design processes there are finance/procurement/HR processes. And it’s easy to sit down in a room and go “okay what we want to do is make our lives a little bit easier, by putting self-service on everything, and outsourcing almost everything we do to the business.”
Jason West: Yes, because line managers are not busy people, at all. [LAUGHS] They don’t have important roles to do in the organisation,
Joe Ales: Yeah, so it’s “let’s outsource everything we do and make line managers responsible for everything.” And there’s a difference between accountability and responsibility; they can be accountable, but not necessarily have to do everything. I always say we have to have the right balance between who does what. And if a procurement function, a finance function, and an HR function are all going through a transformation at the same time, and have got the same ethos of “let’s move everything over to the business line and get them to do everything” it’s an awful lot of change to land in the business at one point. And with cloud technology, especially, you can be up and running in 12 (or sooner). If it’s a big transformation programme across all functions, it will probably take a little bit longer nine to 12 months to get up and running yeah. It’s not an awful lot of time to change the hearts and minds of people across an organisation, and especially when you don’t actually know, from the very outset, what the end state is going to look like because you are still architecting. So engage the business in your architect phase as much as possible.
Jason West: Yes; in the right way, though, because you don’t want a cast of thousands in your design workshops.
Joe Ales: Absolutely, you need to find those mechanism of playing back to the business, some of the design decisions your making, and the impact that these design decisions will have on your business. Don’t do all the design in a dark room, and then go “ta-da – this is what it’s going to look like.” Because you might have feedback, and you might have a point of view from the business, that “actually you haven’t thought about this.” And then you have to go back to the drawing board, and you do not want to be going back to drawing board, because inevitably it means delays to projects.
Jason West: Yes everything needs to be re-tested, and you surrender some week’s if not months, of delay.
Joe Ales: So before you do your architect, before you start pushing a whole load of design into a system, or into changing your processes, playback these design decisions to the business. Make sure that the business understands the impact on the people, and all the change aspects. Make sure that the business really understands that, and then get validation that this would land well if it was designed like this, and then go away and start to push design and iterating the design across your various systems that you are trying to implement.
Jason West: I think you can do that really quickly. It could be a month, maybe two, of doing some of that off system, before you even engage with the system integrator. Get them in the room before you do that; that’s where you customer centric design piece comes in. And there’s lots of good processes out there for doing it: there’s value proposition design, user experience design, customer centric design. There’s lots of them, but it all starts with the customer, and creating a number of personas. So getting your design team together, your new process owners, your design authority together; create those personas, and then linking back to the requirements that you gathered during the scoping phase. They should give you the insight, that you need, to really define those personas well. And then once you have those personas, you can spend time identifying “what are the tasks they are trying to complete? What are the pains that they’ve got today? And what are the outcomes that they are trying to achieve with the gains that you’re trying to achieve?” And once you’ve got those tasks, pains, and gains you can prioritise them: what’s essential, and what’s nice to have? And involve the business and the people that represent these personas; have we got it right?
Do the work and then test it. You can then, once you’ve got that that agreement, that “yes, these are the things that we are trying to achieve, and that we need” to start mapping out how the changes to processes, policies, systems, org structures, whatever is going to alleviate the pains, help them get to the gains and create that mapping. It won’t be a one for one process, there will be things that you programme will not address, but be clear with people. Say upfront: “we are going to help you achieve these things. We’re going to take away this pain. But we’re not no address how you book your expenses, because it’s not in scope.” But that really does help engage people up front, to set the parameters, that design, the architecture, that you need to put in place, and it allows you to prototype that, even before you get to the systems. Just be clear with people: “okay, we’ve drawn some stuff on paper, this is our description of how the world works, and we’ve tested it along the way. Does this look right? Is this going to help you deliver your profit number or revenue number? Is this going to help deliver your programme to your customer?”
Joe Ales: Exactly. This the technology we put in front of you, and you might have to make adjustments to that, based on the capabilities or requirements of the system. Sometimes to deliver one of those outcomes that you express at the very beginning, you say “this is really important that people do this” it is really important that people get in a room, before any technology is put in front of them, to do this. This is not a type of activity that you do with the system partners in front of you. This is almost what we call “phase zero” – getting the groundings right for getting a system integrator into a room, or partner, to start making design decisions. It will help you make those design decisions; those workshops will be a lot run a lot smoother, you’ll crack through the activity a lot more effectively, than being in a room trying to make design decisions on a fly – don’t do that.
Jason West: And seek some professional facilitation in those meetings. Unless you’ve been through this process, it’s very difficult to find your way through it, as well as facilitating the session. So it’s worth bringing in outside help.
Joe Ales: And if you’re bringing in outside help that have got experience in a technology that you’re trying to implement, that will help you mitigate some design decisions that you might be making in white space. They might say “actually, don’t waste your time making that design decision, because the system is not going to be able to cope with it.” Whilst you don’t it’s not about doing stuff on the back piece of paper, because technology will come along, especially when implementing a cloud system – Oracle or Workday or other cloud based tech – they are restricted. They don’t have huge amount of flexibility, you’re not designing in white space. This is about getting the principles right, and sometimes when you’re in the midst of designing in technology, it’s okay that processes, new systems might change, because the user experience wouldn’t be great. But it’s okay; you’re going into it with a core set of principles about “right this is what I want the future state to look like, and it will deliver these benefits.” Now, technology supplier, or technology vendors, help us achieve that.
Jason West: Yes, but you’ve had that realism as part of your overall customer centric design, with some input from somebody that knows what the constraints are of the system that you’re going to implement. Because there’s no point, as you say, designing some fantastically wonderful blue sky set of services or processes if the technology just can’t support it, just doesn’t do it, or it doesn’t do it in that way.
Now, we did touch upon how you go out, and how do you get the business engaged in these design workshops and put them in the room. I think there’s that business interaction, but there’s also, in any sizeable organisation, especially in international organisations, there’s that dynamic of global, of countries, regions and then business lines, business units, divisions or whatever. And finding a way of building a set of design governance or design inputs, and testing and feedback, that allows you to have a small focus group of people in a room, able to make decisions quickly, but then those can be very effectively tested out with a broader group. In the past, we’ve used a global process owner model. So you have global process owners, country process owners, or business unit process owners. I think it’s probably worth just touch on some of the ways that works, and why.
Joe Ales: Definitely. It’s especially useful in federated businesses; implementing global design in federated businesses isn’t easy. A lot of these systems or processes, you’re not designing a process at level two, you’re designing a process at a fairly detailed level, because the system is going to do an awful lot of the transactional processing of data for you. And a lot of countries have got clearly got their regulatory constraints they’ve got to sort of abide by. And naturally, the global process design needs to take into account the regional nuances, always. It’s normal. It’s just that those nuances can’t become the design, and the global process owner has the right, I guess, the gravitas to say that.
Jason West: Yes, people in that role need to be well respected within the organisation, they need to be well connected, known.
Joe Ales: Yes, because they are ultimately accountable for making the design decision that takes into account various country perspectives, or business unit perspectives, whatever those might be. Even in a single country, in a federated business model, different business units in one country are operating differently, on different brands etc. how do you bring all of that together? It is not easy and especially if your “as is” world is everything is done differently everywhere. Moving to a common platform can be a challenge. Expenses might get approved by 50 people in one business unit, and no approvals in another, and how do you get to a common place, a common governance structure, or common delegation of authority in spend? Think of these things right up front, don’t be surprised when you’ve got the system integrator in the room asking you a question: “so what’s your delegation of authority on spend?” And your response is “I don’t know.”
Jason West: Yes. “Well, it’s this in this country, it’s that in another country. But in this business unit it’s this, in France it’s one thing, but somewhere else it’s another.”
Joe Ales: Exactly, that programme would be a nightmare. You’ve got to align policy, align processes, align principles, and do all that work up front.
[Intermission].
Jason West: It’s possible to build that level of complexity into the system, it’s just going to be a nightmare to support. It might add some value but it’ll probably be problematic down the line.
Joe Ales: I would doubt, that for any organisation that is going through a transformation programme of any kind, would want to retain that level of complexity.
Jason West: But you see it happen.
Joe Ales: Yes, you do in some areas, absolutely. But this is a good opportunity to address the issue. And I will say there are times when it is valid. There are some really good business reasons why you’d have something that is different, because there’s value in it. We always talk about, with design principles, well if you create something that creates so much value, whether it’s a policy, or process, or a way of working, if something creates so much value in an organisation, in the business unit, in a global business, could the same value be recreated across all the other business units? It’s question that you have to ask: if it’s so valuable for that business unit, why can’t we employ that same thinking elsewhere? It’s having that sort of flexibility in your and agility in your in your thinking.
Jason West: Yeah and I think having those having those feedback loops is really key. So as the sponsor or a transformation lead, as a programme director I’d want to know that the global process owners are having these regular, weekly conversations with the group of country process owners, and they’re looking for these opportunities to take good or best practice. To reach these compromises, and that those regular drum beat of process owner decision making groups are meeting regularly, before you get to designing technology. So they need to have formed into their own mini team, and they know each other, there’s trust there and they’re able to work through problems together effectively.
Joe Ales: What will happen, if that engagement doesn’t take place, is you implement a global process, or so it would seem. Because actually what’s going to happen is that the local countries will retain their local ways of working, that local systems, the local tools, local processes, and they’ll probably feel – and many of our listeners might not agree with this – but they might feel that actually something’s been imposed on them from corporate or group. “We’ll have to update the system just to keep everybody happy, but actually locally, we’ll keep doing whatever we’ve been doing for however long.”
Jason West: Yeah, and unsurprisingly the benefits aren’t realised.
Joe Ales: No, the benefits aren’t realised, changes aren’t embedded and actually this adds operational inefficiencies and cost.
Jason West: So as a practical tip for a transformation lead, make sure you check in with the country process owners. Just do dip checks here and there, just make sure how it’s going, what’s happening; just get their feedback and if you find these regular weekly meetings aren’t happening, you need to intervene.
Joe Ales: Yes, and if a sponsor is sitting there nervous about how this is progressing or how this is landing, and is our message landing across the countries, business units, are they taking note of what we are doing? Maybe set up a call and invite the entire programme team: the country representatives onto a team and just have a chat with them.
Jason West: And sponsors having a random chat with people – please do it.
Joe Ales: Absolutely, set up dialogue channels. Set up channels of dialogue with the extended project team. And it is just to make sure that the country project team takes accountability, or the business units take accountability for what they are being asked to do. Because, especially in global programmes, it is easy if you’re in a very remote country at the tail end of an organisation, and go “this doesn’t really impact me. I’ll just attend the call here and there. I’ll deal with it when it when it lands.” It’s not great.
The other thing, actually, when talking about design, especially in large organisations: do global design. Especially in organisations where you are perhaps phasing the deployment of something. Don’t pilot it in just one place; don’t do a pilot and design the processes for this particular country, and then roll it out globally. Do global design. In an organisation that wants to implement change globally, make sure you do global design.
Jason West: Yes, because otherwise you have a pilot country with a whole set of processes that might be perfect for that country and they’re rolled on to the next one and it all changes. And you roll in on to the next one and it all changes.
Joe Ales: In the end you have 15 different iterations of design.
Jason West: And I’ll guarantee that at some point you’ll go “we need a different instance now. We’re going to have to have a fundamentally difference version of this technology, as it’s just so different here.” And it goes wrong. I’ve seen many, many programmes where systems get designed and actually a lot of it is not even transformation, a lot of it is maybe an operational system. An operational system replacing a legacy system gets designed for a business unit, constrained to small group of people, and they design it beautifully to fit all their practices and processes and they try to it roll that out. You’re going to get resistance from the business units your landing this into, saying “you’re not taking into account my requirements.” But just be mindful. Anything you’re trying to design, design globally. Even if it doesn’t hit that particular region, or country, or business unit until two or three years down the line.
Jason West: Absolutely, involve them in requirements gathering and in the design right up front.
So we’ll draw to a close in a second. But before we do, and I’m sure we’ve mentioned this on other episodes, but the point bears repeating: as you get into this system design, you need to be really clear about the roles of the people involved. And very specifically, the role of your process owner/owners, and the role of the system implementation partner. In really simple terms, Joe, what is the role of the system implementation partner?
Joe Ales: To build the system to you specification. That’s it. To configure the system. That’s it, that’s all they do. They sit in front of you and ask “what would you like me to do? I’ll give you options if you’re contemplating certain things, as to what system can and can’t, but it’s not my decision.”
Jason West: It is the process owners who are accountable and responsible for making the design decisions, that affect how efficient, how effective, how robust the system design, the data that it produces, the outcomes, the benefits to the business. It is not the system integrator.
Joe Ales: And the system integrator is not going to give you best practice on processes. They will have a view, because they would have designed many processes in other organisations, when they implemented the system in other businesses. But they are not prescribing best practice and many organisations make that mistake. They think that the system integrator is there to guide them on what this good looks like. But you need to have defined what good looks like, yourself, in phase zero: your destination. You need to articulate what your destination is, before you sit with the system integration.
Jason West: So, because that accountability sits with the process owners, you’ve got to make sure that the people that you seconded into those roles have got the skills, the tools, that knowledge, the mindset even, to make the best possible architecture design decisions that they can. And to take personal ownership, and accountability for the outcomes of the decisions that they make. They also need to be comfortable that they’re not going to get right first time, and what you go live with is going to need further work, it’s going to need further iteration. And they need to be leading that charge as the programme team.
Joe Ales: That’s right. A lot of these individuals are, in many cases, responsible for an operation. You’re asking them to be a global design thinker, and sometimes the mindset isn’t there. So, before you venture into running these workshops and facilitating workshops, make sure that these individuals are skilled and equipped. And there might be the right person because of where they sit in the organisation, because of the corporate knowledge that they hold. But equip them with a different set of skills, design thinking skills, managing conflict – because that will happen- influencing without authority; so getting decisions without necessarily having authority.
Jason West: basic project planning, project management. Not PRINCE2, but understanding the difference between risks and issues.
Joe Ales: I think you need that toolkit to go alongside the responsibility and accountability that you hold. So make sure programme sponsors, programme leads, workstream leads or your process owners have got the toolkit.
Jason West: Yeah, absolutely. So, in summary: for this week’s episodes we’ve covered off the fact that you need to have done the work during the scoping phase, to define your vision, your design principles, your strategic objectives, that are going to really drive but this architecture, design work that you’re going to do. You really don’t want to be making those decisions as you’re doing detailed design, so do it upfront. Even if you haven’t done it during scoping, give yourself time to really get those big architectural pieces in place. And make sure your process owners are absolutely in place, that if you’re a global organisation that you have clearly defined global, country, and business process owners and that those teams have been well formed before you get into detail design. And assuming that technology is in scope, and it generally it is in these things, before you get your system integration partner or implementation partner engaged, make sure you’ve really focused on that customer centric design. So you’ve worked it through, you’ve engaged people in the business in that that high level design, you’ve prototyped things, you’ve got that feedback, and done as much alignment as you possibly can, before you get into that detailed design.
And the final thing is, as you’re into that system implementation, be really clear about what your role is, as the customer, and making those design decisions. And what the role is of the implementation partner; which is to turn those decisions into technical reality – and that’s it. And the final thought to leave you on is to make sure your programme teams have got the right skill set, toolset, mindset to be effective in these new roles.
Joe Ales: It’s a nice huge topic; we probably just skimmed the surface of it.
Jason West: Absolutely. And staying on the topic of implementation partners for next week, they’re one of a multitude of suppliers that you would probably have on you transformation programme. So next week we’re going to talk about how to get best out of your suppliers that support your programme team and your transformation. So please tune in next week.
Joe Ales: Thanks for listening. We really appreciate your support. This episode focused on one of 10 critical success factors in the build phase of transformation. If you’d like to be at the front of the queue for next week’s episode, please hit the subscribe button and don’t forget to like the show if you found it useful. If you have any questions or opinions you’d like to share, please contact me, Joe Ales on LinkedIn, or visit our website: underscore-group.com.