Joe Ales & Jason West
Season 1: Episode 7 – Governing Business Transformation
[INTRO]
Joe Ales: Welcome to the Underscore Transformation Podcast. This is episode seven, my name is Joe Ales.
Jason West: I’m Jason West.
Joe Ales: And together, we’re the founders of Underscore.
Joe Ales: In this episode we’re talking about governance and decision making.
Jason West: Effective governance is essential to avoid the most destructive forces on any project or programme, and those are indecision, delay, reversal and rework.
The old adage that “time is money” has never been more true than if you’ve got technology in scope of your transformation. So every day of delay can be all too easily quantified in terms of hard cash. You look at the software subscription fee use, the system integrators, the resources, your people, contractors that you’ve hired, and if you’re implementing one of these Tier 1 Cloud ERP technologies you can easily have a burn rate of £25,000 a day and updwards. If its traditional, on premise ERP solution, that you’re implementing then you know that number is significantly more than £25,000 a day. Some delays can be absorbed, others you just end up spending the money, so if you’re not making decisions in a timely way then time is money.
But actually, more insidious than that, is making the wrong decision, so rework. The best case example is you make a poor decision early on in your design process and you just have to pay twice: once to do the work and once to do it again. But the bigger problem is when you only realise that you’ve made a wrong turn and you need to backtrack late in the day; so either late in the programme or actually after you’ve gone live. And then a seemingly innocuous decision to take a small amount of scope out, you might save ten or $20,000 or whatever on the cost of configuration, but actually trying to make those changes in production can be hundreds of thousands if it’s a fundamental data structure or part of the system. So it’s really key that you focus on the timeliness and the quality of the decisions. When we think about that what are the kind of the top three mistakes you can make in setting up your governance structure?
Joe Ales: Just the top three? [laughs]. The list can be quite extensive. But responsibility of design and then being held way too high up in the organisation. A command, control type of organizational structure or culture can lead to the wrong design decisions being made, because ultimately the person at the very top of the organization that’s making that design decision doesn’t have knowledge or experience of what happens in reality. Actually, to your point it might seem quite innocuous, but actually it can have quite profound effect later on. On the other hand sending it way too low in the organisation where the responsibility gets delegated from, what we refer to in our methodology as process owners. If process owners delegate the accountability of design way further down the organisation then ultimately design decisions might be made purely from an operational perspective, rather than strategic one.
Jason West: But also you can end up with just too much variation, and variation costs money, so you know if you’ve gone too far down you’ve got maybe every region or every country or even every office is having its own unique ways of working.
Joe Ales: Absolutely when you’re talking about programme design, delegating responsibility to various geographies, various business units it just brings complexity into your design.
Jason West: The flipside of that, though, is if you have it too high up and you try and go for too much of a global process, all that happens is you just create a huge amount of local workaround and manual work.
Joe Ales: Absolutely. The work is not going to be executed in the way in which they plan. So it has to be done right, the accountability for design has to be placed at the right point in the organisation.
The third point I think is a lack of clarity as to when decisions need to be made, and ultimately who should be making them. If you’ve got a programme team that doesn’t have clear process ownership, you’re going to try and coalesce a number of individuals across the organisation to agree to a set of design decisions, you’re going to have a tough time. Because different people across different geographies will have different perspectives and different views about how things should operate, so anyone embarking on a transformation programme make sure that you’ve got your point process owners. Those individuals that are ultimately going to have the accountability for the outcome of whatever it is that you’re trying to design, whether it’s an implementation of technology like we talked about in the introduction or whether it’s a change to a business process. Ultimately, it’s going to affect the way a number of people: managers, employees or the functions that you are transforming.
You have to establish your community because the individual that is ultimately accountable shouldn’t be the only individual making design decisions. The design needs to bring together a number of individuals that have got different perspectives, but ultimately the design, whether it’s process, policy, people or technology needs to be signed off and validated by that one individual; that one person who is accountable for the outcome.
Jason West: And when we think about accountability for outcome it’s the efficiency of a process, it’s the effectiveness of the process, but one I find is often quite challenging for process owners is they really need to be accountable for the data those process actually produce or transact all the setup data the systems have around that particular topic, and the transactional data that pushes through them. So as a process owner you are accountable for the quality of the data, the processes that you own and that idea of being a data or an information asset owner is, for a lot of organisations, quite tricky. There are organisations out there that are incredibly sophisticated in this area, but for a lot of, particularly HR functions, finance functions, this can be quite new, pretty alien.
Joe Ales: One of the clients we have been working with, we’ve been emphasising that point precisely, because process owners might have an idea that actually the responsibility around data quality and that data that is transacted through the system, is the responsibility of those transacting it. Or some team in the centre that is responsible for data analytics, reporting, and you’re absolutely right: actually, it’s neither of those. It’s the responsibility of the process owner. It’s a really, really important point that’s not often thought about when we’re designing the role of that process owner: what’s the process owners responsibility in a programme?
Jason West: Yeah, and they also have a real accountability for whether people are using this process.
Joe Ales: Yes, acceptance and driving change through the organisation. So actually we may have a change team that’s driving those change messages, but actually the way change lands in the organisation is ultimately the accountability of the process owner.
Jason West: Absolutely. Process owners being absolutely key, they are going to be looking at system design, process design, policy – how it lands, and they’re the person accountable.
But they’re just one part of the governance model, so when we’re thinking through how we’re designing this governance model there are key decisions that you need to have in your mind. So what decisions are we going to make? Where abouts are they going to be made? Who’s accountable? Who’s responsible? Who’s going to be consulted? Who’s going to be informed?
As you’re working through the programme itself, and ultimately where do those decisions roll up to? You can’t really push everything up to the executive steering committee, because you’ll just grind everything to a halt.
Joe Ales: And you won’t have time, frankly, if the exec steercos are being presented with the minutia of detailed, then there’s something wrong in the programme.
Jason West: You might be asked to leave. [Laughs].
Joe Ales: Yeah. There are layers to this. One of the things we talk about a lot is actually governance structure is not there to prevent or block. Governance structures should be there to enable. They’re the vehicles that allow the programme to move through various phases, to the programme through its various key milestones, its critical path. The exec streerco; they’re the ones ultimately accountable for the execution of the programme. Is a programme going to achieve the objectives that we set out to achieve? And we talked about this in the previous episode, around strategic objectives being really, really important, and they’re the ones validating whether a programme still on track to achieve these things that we set out.
But actually, the user experience of what you’re trying to achieve, isn’t validated at that level really. That user experience that you’re trying to achieve, whether it’s a system or target operating model change, the people that need to validate whether this really is going to work in practice are the business representatives. They are the line managers, the heads of function, the cost centre owners. They will come in and validate whether your design actually is even practical. They’re going to bring a little bit of common sense to what you’re trying to achieve, so having that cross-functional representation at the table, in a formal structure, whereby these guys are validating and say “I agree with what you’re trying to achieve and it absolutely make sense.” And more often than not, they give you little gems, they start opening up cans of worms that you hadn’t thought about. They will come up with the nuance in their particular business units, and say “actually if you change that you fundamentally break this element of our business.” They get you to think about things that no one else really thinks about. And actually, it’s a really important point: you go “wow, I didn’t know about that; let’s take that to the exec and get the exec steerco to give us steer as to which way they want us to go. Do they want us to break that business unit or that particular element of the business? Or do they want us to safeguard it?”
[INTERMISSION: you’re listening to the underscore transformation podcast this podcast is brought to you by underscore the transformation capability specialists to find out more visit underscore-group.com.]
Jason West: We talked about programme board there, but for larger organisations it’s not feasible to have broad representation in a programme board or a project board, because it’s just too many people in the room, too many opinions; you just would get mired. So that’s where we often split out and create a separate operational steering committee, and their role is very much to sense check, to review, to provide critique, to bring these of gems in and say “that hold on that’s not going to work in Germany.” And really you’re designing processes and solutions that are fit for purpose, and all the different parts, and the complexity of the business.
But I’ve realised we haven’t actually talked about the executive steering committee itself. So as you’re setting up your governance structure it’s really key that you have people at the right level on any executive steering committee. We’re talking about transforming at least one major function; HR, finance, procurement IT – one of the professional functions in a business, or an organisation. You can’t make changes in isolation, so the executive steering committee, in my view, always has to have at least the CFO, chief people officer, COO, some representation from the PNL side of the business. You got a CEO, or MD of a business unit, at least one; you’ve got the CIO because the technology will always feature. And potentially, you need to have people from the customer side, you know sort of the sales side of the business as well. But they’re really there to help you deliver the programme as the person perhaps accountable as the programme director or transformation lead. They will help you unblock situations, but you’ve got to be really honest with them. So if you’re going to your regular (hopefully monthly) steering committee meetings – that seems to be a fairly traditional schedule; if things are under stress so you’ve got real challenges, then you need to make them happen more often than every month. If they are happening faster than every month and it’s because there’s issues, and ideally you don’t want to be meeting on a weekly basis because you tend to end up just spending your life creating slide decks for the exec, and you’re just running from one meeting to the next.
But having that broad diversity of thought perspectives, different ways of doing things; you know, having the ability to be able to call on senior people within the organisation to get stuff done, and to just knock down barriers for you is key.
Joe Ales: And you know what? If these individuals don’t see that they should be playing a role in the exec steerco, you have to question the fundamental objectives of what the programme is trying to achieve. Because ultimately if it’s not important to any of you, why is this programme important at all? It’s interesting actually, if you’re starting or creating an exec steerco, and if you’re having to convince people to come and join it, you seriously need to think about: am I focusing my energy on the right things? Because they should be climbing over walls to get around that table, because ultimately what you’re trying to do will impact the way these guys operate.
You’re right: keep it tight and keep it relevant, don’t invite the entire exec or decisions don’t get made. It becomes an absolute sort of political discussion, so keep it relevant, keep it succinct, make sure that the existing exec members understand their role, in and around the table. They are there to help unblock issues that your programme’s faced with.
Absolutely, they should be challenging: if you come up with a design decision that’s come through your project board to the operating steerco, and gets to the executive and they fundamentally disagree with it, they absolutely have the right to challenge it, and say “for now I’m not happy with that. Go back down through your governance structure and start again.” Hopefully no programme will ever experience this, but they are there to make sure the programme ultimately achieves the strategic objectives they did set out to achieve.
So when you’re starting your execs streerco, make sure that you describe what your destination is and that everybody around a table understands what the programme is trying to achieve. And make sure they agree. Ultimately an exec steerco needs to be initiated right at the beginning; you will have changes in the exec steerco because there are changes in casting. But make sure that you keep to a succinct group, and if you’ve got new members joining the exec – new CFO or CIO – make sure that you spend time educating that individual on where the programme’s come from, what it’s trying to achieve, and it’s really important to make sure they understand their role as an exec steerco member. They’re not an exec in the programme.
Jason West: Yes, absolutely. I think it’s a bit old-fashioned, but having written terms of reference for each of the points in your government structure is really helpful. These are the thresholds where we’re going if we can’t resolve things at this level, then they need to be passed to the next level; here are the decisions that will be making at various levels, and having that just laid out up front just helps the people making the decisions. But it also helps the people on the programme in navigating their way through this really complex set of changes they are trying to make.
Now the one area we haven’t actually touched on, we’ve talked about the exec steering committee right at the top, we’ve talked about the operational steering committee kind of at the mid-level, we’ve talked about process owners more at the coalface making those kind of key decisions, but often you can have conflict between that individual process owners. And I don’t mean conflict personally, but can come from design: competing design priorities and decisions need to be made and mediated between one process area and another, so it’s often really useful to have a design authority – not just really useful it’s kind of essential to have a design authority that’s sat above the process owners.
Anything that’s produced as a solution needs to ultimately go through an operational steering committee, if you have one, and ultimately up through an exec steering committee, but actually really thinking through having an effective design authority and who sits on that, who chairs it, how and what decisions are being made? What thoughts do you have on design authorities?
Joe Ales: Actually, it’s a really important point, because actually the danger that you have when you’ve got process owners being accountable for the outcome and being accountable for the design, actually no process sits in its absolute isolation. If a process owner wants to make a fundamental decision to a process in their area, say resourcing, in some occasions the reward process has something to say about the resourcing process. Whether it’s benchmarking, pay, or pay bands etc. there’s an interdependency between these two process owners and actually having an effective design authority there brings these process owners together to make a synthetic, sensible design decisions in their process area. To get those validated by other process owners is really, really important.
Jason West: And in fact, there was an example just recently: you can have payroll sat in finance, perhaps making changes or implementing a new payroll system and actually the way you onboard new employees has a fundamental impact on if you’re going to pay that person accurately. And it’s not just within one function, any change you’re making to any part of the system or process has these ripples through the organisation that at the outset might not be completely obvious, and that’s quite difficult to unpack. Having a design authority that has not just people from your function, and IT because generally you’re making changes to systems, that’s the kind of the obvious ones, but you’ve got all the other areas. You’ve got procurement, you’ve got finance; again you’ve got to limit the number of people in there, because it’s got to be a really sharp decision making body, but also you can’t leave out bits of the organisation. So having that broad view is key, but it doesn’t get overly bogged down by decision by committee.
Joe Ales: That’s right and this group of people, they are brought together to validate a set of design decisions, and their impact across the organisation. So you have to have the trusted individual, from the exec actually, the exec may well turn around and say “actually if you put Joe blogs (poor Joe blogs he gets posted everywhere), if you put Joe blogs into this team to validate that design, I’ll feel comfortable that the right people are validating what you’re trying to do.”
Jason West: I think that the final piece that we’ll just touch on today is scope. It’s one of the most important decisions that you make: what are we bringing into scope? What are we taking out of scope? And what changes are we going to make as we progress through the programme?
And some of the biggest issues that we’ve seen on programmes that have really got into trouble, and these tend to be ones where we’ve gone in after it’s gone live, is really around the decisions that they made frankly to reject scope. And when you’ve got these really high burn rates on projects 25, 30, 40 50 thousand dollars a day, whatever the number is, the people just kind of stare at the go live date and that pot of money that’s just getting lower and lower. And it can be all too easy just go “you know what, we’ve just got to hit the date, we’ve just got to get this thing out there.” and scope gets bailed out of the programme at a rate of knots. And if you don’t have that really strong governance from process owners, who feel personally accountable for delivering the benefits being promised, likewise if the programme manager, the programme director, the transformation lead aren’t feeling personally accountable for those business case benefits that were promised to the exec. And if the exec across enough of the detail that when their signing off they say “Oh yeah take that out to scope to meet the date” or they’re putting too much pressure on the programme to hit a date without really understanding what the real impact is on the benefit, that’s when you can get into some really big problems.
Joe Ales: Yes, actually and we talked about this again in previous episodes: you create a case for change, you define a vision of where you want to get to, you describe what are your key outcomes from whatever transformation you trying to execute, and make sure that your scope is always aligned to that. Because ultimately if you take things out of scope something’s got to give. Scope creep is another one, because actually if you’ve got a vehicle that’s generated a lot of enthusiasm in the organisation and is going to provide some change, it’s very easy for people to jump on the bandwagon and say “you know what; wouldn’t it be great if your programme could also deliver this, and deliver that.” And there is a danger that sometimes the sponsor sees this as an opportunity to win by-in because the programme is so important to everybody, let’s try and achieve all things for everybody, and actually end up achieving nothing. So make sure that you are managing scope creep, and more importantly make sure that you’re not taking things out of scope that ultimately affect your business case and the outcomes that you are trying to achieve from your transformation.
The sponsor needs to be all over this. The programme may come up with challenges around struggling for resources, we’re struggling for time, we’re struggling for availability of key people, we’re not making design decisions as quickly as we’d like, so therefore we are creating bottlenecks in the programme. The sponsor has a role here to help unlock a lot of this, and to make sure that the programme stays honest in what it’s trying to achieve.
Jason West: So key takeaways for this week: governance: it’s really important. Make sure you’ve got a multi-functional exec steering committee that’s got good representation from the business, and they are engaged and across enough of the detail that they are going to be effective in holding the programme to account, for delivering the outcomes have been promised in the business case.
If you’re a large, complex organisation really think about using an operational steering committee to actually help push decisions through or validate things. An empowered design authority that can really help you unlock challenges or issues between different process areas and that you’ve got process owners that are absolutely accountable and feel accountable for delivering the best possible outcome from the processes, the policies, and the systems that they have under their control.
Get all that stuff right and you’ll have an effective programme, but be really careful about scope and taking things in and out of scope and make really carefully defined decisions about how you go about doing that.
Jason West: Thanks Jason. So next week will be looking at methodology and approach.
[OUTRO]