UiPath RPA Automation Implementation Methodology Fundamentals

Introducing the UiPath Automation Implementation Methodology

UiPath devised the Automation Implementation Methodology to provide a common roadmap for implementation teams across the globe.

Depending on the organization's automation program maturity, without having a well-thought-through and tested plan, implementing a new automation project may prove quite difficult. This methodology also ensures consistent quality, faster and more reliable implementations, and quicker process handovers.

UiPath devised the implementation methodology to provide a common roadmap for implementation teams across the globe.

There are four common implementation models.

1. In an organization looking to automate its business processes, there is a department taking the role of the Client, and then there's an automation Center of Excellence (CoE), providing the UiPath expertise and capacity to implement the automation through an Implementation Team.

2. The second model involves a client organization looking to automate its business processes using the UiPath Business Automation Platform. The organization turns to an external automation services provider and typically a UiPath official partner, which can provide the required expertise and capacity through an Implementation Team.

3. In the third model, the Client organization obtains both the licenses and the implementation services from UiPath. In this scenario, the UiPath Professional Services team sets up an Implementation Team to provide the required services.

4. The Client organization passes on its implementation work to both a partner as well as UiPath.

The UiPath Automation Implementation Methodology stages

Companies that are serious about automation will set up and execute automation programs, consisting of many automation projects across different business areas. These automation programs are managed and delivered by Automation Centers of Excellence, made up of capable automation practitioners.

The automation implementation methodology presented here is meant to guide throughout the entire process of turning an automation idea into an automated process. So, in an automation program, there will be different implementation teams delivering different automation projects, each of them following the methodology.

The Automation Implementation Methodology

Having an organized lifecycle of a project offers consistent quality, faster turnarounds, and more successful implementations.

There are eight stages in the UiPath Implementation model, starting with Kickoff and ending with Project Closure. At each stage, the Automation Implementation Team collaborates to meet the expected output.
In general, the Implementation Team consists of Solution Architects, Project Managers, Business Analysts, Infrastructure Engineers, and Automation Developers.

Here is an easy-to-refer guide to the templates.

Application Access Tracker

What is it? This document is used to record and track access requests across the execution of an implementation.
Who uses it? Solution architect, infrastructure engineer

SDD

What is it? A comprehensive blueprint that outlines the specific details and workflows of an automation solution.
Who uses it? Business analyst, automation developers

Issue Tracker

What is it? This is a document maintained throughout the implementation project and is used for logging all issues encountered during Development, UAT, and Hypercare.

Who uses it? Automation developers

PDD

What is it? The Process Definition Document outlines the business process chosen for automation. The document describes the sequence of actions performed as part of the business process, the conditions and rules of the process before automation (AS IS), and the new sequence of actions that the process will follow as a result of preparation for automation (TO BE).
Who uses it? Business analyst, process SME, process owner, solution architect, and development lead

Runbook

What is it? The runbook is created as UAT is ending. This document will be passed on to the support team and any future developers as the primary resource on how the automation runs and how to debug any potential issues.

Who uses it? Support team, development team

Code Review Template

What is it? This document is intended to document any defects in the code. The document also tracks the severity of the issues and can be utilized as a resolution tracker.
Who uses it? Development team

Project Management Workbook Template

What is it? A structured tool used for organizing, tracking, and managing various aspects of a project efficiently.
Who uses it? Project manager

Technical Testing Plan

What is it? This document is intended to outline testing as a criterion for completing Development & Testing and entering User Acceptance Testing.
Who uses it? Solution architect, automation developers

Technology Checklist

What is it? This document contains all technical prerequisites to start development in an automation implementation project.

Who uses it? Solution architect, infrastructure engineers

UAT Planner and Test Case Template

What is it? This document is used to document the UAT test cases and the results.

The roles and responsibilities involved in an automation implementation

The Implementation Methodology works smoothly and produces the best results when different people with different skill sets work together across the different phases.

The Implementation Team

Each member of the Implementation Team plays an important role in the implementation process. Every role, including project manager, business analyst, solution architect, automation developer, and infrastructure engineer, has a set of primary responsibilities.

A team with clearly defined roles and responsibilities makes a project effective. For an automation project to be successful, each role must perform its responsibilities effectively.

The Client Team

The Client Team usually has a dedicated team of professionals, such as the engagement sponsor, client project manager, process owner, process SME, client IT team, support team, and automation operations manager.

Note that not every client team will or must have all of these roles.

Each role performs a dedicated set of functions that are crucial for the project to be delivered within budget, time, and scope. They also actively engage with the Implementation Team.

Solving common implementation challenges

Expectation setting

What is it?

High client satisfaction is always a goal of an implementation. One of the best ways to ensure your client is satisfied is by setting expectations early on about what deliverables the client should expect and when they will be delivered. If client expectations differ from what the implementation team is set to deliver, the client is likely to be unsatisfied at the end of the engagement.

At what stage should expectations be clearly defined and communicated?

At the beginning of implementations, the Kickoff stage is where the high-level expectations for the project will be defined and communicated. At this stage, it is important to reiterate the key points present in the SOW. However, setting specific expectations around the process itself will happen at the Business Case and Technical Validation and Process Analysis stages.

How can we solve this challenge?

We should begin every engagement by understanding the customer's expectations.
After gathering enough information from the contract, the next step is to directly confirm the customer’s expectations and deliverables by having a conversation with them.

During the conversation, start by explaining what you already know about their expectations. This can make the conversation more efficient and help ease into asking about details you need to clarify.

By using the Project Kickoff template, you can set expectations and document them. Afterwards, during the Kickoff meeting and by using the deck you can make sure that customer expectations are aligned with what you are actually going to deliver.

During the course of the engagement, you should have a weekly project status meeting to ensure short-term and long-term expectations are aligned between the customer and the implementation team. We can use the Weekly Project Status Update deck for this purpose.

What resources to use?

Project Kickoff document
Weekly Status Report document

Scope creep

What is it?

A common concern in any software development project is scope, or what you formally agree to deliver as part of an engagement. In any project, scope is determined early and should be reiterated often to keep everyone on the same page about what is being built.

At what stage should scope be clearly defined and communicated?

The high-level scope for the project is set at the beginning of implementations, in the Kickoff stage. Later, at the Process Analysis stage, the scope for a specific process or automation is finalized with the approval of the PDD, which defines the scope in detail.

How can we solve this challenge?

As a starting point, we need a Statement of Work (SOW). We start by reconfirming the SOW scope during the Kickoff call and explain how any changes to that scope will have to follow the Change Request process. Anything that might affect the scope will also be addressed during the Weekly Project Updates.

What resources to use?

Statement of Work
Project Kickoff document
Weekly Status Report document
Change Request template
Process Design Document (PDD)

Unorganized User Acceptance Testing (UAT)

What is it?

Unorganized UAT can happen if UAT tasks and responsibilities haven’t been clearly explained beforehand about who is responsible for various steps.

At what stage should UAT be clearly defined and communicated?

In the Kickoff stage, Process Analysis stage, and Solution Design.

How can we solve this challenge?

It's important to have responsibilities for UAT clearly communicated early in the engagement. During Kickoff, the UiPath team can go through the RACI Matrix and thoroughly explain how the UAT phase should happen. It's also good to try and estimate the effort needed from the UAT participants on the customer's side as well.

Next, during Process Analysis, once the PDD is completed and approved, the client determines the success criteria and creates the UAT Plan in collaboration with the Business Analyst. The solution architect will also be consulted on the UAT Plan, to validate the feasibility of the requirements.

The UAT Plan is a document outlining the tests to be performed as well as the logistics for how end-user testing will occur after development, such as details on user availability, test data preparation, and cleanup. Clients are responsible for completing the UAT plan, but the business analyst may need to assist, depending on their level of experience.

Afterwards, during the Solution Design stage, Once a solution has been documented the solution architect and automation developers work together to prepare the Technical Testing plan, which should encompass UAT scenarios, functional testing, and system integration testing.

What resources to use?

Project Kickoff document
PDD template
UAT Plan template
Technical Testing Plan template

Access delays

What is it?

Development, testing, and production execution is dependent on having access to systems. Any ambiguity or missed application can halt those phases completely and impact expected timelines. It’s crucial to identify what access is needed early in the engagement so you can request it for the relevant team members.

At what stage should accesses be clearly defined and communicated?

In the Kickoff, Business Case and Technical Validation, and Solution Design stages.

How can we solve this challenge?

During the Kickoff stage, the issue tracker can be used for environment access issues, development roadblocks, UAT failures, or anything else that’s impacting the progress of the implementation. Anything that’s impacting progress must be discussed with the client during the weekly project update meeting (the Weekly Status Report template should be used here).

Next, during Business Case and Technical Validation, solution architects are responsible for identifying the key complexity, technical dependencies, and accesses needed for themselves, the developers, and the robots. This includes any application used in the process and access to Studio and Orchestrator for developers.

During the Solution Design stage, the Application Tracker is used to record accesses required by the developer to build the automation and for the automation to be run in UAT and Production. As a best practice, use the Application Tracker as early as the Kickoff stage to record access requirements.

What resources to use?

Weekly Status Report document
Application Access Tracker template
Technology Checklist template
Issue Tracker template

Customer availability

What is it?

The unavailability of the customer’s process Subject Matter Expert (SME) or process owner is a common challenge encountered in projects and is the cause for significant project delays.

At what stage should customer/users availability be clearly defined and communicated?

In the Kickoff, Process Analysis, UAT, and Business Case and Technical Validation stages.

How can we solve this challenge?

Early in the engagement, we should decide with the customer on the number of SMEs required per stage. Especially for UAT, we must set the expectation for how many SMEs are needed and estimate the number of hours required for each.

What resources to use?

Project Kickoff document
UAT Plan template

 Source: UiPath Academy