Joe Ales & Jason West
Season 2: Episode 1 – Resourcing Your Progamme – Maybe Your Should Hire the A-Team
Jason West: Welcome to the Underscore Transformation Podcast. My name’s Jason West.
Joe Ales: And I’m Joe Ales.
Jason West: And together, we’re the founders of Underscore. This is season two, episode one. This week we’re talking about resourcing your programme team. So the first thing to say is: congratulations! You’ve got your business case through approval, your exec team are all fully supportive of the plan, process owners are all bought into the high-level solution design that you figured out during the scoping phase. You’ve got your new operating model agreed, and people have started to ask what this transformation programme’s all about. Before you start rushing off and building and designing things, it’s worth taking a moment to consider the personal risk that an exec sponsor takes when they set up and tell the board that they need several million pounds/dollars to invest in transforming their function. Now, you would assume the securing the best possible team to work on the transformation would be at the top of their to-do list. Frankly on too many occasions we see that resourcing the programme team is actually really rushed through, and it kind of gets compressed between this time of the programme getting approved and budget put in place, and the kick off happening. And really, just there’s just not enough time, effort, and thought put into it. So that’s why we really focus on this as the very first point on the checklist; is get the right team around you. But let’s just think about what are the practical steps that we can take to reduce the risk around making the wrong resourcing decisions on programme.
Joe Ales: You’re right Jason. Being able to build the right team is really, really important, really key, and with the right skills and capabilities. One of the things we talk about in projects that we’re involved in, is having the right balance between internal resources that are seconded onto the project, and bringing in external subject matter expertise in areas that the organisation doesn’t have experience in. This is new ground, typically, for an awful lot of organisations and building that team that has both internal resources, that are going to take ownership and accountability of whatever is designed longer term, with subject matter expertise of people that have been there, done it, is important. And having that mix is really key.
Jason West: Yeah, you’re absolutely right. Getting that right balance between internal staff, and external contractors and individuals is really important. And it’s not just the contractors obviously, you’ve got potentially a management consultancy involved, you’ve got a system implementation partner, you might have the technology vendors staff involved, and maybe external client-side advisors.
Joe Ales: Yes, and each of them offer different support, and you have to be clear about what’s the purpose for each of those components, of your programme team. You have to have clarity around responsibilities and accountability etc. so that there is no ambiguity as to who’s responsible for making decisions.
Jason West: Yes, and we’re going to go into more detail on that when we get to the supplier management piece; looking at the difference between the role of management consultants, of system implementation partners, and client-side advisers; they are different and complementary in certain circumstances. But I think that the first point is to really be clear with people about “this is your programme role.” Actually documenting what are they accountable for? What are they responsible for? What are the types of skills and competencies that they’re likely going to need in this new programme? And actually giving that to people. In a lot of programmes that we’ve worked on in the past, and we’ve been guilty of this, we haven’t always done it, and it does lead to some real challenges. But I think the other piece to think about is, as you’re kind of deciding which roles should be filled by somebody on the payroll, that’s seconded onto the programme, versus filled by an external of one sort or another there’s a couple of lenses to look at that through I think. There’s the question of “what is the enduring capability we need for these types of resources? and who’s best placed to make decisions?” So if you think about those two things, what are the key roles that really should be fulfilled by permanent member of your team? Somebody on your payroll within the programme?
Joe Ales: I think the owner of the change, the individual that exec supports, who has gained the business case approval, the individual that is delegated that responsibility of making sure the change happens, that has to be an internal person.
Jason West: So, it’s the person that the executive sponsor is saying “okay you are accountable to me for delivering this change.”
Joe Ales: That has to be a permanent person because that person is ultimately the face of the programme. Programme managers, programme directors should be resourced externally, because you’re ultimately going to require skills and capabilities that don’t exist in your organisation today. You’re implementing something new, so you should go out and equip yourself with an individual that’s been there, done it, got experience of running these programmes.
Technical roles that you wouldn’t expect to have the capability internally include systems architects, maybe integration specialists, maybe data specialists, those who have been involved with that specific technology in the past.
Jason West: Yes, and business analysts, functional consultants.
Joe Ales: Yes, functional consultant on the technology side, absolutely. I think those individuals maybe you could acquire externally, but then make sure they don’t work in isolation. You have to have on the client side somebody that almost partners with them, so that knowledge is retained within the organisation, way beyond these individuals exiting on completion of the project.
Jason West: Yeah and it’s also important that the people making the design decisions, are your staff.
Joe Ales: Absolutely: process owners. Yes, the process owners, always, are internal individuals. The functional heads, if they’ve been seconded full time onto the project, or whoever those functional heads have delegated that responsibility to. Similar to the exec delegating the responsibility to a programme lead, the functional heads should also delegate the responsibility of their functional design, to somebody within their team.
Jason West: Yes, assuming they’ve not been seconded onto the programme themselves, yeah, it has to be an internal resource, without question.
Joe Ales: And then, of course, being supported by individuals with expertise in facilitating design workshops, design sessions and the business analysts that you talked about. Because in an awful lot of cases, these individuals are operational individuals. They might have optimised the process before, and they might have done a bit of continuous improvement on elements of their function, but probably have not re-engineered or redesigned the function in its entirety. And we’re not talking just about process here, or systems, we’re talking about maybe operating model, roles and responsibilities, and system integration, data, policies. There’s an awful lot to consider and it’s unfair to expect functional, operational people to have that expertise from the get go. When you’re going on a transformation journey, you’ve got to think about “how am I going to provide the skills and capabilities the process owners need, to make the right design decisions in a timely manner?” And actually just think differently about this is not optimising operation, this is probably designing something fundamentally different to what we have today.
We’ve identified something like 37 roles in our capability matrix, in our resource matrix, of individual roles that are required to execute this transformation, this change at different phases of the project etc.
Jason West: And not all of those are full time, so if you’re sat there is as a mid-sized organisation going “37 people?” don’t panic.
Joe Ales: Yeah, it’s 37 roles that are required to execute the change well. These roles require a certain skill set and set of prerequisites. So please equip internal teams with the skill sets that we describe in our in our capability matrix.
Jason West: Yeah and being clear, as we said, which ones really must be internal. And I think that one that we haven’t talked about is the design authority. Sponsor? Yeah, absolutely needs to be internal. Transformation lead and process owners definitely need to be internal. But I think the design authority that sits above the process owners, it is really important that the individual that’s fulfilling that role is on the payroll. And they are going to have to own these design decisions.
Joe Ales: It’s ultimately that programme lead individual who is delegated responsibility from the sponsor; that individual ultimately heads up that design authority. On their head be it. And all of the design decisions must be done in the best interests of the organisation and are fit for purpose. They can, however, be complemented by somebody who can help facilitate these design authority meetings, and understands the processes that the organisation needs to go through in terms of the iteration of the various designs. Especially in cloud technology, for instance, iterations of decisions are common. You are making decisions in the design authority today, and actually once you hit the ground running in operations, and you realise actually “in hindsight we shouldn’t have made a decision.” Because it happens, it’s a reality. Nothing is perfect from day one. So you make a set of design decisions with the data you have in front of you, but those individuals making those design decisions – that functional lead or I call it the programme lead – hasn’t done it before. So actually, being complemented with somebody that’s been there and done it before, a programme director or programme manager, sitting alongside a programme lead is important.
Jason West: Likewise, it could be a functional architect that you pair them up with, or that’s where you might bring in a client-side advisor, who’s specifically only going to work on those design decisions, and bring in that best practice from outside. Rather than being full time on the programme in a programme management or programme direction role. But I think the other thing that’s important is where you have paired up, it’s really key that the person that’s providing that external advisory, has held senior operational role within the function you’re transforming. Because you know, as well as I do, that it’s all very well having somebody that’s got a wealth of consultancy experience, or project experience, but if they’ve never really had to live with the design decisions that they’ve made in operation, and the pain that can bring, they’re really missing a vital element of insight into what the optimal decision might be. But we do see this is an area where, for a lot of clients, it’s very individual by individual. They’re unsure about making these decisions, they lack the confidence, or just the knowledge and capability, and they look to other people within the programme to make decisions on their behalf. And often that will be leaning on management consultants, or leaning on system implementation partners. The system implementation partner is there to configure the system, based on specification, they’re not there to make recommendations. They’ll give you options, but ultimately it’s your decision, as the client, to make those calls. And in certain circumstances, where people have been over overly reliant on these third parties, it can really store up problems in the future. If you think about the sorts of challenges that it brings.
Joe Ales: Absolutely, operationally, if you’re outsourcing a design decision to somebody that that is not going to “live” with the operational impact of those design decisions, you’re asking for trouble really. Having an individual that has corporate knowledge, and again asking an individual that doesn’t have any corporate knowledge to make a set of design decisions in our organisations is not right. Again I would say if you’re hiring somebody from the outside to the become a programme lead, that’s okay, but then that programme lead is going to have to lean on an awful lot of internal resources to just figure out “okay is that right? Does that make sense? Is that fit for purpose? Are we making the right calls here?”
Appointing a programme lead with a little bit of corporate knowledge is probably even more important, more valuable longer term. But outsourcing it to a third party is really risky.
Jason West: Yes, so the first problem is that you make the wrong design decision. That’s one issue, but you tend to only find that out once you’ve gone live, and by that point the individual won’t be around. What are your options then? Well you either pay them to come back, to fix the problem that they inadvertently created, or you’ve got to work through the problem from first principles, with your operational team, who are under pressure because whatever is being designed isn’t working properly. And if you haven’t undergone that transfer of knowledge, skills, and capability to diagnose problems, to design solutions, to test them, to manage that change, and the project that potentially has to go around that, then they’re going to have to figure all that out from first principles, whilst being under pressure to deliver operationally. So generally it doesn’t happen, and then you’re into creating local workarounds, and then this new way of working, this fancy new operating model, this wonderful shared service that you’ve built or new technology you have implemented degrades. There are people finding all sorts of ways to work around it. Or the other thing is, you just have to live with it, you just have a sub optimal outcome; you don’t quite deliver your business case. And one of the biggest I’m kind of modes of failure of transformation is around failure to deliver the benefits. You can generally force a programme to deliver on time, or deliver to a budget, but it’s the outcome.
Joe Ales: It’s the sustainability of it beyond the go live; and in this phase of the programme, sometimes programmes or organisations lose sight actually about what it is that you’re trying to achieve, when you signed off the business case. And throughout the life of the programme, absolutely some decisions are made that are fundamentally against the original reasons for investment. And to your point Jason, which is to drive that outcome of “we need to go live on this date, and we’re running out cash, or we constrained by budget.” Change doesn’t happen, until change happens, right. So go live is just day one of the transformation. You have this massive engine of lots and lots of resource, and lots and lots of activity taking place in this phase of the programme, to produce something that is not yet real. It is only real on day one, and guess what; on day one an awful lot of that capability walks out the door. So if you don’t have a sustainable operating model, and we’re going to talk about operating model in the future efforts in the next episode, if you don’t have that sustainable capability to actually embed that change and remember the design principles, and the rationale for business case in the first place, you’re not going to deliver. For example, the intention was to create a shared service, but now we’ve gone live we don’t have a shared service. Why is that? And one of the other things we talked about, actually, is a continuation between scoping and implementing. Before we’ve been formally handed off into this phase, a business case is created, the transformation programme and a set of strategic objectives: you shall deliver X. And there is an element of risk, if the person that’s delivering the change is not involved in the scoping. We’ve come across that before, where there’s a hand off and the individual, the team that has created the business case is no longer around. The baton has been handed to an implementation team, that doesn’t have perhaps the same insights, the same drivers, or the same rationale, the same reasons, whatever, that were created in our business case. And then when you go live, you end up with something that is fundamentally different to what you’ve committed to in the business case.
[intermission]
Joe Ales: having a programme lead involved from day one, in scoping through to implementation, and into warranty and sustaining it, is really, really important.
Jason West: Wherever possible you really want to do it like that.
Joe Ales: Sometimes it’s not possible, because of casting changes etc. Things like that do happen, there are changes of sponsorship, or execs changing roles, and we talked about that in a previous season. So don’t plan for it, but be prepared for changes in structure, because these programmes take a long time, and there are inevitably going to be changes in casting, and changing individuals in the organisation. But having that continuity makes your programme more likely to succeed.
The other role, actually, is change management. So, again, what’s interesting is there’s an absolute vast skill set out there, of change management specialists, but what I’ve seen in organisations is don’t expect those individuals to come in and change your business. That’s’ not what they are there to do. Their purpose is to come in to an organisation, and equip an organisation with the techniques and methods to execute change. What’s the toolkit, what’s that going to look like? And to help you create a plan for the change. The people that are driving the change are the functional leads, other process owners, others change champions that you’re going to appoint internally, every line manager in the business, every employee – because you might be asking individuals to do self-service and maintain data themselves, and that is something they wouldn’t have done before. But don’t bring your change specialist in to embed the change, because that’s not their purpose.
Jason West: And to your point on the very real fact the go live is day one; it’s not day 408 of the programme. The programme is just that “being pregnant” but; the baby arrives on go live. And it is at that point that the work really starts. I think the key point is that on that day one, where you’ve got your new “baby,” there’s certain capabilities that you need as a human being and as organisation. If, as an organisation, you don’t know how to support this thing you’ve got; if you’ve implemented new technology and you don’t have people in your organisation that really know how it works, how it’s put together, how it’s designed, how it’s configured, and they don’t have those skills to change the configuration, you’re going to really struggle. Because business requirements change. You find out a huge amount in those first few weeks, after go live, just what the real requirements are, and where the design decision problems are. So you need the ability to change things. That requires a number of things: you need people with technical capability, to make changes to a system. But you also need accountable people in those senior functional roles, and process owners who know how to diagnose problems, who know how to design and know how to speak the language of the technical team, to make that translation between “we’ve seen this problem in the business, this is what the functional impact is, okay technical team this is what I need you to do.” And those teams need to work together effectively. And they need to find ways of speaking the same language.
To your points on change management, in a lot of cases you actually need an enduring change management capability. Day one is just day one. Things are going to change, and you probably need enduring project management and change management capability, and depending on how big the transformation is, you might actually need an enduring programme management capability for a good few years. So it’s definitely worth thinking about, when your resourcing your programme, what’s the day one requirement? What’s the day 90 requirement? The day 365 requirement? How far out do we need to think? And the reality is quite some way; when you’re resourcing your programme, think two years/three years down the line, about what are those key roles and key capabilities we need in-house, to be successful in the long term? And just coming back to our capability matrix, that’s where we started with trying to fix this stuff. Because we’ve seen a lot of programmes get into trouble where they’ve got the wrong people, doing the wrong roles. They’ve got suppliers fulfilling roles that must be, should be fulfilled by permanent staff. and those permanent staff that are on the programme, a lot of people are on the programme in fact, really aren’t sure about what their roles are, and how they fit together. Which is a real challenge when you consider that you’ve got multiple organisations, or people from multiple organisations, working together to deliver this really complex change. And they’ve got their own commercial drivers, they are not clear about how my role works with your role, and it’s not surprising that a lot of challenges around this kind of people related. So really spending the time properly documenting those role profiles is really key. And the reality is, in a lot of programmes, it does not happen. We see it a lot in the resourcing side – that’s the resourcing business that we run – is a lot of programmes will just call up and say “okay I need a business analyst, they need experience of Oracle/ERP/cloud and it’s a project for six months, and I want to pay £700 a day.” And that’s it, that the total extent of the requirement; there’s no job description of any sort, and sometimes this is the first time that person’s even heard of a business analyst or programme lead. They are going to interview people, having no clue about what this role is, so that’s why we’ve put together this this capability matrix, to actually make those resourcing decisions as effective and as sound as they possibly can be. So really documenting those role profiles, putting the right competencies in place, and thinking through “what are those competency based interview questions that we should be asking?” And providing that level of support around building the right team, because frankly you could have a plan that’s a bit off, and you could have a not great business case, but put the right team on it, with the right executive sponsorship, and frankly you can fill in a lot of those gaps.
Joe Ales: If you have a solid business case, but then you launch a programme and you don’t equip yourself with the right skills and capabilities around you, it’s going to be a struggle. Totally agree Jason. And it is interesting that you have to plan out your resources, at the outset of the programme. And there’s a lot of organisations out there that would love the fact that organisations are struggling for resource. “I need somebody to start tomorrow” is music to recruiter’s ears. But in the recruitment world, let alone the contracting world, there’s so, so much that can go wrong with desperation. So plan your resources upfront.
Look at our capability matrix, review that, see what skill sets you need for what phase of the programme, and have a recruitment plan, a resourcing plan that is going to give you the right skills, at the right time in your project. And there’s an awful lot of businesses out there who will be pushing an awful lot of resources at you, that can just about spell the word of the technology they are about to implement – whether it’s Oracle, SuccessFactors, SAP, Workday or whatever – If they’ve got that word somewhere on their CV or LinkedIn, that candidate, that individual will be pushed to you as a potential resource. And if you have not thought about the skills that are needed, and where does that individual fit in my overall programme structure, and what’s their real purpose, you can be misusing programme budget in resources, that are sub optimal to what actually you need at that time. Structuring your programme from day one is key.
Jason West: The other thing that’s definitely worth mentioning, is it’s really important to take proper references. There’s so much money that has flooded into cloud ERP, cloud HCM over the past few years, and especially on the ERP side it is just skyrocketing at the moment. And there are an awful lot of programme/project people out there, that we know have a string of failed programmes or failed projects behind them, and they consistently keep securing future work, and it can only be because people aren’t taking references. So, if somebody provides you with a reference, be really clear about what that person’s role on the programme actually was. A lot of the time they might be somebody that reported into the person that’s giving you the reference, rather than the programme sponsor, or the programme lead. Sponsors and programme leads – they’re the only kind of people you want to be talking to, if you are talking to somebody senior within the permanent staff of that client. They are the sort of people you want to talk to.
Joe Ales: And don’t just take the last one [reference]. Because what’s interesting is that with every organisation that goes live, there’s a honeymoon period, where everything seems to be OK. “We’ve turned something on and the sky hasn’t fallen, the world doesn’t implode, so we’re in a good shape.” If you bring in somebody to work on your project, that’s literally just left another programme that’s recently gone live, the likelihood is that they’ve not yet come across any issues that have been stacked up since that programme has been developed and implemented until month three or four. So I would encourage those taking up references to go and speak to individuals that have been live for a period of time, to understand what lessons have you learned? What could have been done differently by that particular individual that you’re talking to, on that programme at a time? Knowing what you know now, what would you have done differently?
Jason West: Yes. If this sounds like a lot of hard work to hire a relatively small number of people, to work on a temporary basis within your organisation, really stop and think about it. These are the people that have your future career prospects in their hands. Really spend the time, invest in really getting to grips with “what are these roles? What they mean? What does good look like? What’s a good programme manager versus are not good programme manager?” And really spend the time, and give your programme team the space required to get the best possible people onto your programme. Because we’ve seen it first-hand: the personal cost to executive sponsors of getting these resourcing decisions wrong. It’s just not a price that’s worth paying. So really spend the time, and really focus on this is a very high priority, as you get up and running on the build phase of your programme.
So that’s it for our first episode of season two. Next week we’re going to be talking about building your technology support model; so on a similar theme but very much specifically focusing on the technology side, and the right team that you need to support your newly implemented technology.
Have a look on our website and the insight section: that’s underscore- group.com. Very soon there will be the new build checklist that will contain all 10 points that we’ll be talking about over this season. Thanks again for listening, and please do like and subscribe wherever you find your podcasts.