Joe Ales & Jason West
Season 2: Episode 5 – Getting the Best Out of Suppliers
Joe Ales: Welcome to the Underscore Transformation Podcast. My name’s Joe Ales.
Jason West: And I’m Jason West.
Joe Ales: Together we’re the founders of Underscore. In season two, we’re focusing on implementation and the challenges that surround designing, building and testing your business transformation.
In today’s episode we consider the integrated team of suppliers that are involved in delivering a transformation. And a common trait of transformation programmes that get into difficulty is the misunderstanding and confusion surrounding the roles of the internal programme team, external management consultants, client-side advisors, technology vendors, and system implementation partners. So, Jason, how do we avoid misunderstandings and stop ourselves reaching for our lawyer friends at the first signs of trouble?
Jason West: Good question; if you’re calling the lawyers here, though, then we’re in real trouble [LAUGHS]. Unsurprisingly, it starts with scoping the programme correctly. And as we talk through this build phase, we will keep referring back to scoping, because if you get the scoping right the build is significantly easier. During that scoping work you really should have already mapped out the various parties that are going to be involved, at the various stages of your programme, and being clear about who’s responsible, accountable, consulted, and informed at each of those critical steps. And wherever humanly possible, you should always make sure that those RACI models are absolutely defined within the contracts that you have with your suppliers. So you have statements of work that clearly define who is responsible and accountable for each of the various activities, that your integrated team is going to fulfil together. That’s the contractual side, and you really need to have sorted that out before you get to kicking off your implementation.
But on that point, before you involve a wider group of people in a kick off, or a launch of your transformation programme, you really do want to get your integrated programme team together. That’s your internal project team members, any systems integrator, technology vendor, management consultants, external advisors, anybody that’s going to be part of this integrated team with a role to play. You want to get them in the same room, at the same time. This might mean flying people in from other countries, but getting them together right at the beginning, and being really clear with them about what we’re doing, why we’re doing it, and really stepping through that RACI, to be clear about who’s doing what. Make sure there aren’t any confusions, any overlaps, that stuff doesn’t fall between the cracks in these different teams is absolutely key.
Joe Ales: In last week’s episode, we actually made reference to ways of making sure that people don’t misunderstand the roles and responsibilities of systems integrators when making design decisions. It is important to have, at the very beginning, at the very outset, clarity about who is responsible for what, so that there is no ambiguity when inevitably you are going to have some difficult conversations along the way. Because these things are never plain sailing,
Jason West: Yes, and on that point, as you go through these programmes, at times things get a bit difficult. Relationships can get strained, and investing the time up-front, by getting people together and agreeing, not just who does what, that’s important obviously, but also how we’re going to work together. This is a team of individuals at the end of the day; they work for different organisations, they’ve got their own personal objectives, their own commercial drivers, but they’re working together towards a common goal. Or at least we certainly hope they are. And investing the time up front to make sure that we agree, together, what are we doing, why are we doing it, where we going, how we are going to get there, who’s going to do what. But also, how we are going to treat each other, behave, how we work together, and getting that formed up into a team charter. A set of green card, red card type behaviours at work.
Because you do have these different priorities, these different drivers, and starting to tease some of that up-front and get to that common understanding, and then agreed way of working, will make it infinitely easier. If you’re on a call at 11:00 o’clock at night deep into the heart of testing, and you’ve got somebody that’s desperately trying to fix the problem halfway around the world, on something that you need to sign off, or go live, or whatever it might be, the fact that you’ve sat down together, you’ve met face to face, you’ve agreed where you going, why you’re going there, and have some fun.
Joe Ales: And the point is, this is a really important in twofold, one is interms of roles and responsibilities and making sure that there is no ambiguity in terms of “what am I here to do? And what are they here to do?” The second point, actually, is one of collaboration. This is an integrated programme team. For the programme to be successful, every single component of it, every single element of it, needs to be facing in the same direction and working to the same goals. But if you start to develop a “them and us” culture among the programme team, you’re on bad ground, you’re on the backfoot already, because everyone will be watching their backs.
Jason West: Yes. There are some really good frameworks out there around the collaboration; there’s the relatively new ISO44001 to get the very structured approach. There some useful stuff in there that’s worth having a look at. And we’ve talked about it in the first episode of this season: the work you need to do around resourcing your programme, and documenting roles and responsibilities and why that’s important. I think at this stage it becomes really important, because before somebody is seconded onto the programme into subject matter expert role, or a process owner role, or whatever it might be; before they can really start to understand what’s the role of the system integrator, versus the technology vendor, versus this management consultant, they need to understand their role first. They’re not going to be in the right headspace to really get what are all these different people doing. “Well what am I doing?” Start with the individual. You’ve got to get them comfortable.
Before you get to that kick off meeting, you really do want to have sat down with each of the individuals, and make sure they are clear on their role, so they can devote the time when they’re together with these other people, to forming relationships and actually forming up as a team, rather than worrying about “what does this mean for me? What am I going to do?”
Joe Ales: And equally important is establishing, at the very outset, people that are brought into the programme, seconded into the programme, they haven’t been involved in those relationships, maybe in the vendor selection processes. They haven’t established those relationships with those vendors. This is not the first time that the vendor would have met with that organisation. It would have been a process; there would be a procurement process that way for the way back then back when, that members of the programme team would have created strong relationships with, and when they seconded individuals onto the project for the first time, this is the first time that they see the whites of the eyes of the people that are going to help their organisation achieve their goals.
You need to invest time and effort in building a culture and environment of trust and collaboration, and friendliness, among a truly integrated team.
Jason West: A truly integrated team. And spending time on forming this group of disparate individuals from different companies together as a properly integrated team that share common goals, objectives, and ways of working. Get that right up-front and life becomes a heck of a lot easier. And that’s probably one of the first things you can do, to not have to reach into the drawer and start pulling out contracts to beat up the supplier with. The other side to is, it’s great do that work up-front but you have to keep working at it, and either the transformation lead or the programme director/programme manager/combination the two need to work hard on monitoring individuals’ understandings. Not just within your internal programme team, but the understanding, the expectations, the behaviours of the integrated programme team. And, where required, they are going to need to take intervention steps; maybe it’s a particular individual in one supplier that’s going off in a bit of an odd direction, but you need to manage that in the right way, in the way the ways that you’ve agreed with that suppliers, project manager, management chain, whatever it is, how you’re going to deal with that these sorts of issues. But making sure those misunderstandings don’t start creeping in and stuff doesn’t fall between the gaps.
So I think constant checking in and management of the individuals and the team as being an important focus, as well as on the task at hand. It’s very easy for programme teams to become incredibly task focused, incredibly outcome focused, and they might forget the people elements.
But say we’ve held our kick-off, we’re managing the individuals and the team, we really do need to think a bit more about structure. So, what are the key groups of individuals, and suppliers, that make up an integrated programme team?
Joe Ales: Obviously you’ve got your internal programme team, and we’ve talked at length, in previous episodes, about what those roles are: programme leads, functions leads, process owners etc. And all that needs to be documented, there needs to be clarity as to who is accountable for making what decisions. Because the suppliers and the vendors, they are ultimately producing something for you, and they need to know who to turn to when they need some guiding light. Then you’ve got other groups of people, depending on the size of your of your programme, that you made draw on. So management consultancies, for instance, and interestingly many of management consultancies out there that have got capability on both the system integration space, so making configuration changes to products, but also they’ve got experience in change management and programme management, and fault fulfilling the role that perhaps should fall client side. And it is really, really important that clients that engage big consulting firms to execute the system implementation for them, are very, very clear in terms of what role are they [the consultancy] there to fill.
Jason West: Yes, because the role of management consultants, really, should be in that advisory and guidance, and helping to find the strategy. So bringing in people with expertise in your corporate function, whatever that might be, they’re there to help you define the strategy, but it’s your decision the define your strategy. No external person is going to tell you what it should be.
Joe Ales: Yeah, and if they are, you shouldn’t accept it.
Jason West: Yes, warning bells should be going off. They are also there to help you work through your target operating model design, and how that fits into the overarching enterprise architecture. And like you said, bringing in that best practice insight, recommendations, and they do, and can, play an active role in change management, as you say. But it’s not just the big four; there are many specialist boutique firms out there. Some focus just on strategy, some just on target operating model design, some just on one functional area or the other. There’s lots of different ways of cutting that up. But that role of management consultant, for want of a better term, could be fulfilled by a senior interim, or an experienced contractor that’s got the experience of running these types of processes.
I think it’s probably just worth thinking through that we’ve talked quite a lot about the solution design accountabilities within the internal programme team, but it’s more than just making design decisions isn’t it? A programme team is there, ultimately, to make sure you deliver the benefits and committed business case. But that also involves some technical stuff as well, because it’s the your internal team that need to ensure that whatever gets created, is fully tested, it’s been validated as meeting business requirements. So it’s not just verified that “yes it meets the specifications”, but it’s been validated that it’s fit for purpose, that any change – business change, people change – has been effectively delivered: that people are adopting new ways of working, for example. And then right upfront, it’s often the internal programme team that is accountable for extracting data from current systems, cleansing it, transforming it, and then loading it into whatever your new technology is. So there’s actually an awful lot of responsibility and accountability and work that sits on the internal programme team side. And I think where organisations can get into trouble, is where they expect that a lot of that work is what the implementation partner is there to do, and they don’t adequately resource the internal programme team. They assume that just seconding some people in, who are experts in ‘procure-to-pay’, ‘order-to-cash’, or whatever it might be, just getting those subject matter experts in is enough, they don’t need to worry too much about data analysts, and business analysts, and testers, and test managers, and all this other stuff. But accountability sits with the client.
Joe Ales: Yeah I mean, if we think about it, the majority of the accountability of delivering and executing the programme sits on the client side. So if we look at it in its broadest sense, the client is expected to deliver data in a format that is transformable, into the destination system that’s being procured. That’s the responsibility of the client, to make sure that data is good quality, so that’s an awful a lot of work that needs to be done around data quality, and so on.
It’s also the client’s responsibility to make the design decisions. We talked a little bit about advisers, in terms of people that have been there and done it, to come in and help the client make sensible design decisions. Because those implementation partners, that receive instruction about what the client wants, they can provide options, but that’s where their responsibility and accountability stops. The other one is delivering the technology solution; the system integrators, the systems partners are not going to sit there and give you a testing strategy. You’ve got to create the testing strategy yourself, then you have got to test it yourself. They [integrators and vendors] will do their own testing to make sure that the configuration that they’ve built has been done well. But ultimately, it’s your responsibility, on the client side, to make sure that you’ve tested the system, and the processes, or whatever you’re implementing, to death. And also, change management. It’s not the system implementor’s responsibility. It’s a client side responsibility to do that.
Jason West: I think one that often gets confused, is around integrating your new system into the rest of the architecture. Often, the implementation partner is there to build an interface out of their system, or into it, but they’re going from their system, out to something else. They’re not there to make the changes to a target system, to accept that interface, and make sure the data arrives in the right format. They’re really just working from their system; either with information coming in or going out. It’s actually the client who is accountable for the end-to-end operational integration, or interface.
Joe Ales: Yes, and if you’re implementing a system that affects the entire enterprise architecture, and you’re bringing in integrations in all sorts of different things, with different suppliers, you’ve got to engage the suppliers of those systems as well, in your transformation. Because ultimately, you might have to make changes to systems of records that you’re integrating with. They [integrators and vendors] are there to give specification of what data do you want to go where? In what format? And frequency of it? That’s what they will do.
Jason West: And on that topic of other vendors, there’s the suppliers that provide your current services and systems, that you are perhaps retiring. So you need to think through: “we must read the contract before we think about talking to them about terminating it. What support do we need from them during the life of this programme and beyond? And how do we make sure that we have the right commercial discussions, at the right time, to ensure that we get what we need? And there’s an equitable commercial arrangement that they are comfortable enough with, that they’re going to do when we need them to do?” That’s something that can often get forgotten, and even during the business case phase, we make an assumption that we can switch off this system as soon as we go live. But hold on, we’ve got a contract that says that we owe them for the next four years. So it’s important to think about not just the vendors to your programme, but vendors of legacy systems and services being provided today.
Joe Ales: We’ve talked about the business case in previous episodes and the need to be very clear about what you’re trying to do, and the total cost of ownership around systems and so on. And not get too technical here, but one of the key things to think about when you talk about vendors, and particularly around technology, is if you’re decommissioning a piece of software because you’re implementing something else, be sure that you can decommissioning it. Not just from a contract perspective, but actually from a data standpoint; legacy data. And don’t just assume that you can decommission something at the point that this is this new system goes live.
Jason West: Yes, because not all the data might be in it,
Joe Ales: Different data architectures, all sorts of different things that will prevent you from migrating that data settings in its entirety. And then, guess what: the assumption that you made in your business case, that you were going to retire something, won’t happen. Be sure that before you start talking about retiring systems in your business case, that you can.
Jason West: [LAUGHS]. It’s brilliant; only you could take the conversation about vendors, and turn it into one of that data.
Joe Ales: You started talking about integrations. [LAUGHS].
Jason West: In the context of partners, I didn’t start going on about legacy data. [LAUGHS].
[intermission]
So, we talked about the internal programme team, we talked about management consultancies, and implementation partners. Now we need to talk about client side advisers.
Joe Ales: A really important group. These can be your sounding board, a voice of reason on your programme.
Jason West: Or at least bitter experience.
Joe Ales: Yes, yeah they’ll probably be bitter. They’ll probably be asking really difficult questions of the programme team. They dig beneath the surface, and this is not about picking holes in anything, their role is there to make sure that the programme achieves what it is trying to achieve, based on the experience they’ve got.
Jason West: But you can plug them in at different levels, can’t you. So I think there’s two options: you either put them into the programme team itself, to the design authority, to the process owners, as that sounding board, as that external advisor that’s talking to them about best practice. They can say “oh you might be thinking you could do it that way, but here’s the operational impact that I’ve experienced in company Y.”
Joe Ales: And that’s where they will have the most impact, they’ll have the most impact at that level. Not offer a huge amount of detail, but really helping shape thinking. The other option is to plug them into an executive steering committee.
Jason West: Yeah, so it’s either you plug them into the design boards, and the design decisions, or you plug them in at a governance level, with that operational steering committee executives, executive steering committee, or the programme board. It’s one of those two: either the programme border, or an exec steering committee.
Joe Ales: And that could work. But the challenge is, just using that as the channel is, how do you influence design? Because a lot of the design is probably being made elsewhere. So it just it does becomes a QA type role, which is important, but if I was a sponsor, I would look to have something alongside me, someone that understands the trajectory that we’re going on, and where the trap doors are likely to be. So that I can prepare myself, my programme team, and so on, everybody around me, about 2well these are the issues that we’re likely to encounter”.
Jason West: But it is not an ‘either or’, is it. You can have somebody at both executive steering committee level, and at the operational design level that’s really bringing that experience in. So, you’ve got the person at the exec level who’s asking those really horrible, probing questions, that as a programme manager or the transformation lead, you just don’t want someone asking you. So, they’re there to ask the difficult questions and bring that external validation, that what’s being designed within the programme is actually going to work. But then the design teams have got that external perspective, from a different individual, that’s helping them make those really well-founded design decision. The challenge that is coming in through, perhaps the external advisor during the exec steerco, are being well answered. So you’re not reliant on a really experienced individual just catching things at the exec steerco, you’ve also plugged in somebody, potentially equally as experienced, but a bit more operationally focused, a bit more in the detail, to make sure that things work effectively in that design space.
The final supplier is your new technology vendor. So, what are they there to do?
Joe Ales: Technology vendors are there to provide the technology. They’re not there to design your processes for you. They are providing technology as a service: “here’s a kit that I’m going to give to you, use a system implementation partner to configure it as you wish, within the constraints of the capabilities I’m giving you as technology”. But that’s all it is. Clearly the technology vendors are designing things on best practice, using lots and lots of customers to beta test certain designs, so that they’re always evolving their product to meet the latest thinking around finance, procurement or HR. But all they are there to do is to provide you a platform.
Jason West: So they provide that platform, then they need to make sure that it’s as a bug-free as it can be, providing that third level support to you as a client, and that it gets enhanced in the right way. So, as a customer of that vendor, it’s helpful if you’re really engaging with whatever their product development process is, whatever their user groups are. Even though we’re talking about implementation right now, get involved early.
Joe Ales: Yeah, influence the road map. And actually, for large enterprises and for large corporations, technology vendors will be keen to get those individuals involved anyway, to develop products, to help them develop their roadmap. The technology vendors have also got a vested interest in this thing landing well, so they will often, in some cases, some technology vendors will play a role of sort of quality assurance: making sure that the system implementation partners are doing what they need to do. That they’re making the right configuration design decisions in the system.
Jason West: Yeah they keep tabs to make sure integrators followed the right implementation process, and tick the right box to make sure it’s done well.
Joe Ales: But they’re not there to make sure that you’ve done your change management. They’re not quality assuring your programme, let’s be clear. They are quality assuring that the products has been configured in the right way according to their criteria.
Jason West: Yes, and they are not quality assuring the design.
Joe Ales: No. So if you have got 7000 lines of objects that you created, they’re not sitting there asking “Are you sure you want to create 7000, when 20 would do?” They assume that if you’ve got 7000 there must be a good reason for you requesting 7000. They’re not questioning that, they will just say “I’m just going to make sure that the 7000 have been configured and setup correctly in the system.”
Jason West: I think this is where your client side advisors come in. They would be the ones that are saying “hold on 7000 is not quite right. You’re going to have these issues in operation, this is going to be a nightmare to support, actually reporting is going to be horrible”.
You’re not going to get that from your technology vendor. You need to get that from elsewhere. You can do without it; all that means is that you will get the same solution eventually, but you’ll learn it in production, when everything’s live in front of a live studio audience, with the CEO looking at their pay slip going “why is this not right?” and all those fun things. So that’s where the value comes in: stand on the shoulders of giants wherever possible.
So there are the nicely set out roles. But you’ve already touched on where a management consultant organisation can have an implementation partner, and being clear about where the differences are and asking upfront: “are you acting in the role of our management consultant? Or in the role of our implementation partner?” Because even though the name across the door is the same, they’re totally different teams and often in these partnership models they really don’t talk to one another.
Joe Ales: Yeah, they’re different individuals.
Jason West: So be clear about what you’re contracting for. But the other thing is around vendors, technology vendors. Because some of them have implementation teams, so you need to distinguish between “am I talking to you as a technology vendor or as an implementation partner? “And just make sure that you’re clear about in what roles, which individuals, who you’re engaging, as it can be really easy to get all that very muddled and things breakdown very quickly.
Joe Ales: Yes, we talked earlier about this team charter; call it out. Ask: “if my technology vendor is also my implementation partner, who do I go to? Is it the person standing in front of me who’s doing the configuration? Or is it someone?” Be clear what the escalation points are in those situations. And, likewise, if you’re using your system implementation, and management consultant, you’re using the same brand to do the same thing, that they are different teams, they are different individuals.
Jason West: They will often have different contracts. They will be contracted separately, and they are usually written very, very differently, because they are fundamentally different services.
Joe Ales: It’s interesting though, isn’t it, for organisations that engage the system implementer and management consultant at the same time, contractually, and just be very mindful of how that would work. There are some pitfalls along the way, where that consultancy firm is accountable for delivering both. Be sure that you stay on your side of the fence, client side; they’ve got plenty of QA assurances, and checks in place, to make sure that everything is going according to plan.
Jason West: When it comes to managing these relationships, especially if you are a large, strategically important client to either a management consultant, implementation partner, or a technology vendor – or in certain circumstances, all three – oftentimes they are very keen to play an active role in your government structure. To have individuals from those organisations sat on your executive steering committee, and it can seem great, you might think “wonderful; Deloitte or KPMG or whoever they are, are going to send a senior partner in to our exec steering committee. Isn’t that great”. But there are pros and cons.
Joe Ales: In the true spirit of collaboration, absolutely it can work, transparency and so on, it does have benefits.
Jason West: But if you’ve got a problem with a particular vendor, and they are sat in the exec steerco and they have to stare into the white of the eyes of a client, it can be useful.
Joe Ales: Exactly. But it can be counter-productive in some areas. You might have constraints on budget; when you start talking about financials of the programme, never have these individuals involved in the room, at that point.
Jason West: They have commercial drivers, and aren’t suited that that topic.
Joe Ales: If they are part of your exec steerco, be sure that you segregate discussion, for example programme points and maybe financial points, or business strategy points, that are driving the transformation that you perhaps don’t want to be publicised and known externally outside the walls of the exec.
Jason West: Yes, and you’re often making significant changes to team structures, and numbers of employees. So is it appropriate to have those discussions with an external party? Absolutely include them in the right way, maybe in a separate forum, with the executive sponsor, and give them access to the exec, because it is really valuable having those relationships at the executive level.
Joe Ales: But be mindful about the role that they play in the governance of the programme. The exec steering committee is there to govern the programme, and to provide executive direction to the project, and sign off and so on. And there are different ways, different mechanisms of engaging them. They absolutely need to have line of sight and a channel into the sponsor: it’s vital. The sponsor needs to feel they can pick up the phone, and speak to somebody, one of the suppliers, and that relationship and dialogue needs to be encouraged. But in a formal governance structure I would be reluctant to include them for the entire meeting.
Jason West: We were going to touch on governance, actually not just touching on, we haven’t quite an indepth discussion about governance, in future episodes. I think it will be the last one that we touch on in this season, but we will revisit this topic.
So that’s your large, strategic important clients. At the other end of the scale of small to mid-size enterprises, they might not have enough budget to engage a management consultancy to provide that input during design or to sit on exec steerco. If that’s the case, what can organisations do, where they don’t have the budget to go to a management consultancy, and get that input on design?
Joe Ales: Get client advisers in there. Hire a client-side adviser; engage with somebody that’s been there and done it before. Go out and get individuals, that have been there, done it, to work alongside your programme team, who have probably not experienced or done this before, and then use that expertise. And there’s plenty of expertise in the market, without needing to go the big consulting firms.
Jason West: Absolutely. And I think a good thing to do, and we’ve spoken about it previously, is make sure your process owners go out and tap into their networks, and go and visit other organisations, to see what good looks like elsewhere; get ideas and give them space and time to actually go and do that work, do some reading, do some investigation, some research.
Joe Ales: And client advisors can help unlock those types of exchanges; these individuals will have a network themselves, so bring in the client advisor to help you stay on track and that you don’t do anything silly to hurt yourself. And can you leverage them and their network, to open opportunities and to network in other organisations? And that, in itself, will be valuable.
Jason West: So, I think if we just stepped through to, how to get the best out of these suppliers. And I think the first thing to say is, you actually have to proactively manage their performance, and you need to have checkpoints within your programme, to have commercial discussions that are beyond your day to day delivery of the project or programme discussions. Here you talk about performance, and issues, risks in terms of the commercial relationship. But it’s always beneficial, wherever possible, to ensure that all parties involved in this phase of the programme, can see a path through to this as a long-term relationship. There’s some ongoing opportunity for revenue, there’s an ongoing opportunity to continue working with these vendors, with you as a client. Because obviously to the vendor, there’s a potential for future revenues to secure, but also it really helps with trying to fix problems, in the here and now. If the parties believe this is just a one-time game, you’re going to have a different set of behaviours, than if they think this is going to be a repeat game, where there’s value in the relationship beyond whether somebody’s right or wrong on this particular point.
Joe Ales: And that needs to be set out way up front, when you create your contract, your business case. These types of transformation programmes rarely stop on day one of launch. So there’s always an opportunity to create a long lasting relationship, and we talked earlier about mentality and behaviours, and these types of things. If you don’t set those up right, upfront, the relationship will end once you’re live. And the likelihood is that they’ll be contracting opportunity for support services, through life support for whatever it is that you’re implementing, with potentially a different supplier. But having that continuity is really, really helpful as you transition, as you embed your what you’ve built. So having that long lasting relationship is possible, if you have the right behaviours throughout the programme, as you’re more likely to end up with something that’s win-win for everybody.
Jason West: As programme sponsor, one of the things you want to be looking at is, how does the programme team talk about the different suppliers? Do they take a transactional approach to the relationship? Or a strategic one?
Joe Ales: And the sponsor has a role to shape that, because the sponsor may well have a vested interest in building a long term relationship with that vendor.
Jason West: Yeah; if your programme team is coming to you with every single missed milestone, every defect, and it’s really breaking down into a “them and us” sort of dynamic, you need to address that very, very quickly. But that’s not to say that the programme team, or the programme manager that’s managing that day-to-day relationship with project management, programme manager, depending on which level, they shouldn’t be a soft touch. They shouldn’t just accept every change in scope, in timeline, in cost; they shouldn’t be signing off every change request without question.
Joe Ales: No, there are rules of engagement, so in a spirit of collaboration, yes you need to compromise, but we’ve still got commercial relationships between all the parties. We mustn’t forget that a supplier has a contract to deliver a particular service, and if it’s not delivering service at all costs. There’s the spirit if of working together, which is really important, but also understanding that there is a commercial relationship here, as well, and we mustn’t forget that.
Jason West: I think again this is where client-side advisors can come in, because if a programme team is not fully versed with what a supplier is doing, then then having somebody to constructively challenge change requests, as they come in, you can end up with a much better solution. Because it could be the individual functional consultant, if we’re talking technology here, has just thought about the solution in one way. And the one way is just to apply a whole lot of time to the problem, and that ends up with a quite sizable cost. Whereas somebody coming in from the outside, with a fresh pair of eyes, could say “hold on, you don’t need to do it that way. You could just make this change over here, and you know what, there’s no need to put those extra hours in. Therefore, there’s no cost change”.
Joe Ales: And actually systems/technology vendors will also appreciate the fact that they’ve got somebody there, client side, just being a voice of reason around change. The client says “wouldn’t it be great if we could do this?” The client advisers may well come in and say to the client “yes, that could be a good thing. But actually, the system’s constrained by XYZ, and by the way, if you implement that, these are the consequences in your BAU, so think very carefully about what you’re asking technology vendors to do”. It’s a role that can be positive on both sides of the camp.
Jason West: Yeah; one of the areas to look out for, is the change requests and the frequency that they’re coming in, and the other validity. And also the balance between how many are we approving versus rejecting? And if you’ve got too many that you’re approving, or too many that you’re rejecting, it suggests that you’ve got some problems somewhere in the relationship.
Joe Ales: If you’ve got too many change requests, in the first place, then probably the original design is not quite right.
Jason West: So the final piece is really around making sure that you’ve got adequate time, at the start of the relationship, to scope out that statement of work, with all the relevant people. And that you build in, especially with management consultants, and implementation partners, plenty of time for knowledge transfer as you go. Because in our shared view, the objective rule of suppliers, as far as you can contractually put it in, is to ensure the client is as self-sufficient as humanly possible at the point of go live. And unless you build that into your commercial negotiations in your contract, right up front, that’s not the default.
Joe Ales: That is an interesting one, because there can be a lot of ambiguity around self-sufficiency, because the client will absolutely be expecting to be self-sufficient from day one. But naturally, the way maybe technology gets implemented isn’t aligned to that. And it’s only it’s only at the very end, when knowledge transfer starts to happened that a client starts to take accountability for it. But it comes at a point, quite close to go live, where you don’t have all the tools, to support and sustain the system. So build it into the contract, right up front, and find the mechanisms to put in place that allow you to be self-sufficient when this thing gets switched on.
Jason West: And if you haven’t done so already, go back and listen to the previous episode, where we were talking about the future support model, and how important it is to start thinking about this stuff right now.
So, we’ve covered off a pretty broad topic. So when we’re talking about suppliers, and getting the best from them:
First use them in the right way, and make sure that everyone in the programme team is fully aware of everybody’s role, and different vendors, different suppliers and the programme team.
The different roles that there are, and how they work together.
Avoiding confusion if you’ve got suppliers fulfilling multiple roles on the programme.
How best to plug in different vendors at different levels of the organisation, whether that’s part of your governance or part of your design, and the different options that we’ve got there.
Managing the performance of suppliers and how best to focus on those long-term relationships. And some of the warning signs to look out for when it comes to change requests, and the volume of them, and how many you are approving or turning down.
And then the final pieces on knowledge transfer.
As ever, this is a huge topic we could talk at length on this one. But bearing in mind, this is 10 key success factors in a transformation programme, that at minimum is going to last a year. So it’s probably unsurprising that there’s quite a bit to discuss.
Next week integrations and reporting.
Thanks for listening, we really appreciate your support. This episode focused on one of 10 critical success factors during 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.
To learn about the Scoping phase of transformation, head over to season one and look out for future seasons on Transition and Optimisation. If you have any questions or opinions you’d like to share, please contact me, Jason West, on LinkedIn or via our website underscore-group.com.