Steakholder, sorry, Stakeholder Capitalism is one of those buzzwords today. Seemingly, we should all be included in every decision that any company makes, because of externalities and such. But I digress, this is an automation blog, not economics.
Nevertheless, recent events conspired to remind me of the importance of stakeholder management in the context of RPA projects. So I thought it might be interesting to share some deliberations about who should be consulted for an automation project, why that should be so, and when you should do it, even though it is, admittedly, not one of my strong suits.
Whenever you ask a question, you run the risk of actually getting answers. Worse, sometimes you get answers you don’t like. So it’s best not to ask anyone and just go ahead with your automation project in secret, right? That will lead to a fast implementation without annoying interference from affected parties.
Well — as you probably inferred from the sarcastic style of the previous paragraph — this is unlikely to lead to good outcomes. Generally speaking, we resent having a fait accompli hoisted upon us without having any say about it. This usually leads to more resistance to your project, not less.
Think about it: if somebody tells you, “Hey, this part of your job you spend a day a week on will now be automated, thanks for your service,” how would you feel? The answer is likely one or more of: 1. angry, 2. threatened, 3. marginalized, 4. belligerent. Not a good combination.
Still, is there a situation where some amount of flying under the radar makes sense? Sure:
- There are PoCs and pilots, as well as emergencies where you need or want to keep the team small to move fast
- You might actually have a mandate to clandestinely cut people out, although this is a dick move by the company, so expect push back
- There could be some dysfunctional team dynamics which require leaving someone out
If you’ve read this site for any length of time, you’ll know what I’m going to write next: there is no one-size-fits-all answer to this. It depends on the degree of automation, your approach, the size of the project, whether it’s attended or unattended, etc.
Discussing this in depth is beyond the scope of the blog, but I’ll try to give you a few ideas about possible steakholders you might have to involve in different situations.
You’ll need them as subject matter experts (SMEs) to tell you how to do the task, at the very least. But usually they’ll also want to be involved in deciding which of the tasks is most useful to be automated for them. In the end, these are your customers (in most cases), so treat them with respect.
Also, don’t underestimate the amount of mouth-to-mouth buzz that your colleagues can generate if you genuinely make their lives easier. This can generate a lot of demand for your automation program.
Involve at least one SME from the start (that is one for every part of the process that is to be automated), for more complex processes with a high degree of variation, you should have more than that. Focus on recruiting volunteers or representatives and make sure they commit to the project and have a mandate to spend time on it, but don’t go overboard and invite the whole department.
You need a business sponsor for any automation project to enlist resources and put some credibility behind it. For larger projects, especially those with a high degree of visibility, getting executive sponsorship is also a strict requirement to highlight their importance.
Involve before the project even starts.
If you aren’t part of the CoE (or whatever you call it in your company), they should at least be aware that you’re working on an RPA project, especially if you plan to use their infrastructure. It’s also often worthwhile to set up some feedback or review sessions so they can help you out when you get stuck.
Involve as early as possible.
Especially when starting out with your program, you need to involve IT. They have to set up the environment, provide credentials, tell you where to find data, and so on.
Equally importantly, IT could always shut your project down if they choose to, by nitpicking some security concerns or refusing exceptions to IT policies, so it’s important to get on their good side.
Involve early, but don’t necessarily bother them with every project once you have a well-running operation. If you are in the IT department, this is obviously much easier.
Some projects carry legal or compliance risks. For example, in banking, sometimes a regulatory requirement is that at least two people see and approve a certain document, which can complicate automation.
While I hate red tape as much as the next person (probably more, to be frank), similar to IT, these departments can shut down your efforts at any time and therefore need to be involved in those kinds of projects.
So: know your risks and involve the lawyers early when needed. Your SMEs should be able to point out when that is the case, but it’s better to ask too often than too rarely.
Sometimes, especially in highly political companies, when you leave out certain people, they get a bee in their bonnet and try anything in their power to hurt you. This can have any number of reasons, from a (perceived) violation of “their turf” over rivalries among managers or departments, to simply not liking your nose.
There’s no easy way to deal with roadblocks, but a sizeable percentage of them may actually have genuine grievances (shocking, I know) that can be alleviated by involving them in decisions. But be careful not to give too many people veto powers.
Sometimes you need customer feedback, support from a different vendor, there may be an automation-breaking bug in a target application, regulatory agencies have something to say about how things are done, or perhaps you have to ask your mum for permission.
In any of these cases, remember that not all stakeholders work in your company. A very simple example: you want to create a robot to handle order entry into a legacy system, but some orders are placed on your website, and the customer should receive “real-time” feedback on whether the item is in stock.
This can be difficult to pull off with RPA due to the inherent time losses involved — using GUI automation, starting up the robot, etc. So make sure to involve customers to see how much waiting time is acceptable and adjust your design accordingly (including looking for non-RPA solutions).