• en

How to Ensure Business Processes Don’t Become Red Tape


On June 20th, Kimble’s CMO Mark Robinson will be presenting at the TSIA Virtual Summit, arguing that executives don’t make the most important decisions in a business. Yes, they make important strategic decisions, but it is the day-to-day decisions made by employees on the front line that provide the foundation for sound strategic decision-making. This has long been a cause Robinson has championed – you can get a taste of his point of view before the Virtual Summit in this interview from the Kimble’s PS Insights series. In this interview, Robinson presents strategies for ensuring business processes don’t become red tape. You can listen to the interview in the embedded player below, or read the full transcript.


Transcript of Q&A with Mark Robinson

Sir John Harvey Jones once said that no one goes to work wanting to do a bad job. But we put so much red tape in their way that they give up trying to do a good job. Some of that is about processes, so why do we have the specific processes that we have?

Well for me, it’s about a number of things. First of all, it’s about driving consistent behaviour. And if you drive consistent behaviour you’re more likely to get consistent outcomes for your business. I think as well, one of the challenges of growth is that there are basically not enough experienced people to go around. So you’re always going to be giving people (if you’re growing) something they have not done before— or they’re effectively learning on the job.

If you give them process, you help guide them. I’m not suggesting everybody follows process rigidly. The analogy I would draw is like a G.P.S., Google Maps. I don’t know about you, but the way I use Google Maps when I’m driving my car is that it tells me how to get from A to Z, and along the way there are various turns I do. Most of the time, I can remember which way to go but occasionally I’ll just need that little prompt about what turning I should do or maybe it’s a bit heavy traffic, maybe a different way. And I think processes are like that. They are helping guide you on a journey. If you’re more experienced, there are things that you may cut corners or change things slightly differently. But ultimately it’s taking you on a journey from the beginning to the end. And if you do that consistently across the business you can then delegate that to more people.

Getting that consistency is really important isn’t it? Because organisations want to give the same quality of service and the same quality of output all the time, processes can help with that presumably?

Absolutely. Processes are a way of putting policies into action. They’re actually all about driving behaviour. When you are growing an organisation I think it’s very tempting to not empower people in organisations to make decisions. You’re too frightened that if they make a mistake, it affects you. And if you’re running for example, a services business , it can have a real impact on you. One failed project could ruin your brand, it could certainly lose you money. So unless you’re convinced that people are going to drive things in a consistent way, you won’t let go. You’ll end up staying in the weeds. You won’t be able to become more strategic. You won’t get to take a more strategic role and you won’t be able to grow because unless you empowering everybody across your organisation to make those decisions, and you can trust them, then you’ll stagnate and then the growth of the organisation will be inhibited.

Processes can therefore give you a way of scaling. Within the professional services sector do you see some key processes and key business processes that are important for those organisations?

For consulting organisations, then the sales process is absolutely key. The difference in a services organisation to a product business is that in a services organisation your sales are dependent totally on having the resources to actually deliver those services—and having them available at the right time. So it’s not just sales. It’s about being able to resource the sales you do. So, the link between supply and demand and that process is really important and that involves understanding when it is in the process you’re actually going to resource. For most organisations, sadly, they will resource once the business is won or very close to being won. But the trick in growing your organisation is to actually resource as early as possible. And that requires a disciplined process for recording what sort of demand is happening in the market and a disciplined process for when you react to that demand and start to look for the resources you need to match that. That’s the first one.

The second one is around the actual delivery of the projects themselves. You need to be able to deliver those projects consistently. You need to deliver them to the margin ideally that you won them at. You need to have a process in place to recognise early when those projects are going off track so you can do something about it. And then finally, I think you need a very disciplined process around forecasting. Because for me, if you can get the resourcing piece right, and you get the delivery piece right, then to measure how good those two processes are is really how accurate your forecasts are, and that’s a great measure of knowing how successful your processes are in those two areas.

I’m wondering if some of those processes—those key processes that you’ve mentioned—lead to more further down within the delivery part of a project, there has to be a process around change management… and there may be others as well. These all nest into a collection don’t they?

They do, but I think my definition of process would be that what you’re trying to do is to do things as early as possible. To spot problems—it’s very much about looking forward, not backwards. I think traditionally, the way people have worked their businesses they’re focused on what I call the operational whirlwind—they’re focused on the backend collection of data, how things are performed historically. But if you’re running a services business, what you’re really trying to do, as I said earlier, with sales and resourcing, is spot demand early. To areas that may be new service lines that you should be getting into where you’re getting demand but also getting out early of areas which are no longer successful from a project delivery point of view. Are you spotting where problems are going wrong early enough and trying to build all your processes around doing that? What I would recommend is to think about everything early, whether it’s change control, it’s challenging the customer early on whether or not things are changing and being bold enough to make that change.

If you have a process in place that fleshes out those unpredictable elements of a project, that presumably makes people better able to manage them and better able to deliver the right service to the customer?

Another example of that (many years ago, in a previous life), we were doing work with a large engine manufacturer for airplanes. One of the things we observed about their process was that they would always try and surface risk early. They recognized that a typical project lifecycle, particular in IT, sadly, is that you kind of do all the easy stuff first and it’s only at the end when you start to bring everything together which looks great on your project plan because you’re delivering probably ahead of plan. Then suddenly something towards the end of the project goes wrong and you suddenly realize that this is going to cost a lot more money than you expected to fix—which the customer is very upset about. What we did in their own experience was we changed our delivery process around and we decided to attack all the high risk items – the pieces for example looking integrating with other systems – we tackle those at the beginning of the project and sometimes that surfaced a big problem very early. It surfaced the fact that this project was going to be a lot more expensive than expected, or there was some key dependencies that we had to have ironed out before we go forward. But the benefit of that was, very little money and effort had been expended at that point and most times the customer said “that’s fine” or “spend more money, we understand why there’s an issue,” and then we were able to raise the budget. It’s just a lot harder to do that when you’re two weeks from going live.

You haven’t got the time to mitigate the situation you found yourself in, so that’s a good way of having a process that protects the project, and ultimately protects the customer. Is there a way of deciding the right amount of process for an organisation? I guess you could have too much, or you could have too little?

Important thing is: you don’t want process or processes sake. The other important thing to remember is that processes will evolve. You need a process, if you want to call it that, for actually deciding when you need to change those processes. When you’re in a startup, a small organization, in fact any new organization, you’ll tend to bring around you the people you’ve worked with in the past and it’s great and everybody will have that sort of sixth sense between them. You all know what each other are doing, you’ve got that sort of muscle memory of working before. As you grow, unless you’ve got an incredibly large number of friends that you’ve worked with, you’re going to run out and that’s the point when you lose control. And as I spoke about earlier, you won’t be able to sort of devolve power to other people unless you’re confident they’re going to do the same things in a consistent manner as your friends. By the same token, you have to make sure that your friends—the people you trust—aren’t bogged down by over-process. You do need a way of flexing that and having it be flex enough for those really experience people to not feel they’re bogged down, as John Harvey Jones would say, with red tape, but also that the other people are actually able to be driven in a consistent way through the process.

And I think those processes change. As you get bigger, then you’re going to inevitably need new processes. It might be when you’re small organization, you don’t need a process for purchase order cover to go out on site, because you know the customer you deal with, maybe it’s something you’ve worked with many times before and you trust them that if push comes to shove they’ll come and bail you out and pay the money. But as you get bigger, you will have to enforce rules that say please don’t go outside unless you have purchase order cover and be prepared for the consequences that you may lose the business. But ultimately, you’ve seen the impact of maybe running a project without getting paid for no fault of your own can have on your business but you’ve learned those mistakes and that again is an example of a process that will change, become more rigorous, as you get bigger.

Having processes in place is perhaps a sign of growing up as a company. Have you got any stories or examples? What happens when people get it wrong?

What people do is, they do get obsessed by commonality in processes. They’re confusing what they’re trying to achieve. So, an example would be I’ve put in a lot of financial systems across lots of different countries and it’s very easy to try very hard to get every part of the process nailed down. But there may be for legal, cultural, whatever reasons around different countries, why you can’t have a common processes across different countries. And what you should do is think about what the common denominator is. Think about all the processes that are very similar, nail those down, get those right. If you focus too much on the processes that will just be too hard to do, or there are real reasons why they won’t, you’ll end up antagonizing people which will mean the key processes you want to get in place won’t actually be absorbed, they won’t become commonality. The first thing to do is to think about the processes that are common. Get those bedded in and then maybe start to look at other things. But I think if you get that right you’re probably 90 percent of way there anyway.

You’re talking about prioritizing the important elements, aren’t you?

I think they would be much more clearly understood to people. Often people also confuse the systems they use for process. I sometimes talk to customers where they’ll tell me that this is the way they do things and actually, you find that this is the way they do things because of the constraints of the process they used to use. I’m old enough to remember when I filled in a timesheet, it went into a little orange envelope and a man or a lady would pick it up and take it to somebody else and put it in their in-tray. They would sign it off and go to the next person. What we do is build systems that mirror that process without the person moving it round. We don’t think actually what we’re trying to achieve here as an outcome is to get approval. What we’re not realizing is actually the outcome we’re trying to drive is to make sure that the information that we put down about what expenses we’ve claimed, for example, or what time we’ve done, is accurate so that we can bill the customer. It’s not about moving it between different people in the organisation.

That’s a great example because what you’re saying is it’s about being focused on the outcome you are aiming for and being open to the idea that the way you do it now may not be the most efficient way of doing it, but the process should be about achieving the outcome in the most efficient way possible. People don’t always like processes, do they? How do companies engage with their staff and help them to understand and see the value?

I think there’s a number of ways. First, people have to explain to everybody, make it very clear what the outcome is they’re trying to drive with the process. And if they can’t do that, then don’t put the process in place. The second thing is, typically a process is being driven around trying to drive an action of those people. And if it’s not driving to an action, then it’s not a proper process from my point of view. The third part is what I call measure what matters and sometimes a process is about gathering information, gathering data for somebody in the back office of the organization. And if people don’t realize why that information is important to them, or to the company, or both ideally, then again people won’t tend to stick to that process. It will require a lot of bureaucracy to make that happen.

The other area in terms of doing this, I think is people need to walk the walk as walk as talk the talk. Often you’ll see leaders in the business defining processes and they’ll be the least adopters of that process. A great example would simply be, in terms of using systems, using data and systems. They’ll go away and build a spreadsheet off-system and expect people to be using the system. And it’s no wonder that there isn’t the compliance there should be.

Once everything’s in place and everyone’s happily adopting it, what are the benefits of getting it right and having a good strong set of processes in place?

From a company point of view, it’s what I said at the the beginning, it’s about driving consistent outcomes. You’re absolutely sure that what you’re expected to do is what’s going to happen and it’s going to happen, not just in your own domain, but also in other countries, other divisions. And that allows you to grow. I think from a people point of view, they learn. We talked about less experienced people, if you’ve got a process that becomes part of that muscle memory, then they’re getting a more rewarding experience. They’re enjoying what they’re doing more, so it’s a benefit not just for the company, but for the individual.


Want an In-Depth Look at Kimble PSA?

Request a Demo