Who should deliver automation projects?
In a typical enterprise comprising various teams and functions, automation projects are diverse to say the least.
Each project will detail a different task or set of tasks. Each project will likely support a different department. And each project will drive a different series of changes, requiring different levels of disruption mitigation.
So, who exactly should all that responsibility fall to? Who should deliver automation projects?
The steps required to deliver automation projects
You’ve decided to start automating, and found the software solution you’d like to implement. Next, then, delivering an automation project involves:
- Identifying tasks to automate (and getting any needed approval to do so)
- Ensuring the processes in question are ready for automation
- Re-engineering processes that aren’t suitable for automation — i.e., if they’re broken or redundant
- Configuring the automation to complete the tasks in question, i.e. writing IF statements and building out logical workflows
- Deploying the automation and ensuring it runs smoothly
- Helping disrupted teams (i.e., teams that now have part of their daily tasks automated) adapt to the change
The one true deliverer of automation projects?
The typical or perhaps instinctive practice when it comes to delivering automation projects is to have one person in charge. This is usually someone with IT skills/from the IT department. (I.e., someone technically-minded, with strong knowledge of the company’s internal tech stack.)
For example, having a single deliverer of automation projects would often mean that one IT team member is responsible for identifying automation opportunities across all departments. They’d be responsible for understanding exactly how the current processes work, and how they can change to suit the team. They’d then have to configure the automation, deploy it, and help the affected teams adapt.
That’s a lot for one person — and relies on knowledge of the day-to-day workings in departments that person may not know well.
Clearly, real life is not so simple as to allow a single team member to deliver automation projects.
The person best suited to deliver an automation project can vary from project to project. Moreover, it’s rarely just one person in the organisation that will have a hand in delivering automation projects.
A cross-team effort
To deliver effective automation projects, you’ll need cross-organisational collaboration. That is, members from different teams and departments will need to communicate needs, limitations, and possibilities, as well as share skills.
- A marketing manager makes an automation project request
- From there, an IT manager could research what’s needed in more detail
- Then, a frontline engineer would install and configure the fleshed-out automation project
- Meanwhile, a change agent delivers any needed training
- And throughout all this, there’s an operations manager to oversee the project and assist with issues at any stage
In this example, there’s no one person, or even one team, delivering the proposed automation project — it’s a cross-team effort.
A big-picture approach to automation
Automation is versatile, and its application in real-world projects will be too. Without effective collaboration, this versatility goes untapped. And, as a result, teams miss out or get impeded by mishandled (or simply missing) automation projects.
If only your company IT guy configures automation without any other input, you’ll only automate a fraction of what you could be automating.
- A beginner’s guide to BPR
- In-house automation vs outsourced automation: the pros and cons
- ELI5: What is a change agent?
- What is a chief automation officer, and do you need one?
- Rethinking your automation approach