How to Avoid Common Process Automation Project Pitfalls

Blog: Solutions Review - Business Process Management

As part of Solutions Review’s Premium Content Series—a collection of contributed columns written by industry experts in maturing software categories—Bernd Ruecker, the co-founder and chief technologist at Camunda, shares some tips on how to avoid some of the common pitfalls that can occur in process automation projects.

More than nine in 10 IT leaders say they consider process automation critical to achieving business optimization and efficiency, and organizations launch more automation projects than ever before. But many initiatives are bogging down shortly after they get started. Organizations lose a lot of momentum when they don’t follow a proven path and, as a result, often focus on the wrong things.

Here are seven solutions to common pitfalls organizations encounter in the early stages of process automation.

1) Don’t start with big strategic endeavors too early in your journey.

Don’t try to create reusable artifacts or even a bespoke process automation platform as the first step in your process automation journey, even if you are a big organization that wants to scale process automation. Start slow. Start just a couple of projects to help you become familiar with process automation in general. An initial proof of concept allows you to learn about process automation in your environment. This will help you settle on the right tool stack and the type of software architecture to instill later in the journey.

Keeping reusable artifacts up to date or fixing bugs can be very time-consuming once those artifacts are released. By starting small, you can understand the fundamental common characteristics of projects in hindsight, which allows you to make significant decisions about what reusable artifacts will bring the most value.

2) Avoid a top-down adoption motion

Top-down adoption, where tooling is decided on at the top and handed over to development projects, can stifle a process automation initiative. That’s not to say you can’t define company-wide recommendations, but you should still leave the project teams enough room to make preferred tool choices independently. This will increase the chances of tools being embraced rather than rejected.

It works better to create an environment that allows for bottom-up growth instead. Most successful projects start with a developer learning about a tool somewhere and playing around with it. Once they understand the possibilities, they become enthusiastic about it and test it out by pushing a project into production. At this point, a proper evaluation of the tool can be conducted. A good balance is to develop an environment where grassroots initiatives can start and then support the most promising ones to drive adoption. Scaling adoption should always come as a second step.

3) Resist the temptation to create your own platform

There are usually two reasons to build such a platform: companies don’t want to depend on the vendor. They need some integration into company specifics that all projects can leverage. But making such a platform is a risky endeavor for multiple reasons. It’s hard to set up a process automation platform, and attempting it will distract you from delivering business value. It makes it hard to include learnings gleaned from later projects as you settle on specific architecture primitives very early in your journey.

4) Work agile and concentrate on delivering business value from day one

This is a critical step in the process. You have to get started with a concrete project that solves some immediate business pain. Avoid strategic platform initiatives for as long as possible. Doing too much strategic work too early has a high risk that you don’t deliver any business value for a long time. Not to mention, you’ll likely get stuck shaping a complex platform without understanding its use case. Favor agile development approaches that develop workflow solutions iteratively and incrementally. This allows you to align with business goals, learn fast and let these learnings correct your course.

5) Avoid starting with process architecture or process landscape initiatives

Some companies try to capture all of their processes in a process landscape and sketch out those processes first, often as a basis to prioritize automation projects. But you can’t expect to derive ready-to-be-used process models for your automation projects upfront. When you know how a process automation project should work, you’ll be better able to design process models and sketch process architectures later.

6) Embrace and learn from failures

Embrace a culture where failures are openly discussed to learn from. Vendors’ or consulting companies’ best practices (or books) can be a good starting point, but they can’t replace finding your way. Once you get going, use those learnings to improve your practices. An excellent way to make sure essential learnings are captured is to transform the early project teams into a center of excellence, allowing those folks to shape and consult upcoming projects.

7) Let project teams breathe and make their own decisions

Last, avoid rigid standardization at the outset of an automation journey. Project teams need the freedom to choose the right tools and have a say in the best practices the organization will use in its process automation journey. Teams must understand that their decisions will impact future iterations of the project and decisions regarding platform technologies. But they need to have a certain amount of autonomy to encourage experimentation that could lead to greater value over time.

A successful process automation project usually follows a step-by-step approach that starts slowly, with a pilot, followed by a handful of projects to foster learnings that will guide future steps. Moving forward step-by-step, not trying to do it all at once, will help automation journeys navigate past avoidable early pitfalls.