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:


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.)

Having your best IT technician deploy automation projects isn’t a bad idea – far from it. The problem lies when you leave them to do so alone.

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.

For example:

  1. A marketing manager makes an automation project request
  2. From there, an IT manager could research what’s needed in more detail
  3. Then, a frontline engineer would install and configure the fleshed-out automation project
  4. Meanwhile, a change agent delivers any needed training
  5. 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.

In other words, effective automation projects are delivered through planning, communication, and collaboration. They’re not delivered by a lone person within the organisation.

If only your company IT guy configures automation without any other input, you’ll only automate a fraction of what you could be automating.


Useful links

A beginner’s guide to BPR

ELI5: What is a change agent?

Rethinking your automation approach


Download