In April 2022 Gartner published an article about ten common mistakes when focusing on automation within a business.

We felt our customers would benefit from deepening and adding to their post.

Therefore here are the ten (same) points Garter already made, but explained in depth and backed up by our experience within this field.


01 - Falling in love with a single technology

Quite a common problem we encounter when assisting with introducing automation. Often a business decision has been made to purchase a certain license of an automation product. This puts a heavy burden on the department responsible for using the purchase to implement as much as possible with this. The idea is to guarantee a return of investment and to finally solve all the current problems.

The outcome often is a less than ideal workflow, driven by the desire to enforce the usage of a tool. Workarounds to compensate for missing features are implemented and the over-commitment increases the frustration with the limitations of that tool. A close collaboration with the vendor can reduce the daily friction and lessen the pain.

Lesson to learn: Do not let the tool guide the process of finding a solution, but identify the problem first and select the tool accordingly. Building too many fixed workarounds which make it hard to change an already implemented workflow, decreases flexibility of your technical team and will lock you into a process that takes away your possibilities to change and adapt.

02 - Believe that business can automate without IT

New products and solutions lower the level for first time usage for entry users and make a rapid approach possible. One challenge in automation lies in the seamless integration of processes and workflows into the existing environment and the building of new solutions which can be adapted and changed quickly if required.

The skill-set required to be able to do this usually lies outside of the scope of the entry users of automation. These background process tend to get more and more complex as they interact with other systems. Often an intimate knowledge of the interfaces between the systems involved is required as well.

Lesson to learn: Include your IT department from the very start and continue building their skill-set as well. Including a department dedicated to handle complex challenges to run an automation platform with many components is usually the best approach on handling the workload.

03 - Thinking automation is always the solution

Fun fact: It is not. For automation to have the desired outcome, the overall quality of the process must be as high as possible. While a bad process can be automated and improvement would usually be notable, the optimal solution is to replace the bad process with something more efficient and then automate if.

It is easy to oversee fundamental flaws or room for improvement when focusing on automation in existing processes. Usually bureaucratic obstacles and historical workflows that have resisted previous changes will survive the longest and are the hardest to approach.

Sometimes just changing the process order can have a notable effect.

Lesson to learn: Consider changing workflows and processes instead of automating them first. Not all problems are gonna be solved by automating them. This will in the long-term take you further and improve your processes at the same time. There are of course processes which can benefit from a partial automation, while showing drawbacks when automated completely. The best approach depends on the process itself.

04 - Not engaging all Stakeholders

This is a critical and easy mistake to make. It is quickly done to bypass other parties in the anxiety of improving and automating things. Automation can have a broad effect on the business and the roles other parts play. When at a customer, there are multiple factors at play that influence how automation will be met by other stakeholders:

  • Changes in processes that touch the responsibilities of stakeholders must involve those. Those changes can not be accomplished otherwise or will at worst lead to serious disturbances in the daily business.
  • Not involving and informing as many parties as possible creates barriers between groups.
  • Missing out on already existing processes, tools, knowledge and competence drains your resources.
  • Without interaction between all involved groups, only an incomplete bigger picture of any process an be established.
  • Other stakeholders might have other interests in mind that are not necessarily that obvious from the current point of view. Unknown dependencies can be discovered and from the stakeholders perspective other improvements might be desired as well.

Lesson to learn: Try to involve your stakeholders as much as possible. This will benefit your business beyond the automation effort. Playing with open cards pro-actively builds on trust and shows respect towards the interests of others involved.

Existing resources should be leveraged to accomplish the automation goal faster and with less wasted resources by using the stakeholders. There is no need to invent the wheel twice if it is already in use or even a better wheel has already been implemented. Look for cross-effects through out the business when it comes to what can be used and needs to be implemented.

05 - Failing to devote enough time to testing

In an unstable and brittle environment errors and mistakes are quickly carried through a process and create an unpredictable outcome.

Incorrect data or an unknown state of an environment can also effect the automated process.

The replaced human factor in automation cannot take any intervening steps and correct unforeseen situations. The quality of automation shows clearly how resistant it is to disturbances.

Lessons to learn: Testing your automation is an essential part of the implementation. You want to avoid it failing in production and result in unforeseen consequences. Time spent in testing is time saved in fixing downtime.

Testing the automation will not only make you familiar with how it behaves in non-standard situations, but also allows you to build in save-guards for any non-conformity situation.

Continue testing after the implementation to ensure the automation still is working as expected. This will increase confidence and competence in your automation.

06 - Wasting effort on overly complicated projects

While every process sooner or later might be automated, the effort required varies based on multiple factors.

Processes which require too many resources can endanger the whole automation process and bring it to a halt without reaching the goal. A process with high complexity is more likely to require more effort than can be committed to be spend on automation at this point in time.

Lesson to learn: Pick the easy processes first, automate them, learn from them and approach more complex processes over time. This will strengthen trust and confidence into automation from the beginning and deliver results quickly.

Starting with automation you want to gather the low hanging fruits first and separate them from the effort-intensive (high hanging) ones. One key strength of automation is the ongoing visibility of progress and completion during implementation. This is especially true in the beginning of the journey towards automation, where results weight most.

A kind of matrix or criteria is required to categorized processes into the ones worthy automation and the one that are not (or should be postponed).

07 - Treating automation as simple task replication

The direct approach in getting a process from non-automation to automation is to transfer the steps directly into the automation framework.

This will guarantee to reach automation quickly, but waste opportunities for improving processes.

The result is a 1:1 replication of the non-automated process into the automated process without any modifications at all.

Lesson to learn: Make us of new possibilities during the automation process to apply changes to existing process.

An automation framework is certainly able to mirror manual processes to any extend, but will also offer additional solutions. Making use of these features to improve existing processes even further should - as an option - not be dismissed.

The results that additionally manifest due to these improvements are substantial.

08 - Failing to monitor in post-production

As long as the automation is running and passing all tests, all is good.

Quickly it will be discovered that errors beyond the automation effort will manifest in the untested area behind the automation in post-production.

Surely those cannot be addressed as well?

Lesson to learn: As briefly touched in point #5 the process of automation is not finished when a process has been migrated. Not at all.

In order to continue to be able to deliver good results and to keep the speed advantage of automation, the configured process will required ongoing monitoring and adjustment.

Prepare to provide resources to maintain the automation status after implementation. Automation is an ongoing process and will not end when the process as been migrated.

The benefits of automation are bought with a strict frame of limited flexibility on adjustments. To keep errors out of the automation process these must be constantly monitored. Problems will occur and need to be addressed.

09 - Using the wrong metrics to measure success

As a part of automation, extended monitoring is usually applied. The automation, deployments, file creations, etc are monitored. When all tests pass and all status are green, automation is working and the goal is reached.

Still this does not reflect the real success of the process automation.

The success of automation is not reflected by the framework running correctly, but rather by the automated process improving beyond the initial state. The key point here is to focus rather on the outcome for the automation to support than the automation it self.

As an example: It is irrelevant if the automatic scripts for running deployments are running correctly, while the number of deployments is not increasing or the time between commit and the change hitting production is not getting smaller.

The reasons for this might be a low level of acceptance of automation by the developers or a step of approval of change that kills the deployment time. Here the automation process does not succeed due to these factors, while technically it is running fine.

Lesson to learn: Focus of the outcome of the process to measure results, not so much on the result of automated processes itself. While it is important to know that the automation is running correctly, this is not necessarily the correct measure-points to evaluate success.

10 - Ignoring the culture and employee impact

Treating automation as a purely technical endeavor sets a too limited focus on the tasks ahead.

Automation is only a part of a transformation within the DevOps framework. As such it thrives best with other supporting factors and gains the best results then.

A supporting culture around automation is for the benefit of everyone, while a culture for example build around slower changes, hierarchies or slower changes will work against it. It is equally important to not only respect but actively support and contribute to the existing culture. This will make it easier for everyone to adept where necessary and not feel outside the changes.

In addition automation will affect some employees directly by freeing them from mundane tasks or speeding up their workflows. This may or may not be appreciated. Integrating everybody into the changes and efforts increases the understanding and tolerance for way towards automation.

The final group that might feel the change are the customers as well. With processes speeding up, becoming more robust in terms of creating less errors and more reproduce-able outcomes, the service satisfaction and quality of work will probably increase and make the product more competitive.

Lesson to learn: The effect of automation goes beyond the technical parts and requires also to integrate a human part. Include the people involved to reach the optimal outcome of your automation efforts.

While implementing changes on the technical front, the cultural changes need to follow and adjust.


Daniel Buøy-Vehn

Senior Systems Consultant at Redpill Linpro

Daniel works with automation in the realm of Ansible, AWX, Tower, Terraform and Puppet. He rolls out mainly to our customer in Norway to assist them with the integration and automation projects.

Just-Make-toolbox

make is a utility for automating builds. You specify the source and the build file and make will determine which file(s) have to be re-built. Using this functionality in make as an all-round tool for command running as well, is considered common practice. Yes, you could write Shell scripts for this instead and they would be probably equally good. But using make has its own charm (and gets you karma points).

Even this ... [continue reading]

Containerized Development Environment

Published on February 28, 2024

Ansible-runner

Published on February 27, 2024