The 14 common pitfalls awaiting your Automation team …and how to avoid them

Whether you’re looking to train up your automation team from internal staff or whether you’re looking to hire some external experts I want to make you aware of 14 common pitfalls that I and my network have noticed new automation teams making time and time again. These issues can manifest at project level when you start to get going at automating

1 Lack of senior business leader buy-in

The number one thing every automation team should make sure they have is senior stakeholder backing. If your senior stakeholders believe in the technology and believe in the benefits of your program and projects, you can move forward at pace without getting too stuck and any blockers can be quickly removed.

2 Lack of IT ownership and understanding

It’s vital for IT to be bought in as well. They will need to take ownership on the part they will need to play if you want to roll out automation company-wide, giving you support on infrastructure and the IT side of things, so that you can focus on automating business processes. IT will need to understand what RPA is and that robotic process automation is very different to IT software development. RPA is more akin to digital workers rather than software development

3 Missing or unavailable data

You’re inevitably going to come up against a lot of missing data and unavailable data when you try to analyse your businesses processes, and when analysing your teams and the business as a whole. You need good data to show you where the best automation projects are and to estimate how much value you can deliver back to the business.

You may need to do a little leg work to measure the current state of processes and activities, and if you’re lucky you may be able to extract data from applications and databases to find the data that you need in order to determine which projects are worthwhile. Sometimes (well more often than not) data just isn’t available, but you at least need a consistent measuring approach so that one project/opportunity can be compared to another.

4 Staff’s resistance to change

Staff buy-in (the end users of the automation, or those who will work alongside automation) is vital. If staff are engaged in the various automation activities and understand the benefits that you are going to bring to them, their team, their business this will accelerate progress and roll out. Otherwise you’re going to have them feeling a bit resistant to any changes you’re trying to implement on them, that they haven’t been a part of.

Digital transformation should be co-creation between the tech experts and the business experts. When staff are involved, and it’s their change they will gain the understand that you’re there to deliver solutions to help them achieve their goals and their targets faster and exceed them. Together you can solve the problems and inefficiencies causing them to have to work late nights, be overloaded with work, and together your solutions will be fit for purpose, actually benefit them and they will be happy to use!

5 Loss of traction

Loss of traction is a big pitfall when you’re running an automation program and is a sign you’ve bitten off more than you can chew. Perhaps you’ve start too big, it took too long to develop and now you’ve hit a brick wall.

A better approach, especially when you’re team is new, is to build up momentum slowly and progressively starting with smaller simpler automation projects which gets people excited, get business teams brought in and then you can keep scaling up by building bigger, more complex and exciting projects. Starting small and building fast also gets you automation team to get your deliver processes perfected.

Practice the steps slowly then you’ll be tapdancing to work in no time

6 Unclear roles and responsibilities

If no one knows what anyone else in the delivery process is doing then you’re just going nowhere fast. Throughout the deliver process everyone involved needs to know what their role is. Everyone in the implementation process needs to understand what’s expected of them and what to expect of other people so written down roles and responsibilities and have everyone agree, leaves nothing up for interpretation later down the line.

You can use what’s called a RACI chart to help clarify what people need to do. For each action or activity define:

R = who is responsible for the action. I.e. who actually does the work

A = who should be accountable if the work isn’t done, is subpar or is delayed

C = who can the person doing the work consult to get expertise on a subject

I = who should someone Inform when the activity is done …or has issues

Each of the 4 architypes above can have multiple people apart from Responsible. There needs to only be one person who take responsibility for issues

7 No clear governance model

A governance model are the steps that determine when something is done, what good looks like and what to do when things go wrong. Without clear governance process (coupled with clear roles and responsibilities), you and your team will find themselves wasting a LOT of time chasing people, going around in circles and being batted from left to right trying to work out what to do and who to go to.

To avoid these headaches, make sure you have all your key stakeholders agreed on the governance model and if something slips you know how to escalate that to get it fixed

· Who to speak to (Who deals with servers? Who are the application owners? Who deals with username/password creation?)

· How is it done (what is the process? Multiple people/activities involved?)

· What is the criteria (? What requirements for this request? What does ‘good’ look like?)

· When will they deliver it by (Is there a timeframe? How long some a testing environment take to set up?)

8 Lack of process clarity

You effectively become a process expert yourself when you analyse a process thoroughly. If not, how will you be able to translate the business problem into a technical solution, in enough detail for the developer to build?

In automation, a Process definition document (PDD) is used to define clearly and unambiguously what the process, from your discussion with the subject matter expert(s) or process owner(s). When you understand exactly what the process looks like and what the improved solution looks like, then the developer should have everything in the PDD that they need.

9 Process documentation differ from what workers do in reality

It’s not advisable to rely on just the work instructions of a process or training manual because that’s probably been sitting there for years collecting dust and it’s not up to date. Most likely the team has found better ways of doing it, or they’ve need to change the process due to the systems being updated or the applications have been upgraded.

Process documentation is a great starting point but make sure you’re speaking with the team on what they do now, how it can be better and then co-design the solution.

10 Automation behaves differently in live environment to how it worked during testing

OK so your developer tested the automation, you thoroughly tested it again during user acceptance testing (UAT) and it worked perfectly ..but then when you launched it, your automation broke down, generated lots of exceptions or didn’t work as expected.

This it’s uncommon as development and testing environments can be slightly different to the real thing, even the data you used in testing might be slightly different, or the version of the application might be a newer version in the live environment.

As you can’t be 100% sure what will happen when you’ve launched your automation it’s important to have a “hypercare” phase, sometimes it’s called “warranty period” or “post go live support”. This allows your team to babysit your newly launched robot until you and the business are happy to let it go on it’s own

11 Lack of time and commitment from process owners and users

When you agreed upfront with team managers how much time and commitment you will likely need your process owners to dedicate to working with you on a project, it can ensure your project isn’t delayed by unavailable subject matter experts (SMEs), or your tempted to continue on a process which isn’t fully defined.

Automation delivery requires full understanding of the process that you’re automating in detail, and you can document that clearly and unambiguously. This is why the number one pitfall (and number one solution for success) is senior buy-in. Senior stakeholders can unlock the doors and make time for that person to commit time with you. Automation design and delivery is not a one-and-done thing, it’s a process which needs several sessions for defining, designing, and testing the solution. With a committed process expert, you have a better chance of getting it right first time.

12 Poor stakeholder awareness and understanding of technologies

With automation, your stakeholders are the business, they’re IT, they’re HR and Change management. All these teams will need to get to understand what this technology is, where they fit in and how it can benefit them. And from an informed position, they will have feedback on how this technology should be used.

Automation can’t be built in the dark corner of the business and be successfully rolled out, because once it’s launched, it just might not get used, or your program could be blocked and never see the light of day.

To get alignment and buy-in company-wide, run some awareness sessions, some one-to-ones, or/and host ‘lunch and learns’ to educate teams on what this technology is and how powerful it can be to help them in their day-to-day jobs, and progress the business as a whole.

13 Unrealistic expectation

Sometimes automation and technologies in general can be a little oversold, or at least misunderstood, so people may have the wrong understanding of what it can do and how fast it can do it. Automation is a powerful tool, it can take just a matter of few weeks to get set up and it is typically a lot lower cost option to software development in many cases, but it’s not a silver bullet.

Automating business processes does take sufficient upfront investment of time and commitment from staff to get solutions implemented, so it’s good practice to be clear on how long it’s most likely to take (E.g., up to 2hours a week spread over 6–8 weeks, or 3x 2hour workshops) and use a cost-benefits calculator to estimate the potential value the solution can deliver.

14 Choosing the wrong process

I wanted to leave this to last, as this is probably the number one pitfall that your team needs to stay away from. Choosing the wrong process is one of the most common reasons for automation failings and why projects stall. When a team works on a process that isn’t suitable for the technologies that they have, it’s too big, or if it’s too complex, it can stall the entire program as stakeholders loose faith.

Many experienced automation teams use complexity calculators to estimate how difficult a process would be to automate, and they use suitability checklists to filter out processes that aren’t suitable for different type of RPA and AI solutions.

Like and subscribe to my YouTube channel Tony IA (Intelligent Automation, Simplified) for videos created to simplify intelligent automation for business leaders and professionals who are new to automation to level-up your knowledge. Become empowered on how you optimise your business and discover new technologies, in a lean and accelerate way. You can also learn more from my book, Business @ the Speed of Bots: The AEIO YOU method HOW TO IMPLEMENT ROBOTIC PROCESS AUTOMATION THAT SCALES. Get ready for the new digital transformation age for more information. The foreword is written by Guy Kirkwood, who is the Chief Evangelist at UiPath, and a very well-known advocate of RPA with over 20 years of experience in outsourcing.

🔥🔥🔥 SIGNUP TO THE NEWSLETTER🔥🔥🔥

FOR FREE GIFTS, FREE DOWNLOADABLES, TOOLS AND TIPS, AND MORE EXCLUSIVE STUFF https://iasimplified.pro/newsletter/#sign-up