Unconventional Automation Delivery Methodologies

Automation lifecycle and delivery methodology can significantly impact the success or failure of automation implementation. Consulting firms all have their own version of the delivery methodology and lifecycle they prefer as they deliver automation projects. These methodologies and lifecycles are often well defined and robust, complete with key deliverables, checkpoints, and approvals. This structure is there for a reason and can be very helpful in pushing a project to the finish line promptly while ensuring quality delivery. 

As an automation consultant, I have been a firm believer in implementing robust methodology and strictly following a well-defined delivery lifecycle. However, I recently encountered a client successfully implementing Robotic Process Automation (RPA) without this structure. They successfully achieved Key Performance Indicators (KPI) with no Process Definition Document (PDD), Solution Design Document, Code Reviews, or Runbooks. I was curious how this client (I will refer to them as Client A going forward) was having so much success without documentation, code reviews, and checkpoint meetings. So, after working with Client A for some time, it felt appropriate to capture and share their somewhat unconventional approach to automation delivery. 

Client A Background

First, some background on Client A. Client A is a fortune 500 entertainment company four years into its automation journey. They primarily focus on RPA using UiPath and Automation Anywhere as their tools of choice. The automation team is small, consisting of around 4-6 team members.    

Unconventional Approach

As we look at Client A’s approach to automation delivery, the reader will notice differences from traditional RPA implementations. It is important to note that this delivery approach is not the result of poor planning or lack of knowledge. This approach is well thought through by Client A, and they are intentional about its implementation. Let’s look at how a typical automation project will look from the cradle to the grave. 

First, requirements gathering: Client A captures requirements a bit differently than your traditional PDD or as-is document. Client A has business users record a video of themselves performing the as-is process. The business will then fill out a 1-page memo with a high-level description of the process to be automated. An automation expert then meets with the business and talks through the process. The automation expert will decide if the process is a good candidate for automation and move forward with development. 

From there, the automation expert will begin developing the process. You may notice that the automation expert is playing the role of the business analyst and developer so far. This is the first unique point to note. In Client A’s model, all team members perform all the responsibilities of any one person in a traditional RPA lifecycle. We will come back to this later. Another point of interest, there is no future state or Solution Design Documentation. This is done (or instead not done) for a few reasons. 

1. Client A targets low-hanging fruit. They do not target large-scale end-to-end processes.
2. The automation expert plays the role of the solution architect and the developer. This means they are expected to design and think through the most eloquent solutions as they develop.

The developer or automation expert may meet with the business as needed for touchpoints and various check-ins throughout development. There is also no formal testing. The developer has the authority to determine how much testing to do and how involved the business should be in testing. Once development is complete, the automation expert will demo the bot for the business and, upon business approval, will deploy the bot.  

The automation expert will then complete a prod support catalog entry upon delivery. This is very high-level information about the bot and is used for production support. 

What Stands Out

Anyone familiar with a traditional delivery approach will notice a few things that stand out with Client A’s method. First, having “automation experts” or a single person responsible for the project from end to end is somewhat rare. Typical RPA engagements consist of a process analyst, solution architect, and developer. It is not uncommon for a project manager, production support manager, and multiple other players to also be involved in a single project. For a single team member to implement solo, it requires highly competent team members who can serve in multiple roles and who can be trusted to work independently. This means they must have good communication skills for the business-facing functions alongside strong technical skills to create high-quality code. The team is results-oriented, and leadership provides the team members with personal autonomy to provide the best solution.  

The next point that stands out is minimal documentation. A few things make this possible. The first is the type of processes Client A is choosing to automate. RPA is often used to automate large, complex processes. While this is certainly possible, Client A usually stays away from this type of project. Client A recognizes that RPA thrives at low complexity, repetitive processes. Though they will explore more extensive processes, smaller processes are preferred, thus easing the burden of heavy documentation. Second, there is no handoff between team members. As mentioned above, one team member is responsible for the entire process; therefore, any documentation for handoff purposes is unnecessary. 

Another point of interest is how quickly things move at Client A. Client A is a very lean organization. For example, access is usually approved and granted in hours instead of days or weeks. Business units and the automation team often jump on calls on short notice. It is also apparent that everyone is good at their jobs. This points to a culture of hiring highly competent individuals. It also mitigates the need for project managers. 

Conclusion 

Automation experts delivering end-to-end automation services in a fast-paced environment; this is Client A’s approach in a sentence. After seeing the success of Client A, I feel strongly there is no single delivery approach that is best for every client. For consultants, we must be constantly concerned with best serving our clients. Carefully examining an organization’s automation goals, team members, and culture is an excellent start in determining the best delivery approach for any specific environment. Maybe a highly regulated delivery methodology and lifecycle complete with checkpoints, documentation, and strong oversight are critical for success in some environments. But not for all.