Joe Ales & Jason West
Season 2: Episode – Build Your Support Model – Don’t Wait, Do It Now
Jason West: Welcome to the Underscore Transformation Podcast. My name is Jason West.
Joe Ales: And I’m Joe Ales.
Jason West: And together we’re the founders of Underscore. This week we’re talking about building your support model. So, if your transformation doesn’t include replacing or significantly updating technology, you can probably skip past the section. Well, you can if you completely satisfied with how your current system works, and you don’t need to make any changes, and you probably don’t need to make any changes in the future. But if you think you may, then it’s probably worth having a listen to the rest of this podcast. Establishing a robust technology support model is something that gets overlooked in a surprising number of transformation programmes. In the heat of programme delivery, attention naturally focuses on managing the latest integration risk, that design issues, or particularly challenging stakeholders. Yet your ability to deliver the business benefits promised by your business case, rests on how effectively you construct your support model. So how can a support model really be that important to the success of your programme?
Joe Ales: Well it’s very important. It’s the piece of the jigsaw that’s going to create sustainability of the change. We talked about this last time, in terms of the resources, the resources needed to execute the project well, all that capability and all that knowledge will walk out of the door possibly at the end of the end of warranty phase; which typically is month one, or month two post go live of your technology implementation. And if you don’t have the right team to configure change, adjust, and optimize those design decisions or manage configuration of technology, you’re going to struggle.
Jason West: How much change is there realistically going to be, do you think post go live?
Joe Ales: Day one you’re making changes. You know, hindsight is a wonderful thing, but you make you make a set of design decisions at the very beginning of a project, on a technology platform that you don’t really understand. And you probably won’t really understand the impact of the design decisions on that particular technology, until you’ve gone live. In some cases, sometimes you do find out, if you’ve already got effective testing – and this is again one of the key episodes in this in our series two, which is testing, testing, testing – but if you have not been able to identify certain nuances or sub optimal design decisions in testing, you will surely find amount in operation. And then if you don’t have the right team structure in place, well there two things of concern. Number one is the capability of the team, to be able to actually diagnose, understand the issue, and really come up with a set of options, that they can configure themselves, or potentially outsource to an application management support organisations, to configure against the requirements that you’ve specified. Those comes from the internal team, so that’s one point. And the second point is actually the change control: having effective change control mechanisms in place, that are not going to unwind an awful lot of decisions that you made you in design for good reasons, because you’re making a knee jerk reaction about something that doesn’t happen. So support model at the very beginning of the project is key. These individuals that are going to support the product need to be involved in the design decisions from the very outset. Again, we’ve seen it before, we’ve seen examples where the support model team pick up something, pick up a beast of a bit of technology that they’ve now got to manage. And the business starts to experience what this beast is like in the real world, and asks key questions: “why have we designed it that way?” And the support team don’t know, because they weren’t involved in the original design decisions, they just got landed with supporting it.
And naturally, the business asks difficult questions post go live, and the support team will typically go “that’s a good point, maybe we will change it.” And what they’re doing is they’re changing a fundamental design decision, that’s been agreed in principle at the very beginning of the project, that is to the detriment of the business case that was set out when they went when the decision to transform was made. So you need to think of our support model from day one.
Jason West: Absolutely. Because we’ve talked about the product meeting reality, and business demanding changes to be made, and some of those with good reason. But the other thing, unless you’re incredibly lucky, or you’ve planned it this way, you’re not going to be going live with the full set of functionality of your brand new ERP or HCM system on day one. It’s so unusual for that to happen. These are big, complex bits of technology, so day one you’ve got to have a road map: there is functionality that you couldn’t switch on day one, because you didn’t have the resource, or maybe you need to roll it out in a few phases; there’s often good reasons for that.
Joe Ales: Sometimes it’s too much of a change for it to hit the business all at once. So it’s normal to have different phases a programme.
Jason West: There’s a difference between follow on phase, where you’ve got a product that’s live with users, with data, with changes happening on a daily basis, with people transacting in the system. Versus your very first fresh green field build of the phase one. So, regardless, the support team’s involved in that, but the reality being that you could have a two year or three year road map to roll out all the different functionality, to all the geographies, to all the business units. And unless you’ve got a huge programme budget and you can afford to have a programme team in place for two/three years, it’s actually your support team that are going to be the people that will do the work, and make the changes happen. That demand from the road map is one aspect. You’ve got those “business as usual” changes, and all this time they’re having to support this product, in production. But you’ve also got the fact that, assuming that you’ve selected a cloud product, it’s going to update two/three/four times a year, and all those changes need to be understood. You’ve got to do regression testing, you’ve got to make sure that you’re not relying on some functionality that’s about to get retired, or that your integrations keep working. There’s constant work to be done. And I think that’s one of the things that organisations, often don’t quite understand until they’ve gone live with these new software as a service products. You’ve just bought into this strategy of continuous improvement, that your core systems will just update on a regular basis, whether you want to or not. So you need to be ready to analyse that change, to make the most of it, to adopt it, to make sure it doesn’t damage anything in your business.
Joe Ales: It’s very different to the old world of on-prem, where upgrades were painful, but took place in a controlled way, at the point where the organisation was ready to do the upgrade. And very often organisations just decided to not upgrade to the latest version of the Oracle ERP because it was too painful, and ended up finding themselves two or three versions behind the current version. With cloud, the Workdays of this world, don’t let you do that, so you have to be ready, you have to have the skills internally to have foresight about what’s coming down the line. And they need to work with the process owners, to help the process owners drive innovation through the technology. Because the support model is there as the technical experts of the product; they are there to make sure that the product doesn’t go down, the product is sustainable, is robust, they’re gatekeepers of the system.
The process owners are the ones that are driving innovation through their function, and the two of them should work hand in hand. In many of the projects that we’ve come across, when we typically ask the question of those programme directors and project sponsors in mid-flight of a system implementation “so where are you with your support model?” many times they had not even thought about it. And you’re running real risk here, because you don’t understand what you need, and haven’t factored that in – is it even in your business case? That is one of the things that is excluded from the business case.
There’s this idea that, because it’s “cloud,” it doesn’t need support. It’s like Facebook, nobody supports Facebook, nobody supports LinkedIn. Yet LinkedIn have a massive team themselves, developing the product and so do Facebook. So, there’s this idea that the products are self-maintained; they update themselves every six months, why would I need anybody here supporting it? It’s so, so wrong. There is this perception that these things are self-maintained and we need minimal teams. But, actually, in many cases, your support team will increase as a result of you implementing technology. Especially if you’re going from a legacy to a new cloud based system, with the rich in functionality in terms of reporting, security, different modules, mobile enabled, and all these great things that will transform your businesss, no question about it. You’re going to that, from something that’s probably a structured database on-prem, limited functionality, hasn’t changed the past 10 years, it’s a data repository, at best, for some organisations – that type of system requires minimal support. If you’re going into a full-fledged Human Capital Management (HCM) system, finance management system, with an array of functionality, if you don’t put a support model in place to effectively support all of that going forward, you’ll struggle.
Jason West: Hopefully that describes why this is important to think about this now, and that you really do need to put this front of mind as you’re getting started with your implementation. But how would you actually go about building that that technical capability, in-house? What are the different ways that we can go about that?
Joe Ales: First and foremost, you have to hire a team; you have to build it. And the best time to do it is right up front. Do it at the start of the programme. We’ve been in or seen situations where organisations don’t think about the support model until way, way down the line and it’s the wrong place to think about it;
Jason West: Normally it’s just before they are about to go live and realise suddenly “crikey, someone needs to be supporting this.”
Joe Ales: Yes, post go live is the wrong thing to do. You have to involve those individuals, that are ultimately going to support the product, at the beginning of your design. So hire the team at the same time as the project team; perhaps if you don’t have a support team in place, start with the person that’s ultimately going to be accountable for supporting it: the manager, the head off – bring that person on board.
You then need to start thinking of additional resources that are going to support different functional areas of the system; bring them on board too at that point. You are going to involve them in the design workshops, so they understand the rationale for decisions that have been made, and they ultimately understand why the system’s been configured in the way in which the system’s been configured. So that’s really important to give them the context.
The second part is to involve them in the configuration of the product.
Jason West: Yeah, though not all system integrators like this.
Joe Ales: They don’t, no and they don’t like it for good reasons actually. Because they fear that they’ll lose control over the configuration. Ultimately they [systems integrators] are accountable for delivering the quality product, and if they fear there are individuals on the client side that are meddling with the configuration, they are clearly going to get nervous about. S you have to establish that partnership model during the contract negotiations. During scoping. You have to agree, up front, what the relationship is going to look like, and how is it going to function when you’re in implementation, so that there are no surprises.
Jason West: And it’s likely you’re going to have to agree to some prerequisites around the individuals that will have access, so they will need to have gone through a certain amount of training on the product, for example, or have some level of certification if that’s available for the technology.
Joe Ales: It might be, that obviously cloud technology is developed through various iterations and various prototypes, and maybe it’s not prototype one, maybe its prototype two that they get involved with. Because clearly prototype one is a black box until it’s presented back to the client first time round. But maybe through the various iterations, the support team can get plugged into some of the configuration, and actually execute some of it, under the control of the partner, providing they’ve got the skills to do it. Or maybe even during the implementation tenant; test it, then get the systems integrator or the implementation partner to QA it, validate it, before it’s moved into production. If those individuals are engaged in the configuration of the product really early on, come go live, they’ve got the skills they need to make those configuration changes from day one. And there isn’t one single product, one single project that goes live, where everything is perfect. Within the first of two to three weeks issues will start to appear, where some of the design decisions might need to be reviewed, and if you’ve got the team in place to be able to execute some of those changes, the transformation is going to gain traction a lot sooner.
Jason West: Yes, and it is critical to realise the investment that you’ve made in this new technology; you need to be able to change it, and develop it over time.
Now, I know you are desperate to talk about structure. So let’s just step through this in a structured way. We’ll talk about four elements of our support model: we’ll talk about support, we’ll talk about development, design, and control. If we start off on the support side, what are the bare bones that you need to support and what are the sorts of activities that your support team will be doing when it comes to it?
Joe Ales: When you’re implementing a structure, you need to think of what type of support is needed for different stakeholders, for instance. So typically, we tend to see a tiered approach to a support model. A tier one is almost an enquiry type of service, where the users are struggling with the particular piece of process or the technology and pick up the phone and talk to somebody. That tends to be your first line of support; these are a bunch of super users, they might sometimes sit in a shared services, or an organisation contact centre. They obviously need to become experts in the system, to be able to guide the user through the process, or help them troubleshoot why somethings are not working according to plan, from an end user perspective. That’s your typical tier one.
If the problem is more related to configuration, or a system issue, that’s a Tier two model. The Tier two is where you’d see in-house, or at least we’d recommend having in-house capability, to troubleshoot and diagnose some of those configuration issues, and fix them. And if you’ve involved those individuals way up front in the project, they’re going to have the skills and capability to do that. So it might be a business process issue, it might be a reporting issue, a security issue. But they can quickly diagnose and understand what the fix might be.
[Intermission]
Joe Ales: Then there is the Tier three, and these are things are slightly more complex. There might be an issue with integration, for instance, so I’ve got an issue with configuration within the system that I can’t address myself. My support model team doesn’t have the capability to do so, in which case, absolutely have a third party – Application Management Support (AMS) – structure that gives you that additional capability and systems expertise. They will configure that particular change for you.
So that’s how you’d typically build a model. What you don’t do is, what we’ve seen in some cases in the past, where everything is outsourced to an AMS because the team doesn’t have the capability. So you have a Tier one that immediately jumps to tier three. And what it means is you spend an awful lot of time, and cash frankly, triaging issues they should be easily resolved. That’s what not that’s not what the AMS service is there to deliver. The AMS service’s purposes is to give enhanced system configuration capability to the client.
Jason West: 20.40 In the short term, from a commercial perspective the AMS provider might go “great, this is massive contracts, were getting hundreds of thousands a year, and I’m just triaging issues that really they should be answering.” But actually, but what tends to happen is the relationship breaks down, because the client is paying thousands a year and they’re not really seeing the value. So, it’s a bit of a short term view.
If you imagine that pyramid of Tier one, Tier two, Tier three, ideally you want to be going live with as thick a band of Tier two in your triangle as possible, and you want to see that growing over time. And you want to see a Tier three shrinking over time. That’s the key aim there; really try and resolve as much as you can in-house as possible, and as your team get up to speed they’ll be more capable and you’ll be able to achieve that more and more.
Joe Ales: That’s right, and use Tier three in the right way. So when you’re developing your support contract for AMS, you’ve really got to think through “what are the components or what are the elements of service I want?” And be specific, be clear about that: integration support, troubleshooting integrations, because there’s something quite specific with some of the technologies, that unless the organisation’s enormous, where you’ve got hundreds of integrations, then build capability in-house to do that yourself. But if you’ve got a handful of integrations, which in many cases, most programmes end up with, having that integration expertise in your support model may not be appropriate. So that’s important.
Another area, another key elements to include in MAS is impact assessment for future changes. These products tend to change every three to six months, and the these organisations have got a better understanding of the impact of that change on the configuration of client’s systems than sometimes the clients do. So getting that into the report is important.
Jason West: Yes, and they get early sight of the releases and training from the vendors, so it’s really valuable to get their input, absolutely,
So that’s the support side, really just supporting the steady state, with nothing changing. But, as you’ve alluded to Jo, the product updates, and we’ve already talked about all the different sources of demand that are going to come in to make changes to the system. A tiered model for development is a good way of thinking about your development side as well. Is it three tiers? Is it the same as on the support side?
Joe Ales: Yeah, probably. Because it’s based on the complexity of changes. So you want to have maybe simple changes done by the super user community: “I want to change someone’s security role or create a new report.” They are simple and can be done by a tier one development team. If things are slightly more complicated that may be linked to road map items, the process owners starting to have conversations with the support team around “How do I enhance the capabilities of the product? How about adding new process, new features?” That probably requires a bit more of a project approach to it, and more around to release management. Because you’ve got comms, you’ve got training, you’ve got all of these things to think about as you’re releasing new features, so that’s probably still using the internal team. And then you’ve got a Tier three, which is “right there’s a new module that we want to implement.”
Jason West: Yeah, or the change is going to ripple through our entire system architecture.
Joe Ales: Exactly, so it has potential for big impact. So, we are going to have to contract maybe a systems integrator, partner or leveraged our AMS contract in a different way. I think it depends on the complexity of changes; I think you should structure your development accordingly. And think it through; think about how you deploy changes in system and the changes across your business as well. For some fixes in Tier one do them quickly, no problem. Tier two, you too you really need to think about in terms of how do you communicate, how you engage the organisation in the change that’s about to be imposed on it? And in Tier three it’s “gosh it’s a proper project.”
Jason West: You need a project manager to manage the change really.
Joe Ales: Yeah it might be you even have to put in a design authority, or project board on an exec streerco around it. Think through this tiered support on running the show, and then tiered support on development as well.
Jason West: Yeah, absolutely. So, we’ve got our development, but that’s just the technical development side. There needs to be design that happens, so we’ve talked about process owners, we talked about design authority, and this is really where that ensuring capability around design comes in. I think in the previous world of on-prem, there’s so much technical complexity to these projects and products, you’ve got to think about hardware, and servers, and network cables, and routers, and then you’ve got to think about databases, and middleware. And before you even get to the software you’ve got this massive stack of technology. In the past, a lot of that design capability sat in the IT function, because it was really deep technical design. With the world shifting to cloud, the amount of technical design is actually significantly smaller, and the technical footprint of these products is so much smaller, about a 10th of the cloud product. So there’s an interesting conversation to be had, about where does design best sit now? Because the technical limitations are reduce: you don’t have to think about databases, and hardware, and all that sort of stuff. There’s that decision really, about where on the continuum of taking a business requirement, turning it into a functional requirement, turning it into a technical requirement, and then designing something. In the past it was very much sat in that technical box. Now, I think there’s a real argument to say “well that design capability should shift more into the function space.” That’s an area we see some challenge.
Joe Ales: Yes, very much so. There are pros and cons for both. What’s interesting is that in the IT world, these functions have been delivering this for years; they’ve got so much expertise and know-how in configuration. They’ve got all the good habits: configuration control, good documentation, test management, release management. They’ve been doing this for years. You’ve now put this responsibility of, not much the doing, but the thought process around configuration and control in the hands of an individual that doesn’t have the expertise, doesn’t have that background. So, it’s really difficult. Again, there’s pros and cons for keeping the model in IT or not keeping the modelling in IT and releasing it to the function. But there’s just a risk factor really. If you have it in the function, the function should impose the controls it uses today, to manage any form of configuration change, or change control and using the processes that organisation uses, so ITIL for instance, and imposing that process on to the function. So it’s making sure that the right things, the good practices are developed through ITIL through all these years are embedded in a support model of technology, that’s being deployed.
Jason West: It’s interesting, because what you’re talking about there, is control. All the control and governance processes around it and I think there’s good argument that potentially that rests in IT. Because they’ve got the experience, they’ve got the track record, they’ve got the accreditations that have been built up over years, as you say.
But I think design is separate to that. The design thinking piece around what is the right solution design? Not talking about how it gets released out into production, this is more about “okay I’ve understood the business requirements, I now need to design solutions in the system, and in processes to deliver the outcomes that the business needs.” What we’ve seen in the past, with some of these on-premise models, is you get into this difficult relationship between a function and the IT organisation, where it becomes a transactional relationship. Which is this “you give me your requirements, and I’ll come up with a technical solution.” And the two worlds don’t really translate particularly well. Where it’s worked well is far more a co-design with IT and the function working together. What happens in some organisations is they carved that out, and they said “OK we’re now going to create systems accountants, or HRIS teams, and they’re going to report into the function, rather than report into the IT organisation.” There is no right or wrong answer with this, but it is a conversation you need to have now up front. And be really mindful of the reasons why the support model is the way it is today. You’re talking about moving accountability, potentially at the executive level, so there’s a good chance you could get flattened, as somebody within one of those organisations, if you don’t approach it in the right way. Be really mindful of the politics and the power dynamics, and tread very, very carefully as you work through designing this support model. You need to address this as part of your wider target operating model design, and you’ve got to involve the IT function; you need senior people from the IT function involved in those workshops.
Joe Ales: No question. Because ultimately, your system that you’re implementing weren’t be working isolation. It will have to be plugged into other enterprise-wide systems. With transformation that you’re trying to deliver, it’s rare that any sort of system implementation will operate as a standalone system, because you just won’t achieve the transformational objectives that you’re setting out to achieve. So the IT function is vital; their involvement is vital in the project throughout. Again, it’s horses for courses: if it is a pure standalone system implementation or transformation in a function, some of that capability could well sit in the function, governed by IT processes and so on, with the design thinking happening at a functional level. What becomes really interesting is where you are implementing multi-functional transformation; so if you’re implementing an enterprise-wide system where the technology spans beyond just one function – you might have a system implementation or transformation around business services, for instance, where I’m transforming finance, procurement, and HR at the same time – and implementing an enterprise-wide system that covers all functional areas. The support model for that type of system is really complicated and will require huge amounts of thought, because all of a sudden you’ve got three functions setting out what they wish to do, what’s their road map, an IS function or something in a centre that’s trying to manage all of that demand with the finite resources it has. Because one of the key things we stress, is the need for process owners to drive innovation through business processes, or the technology that they’re implementing. Process owners need to take accountability. And you’re absolutely right, because in years gone by, it would have been the IT function approaching the operations team, describing to the operations team the value you can unlock from the system, and leveraging it – “how can we get more value from this ERP there we implemented five years ago?” We need to switch it, turn it on its head. We need to say “the IT function are delivering systems solutions against requirements from the function, the process owners.” So when you have a multi-functional system, you really need to start thinking about how are we going to control, or not control necessarily, but how are we going to gatekeep the requirements, and how we going to manage all of that? And who’s going to provide your Tier one support in that case? As an example, I’ve got a query with my expenses or my purchasing on my account, who can I contact. Or I have a query with my personal information that will sit in the same system, who do I speak to? Do I speak to finance for troubleshooting or do I speak to HR for troubleshooting, do I speak to a central team? Think through, if it’s a multi-functional system implementation, think through what’s that support going to look like for the end user.
Jason West: Yeah, absolutely. So hopefully we’ve put forward an argument that failing to put enough time and resource into designing this future support model, is going to add quite a significant amount of risk into you delivering the transformation that you seek. If you don’t have the skills in-house or the capacity in-house to actually design and implement an effective support model, then please contact us. It’s something we are deeply passionate about, and it’s something that we’d be more than happy to help with. But it is really critical to your ongoing success, so if for no other reason, hopefully this has just really scratched the surface to be honest, of what is really big topic. But it’s something that’s well worth your time and attention, because it will pay dividends as you roll into operations to have a really effective support model.
So that was episode two. Next week we are looking at how you build engagement through your transformation. A complete change of pace: we’re looking at change management and how you get the business involved in delivering your transformation.
To download a copy of the build or scoping transformation checklist please visit underscore-group.com and click on white papers under the Insight section of the website.