Why standard IT development methodologies don’t apply on the RPA battlefield


Even in 2018, service providers are still wondering about — and discovering — ways to be successful in implementing robotics. In any other instance of IT development, everybody follows standards built over the years: Agile, Scrum, Waterfall, DevOps, Lean and ITIL. But is it possible to easily transfer that type of knowledge into the robotics process automation (RPA) battlefield? My personal view is simple: No.  Moreover, it is not a priority to do so.  And it is not because those standards are bad or difficult to follow. It is that RPA is so unique and demanding. Think about it for a second: RPA was built to become an out-of-the-box panacea — a no-code, fast-paced phenomenon — where you are able to short-circuit many corporate elements and generate a new, exciting layer between two corporate functions – IT and operations.  To be precise, that layer is on the edge for each of them, involving virtual desktop interfaces, IT domains, applications, servers and interface augmentation (for IT) and process knowledge, metrics and standard operating procedures (for operations).

In any standard IT development you sign a non-disclosure agreement and your client lays out their expectations and allows you to scan existing databases or interfaces to their systems. After that you are basically on your own. Yes, depending on the particular methodology, you may also meet to validate your progress, yet the relationship fosters independence to a large extent. RPA is a different story.

Get ready to become your client’s best friend

As mentioned before, in RPA you are building an additional layer that glues COO and CIO domains. It is a unique arrangement, as you need to impact both functions to build sustainable results. Bear in mind also that we are talking about the client’s private, real-time process space – HR data, payroll data, confidential financial flows — where any change or unauthorized access has consequences or needs to stay limited.  Sounds serious and complex? It is just the beginning, so allow me to explain this piece by piece.

Any process assessments (or “process mining,” as it is currently hyped) – seen as analyses of business processes based on event logs — cannot be run without far-reaching collaboration with the client. You need to first agree on the particular fields or domains that should be analyzed (for instance an HR process). It is true that the client will likely share their preferences, yet due to their rather limited understanding of RPA, their proposal usually is not the best fit. Regardless, to be able to perform real process mining, you need to first get IT domain leaders to agree to give you access to their systems. Simple to write; very hard to actually do. Granting RPA-tailored access to process data in all systems in a particular domain is typically extremely limited and closely monitored even for a company’s internal use, not to mention giving those valuable keys to the kingdom to an external party. There are security constraints and data sensitivity issues concerning private data and things like sensitive money flows, salaries and bonuses, to name a few. In many cases you need to involve legal departments, security teams, operational directors and IT warehouse administrators. It can take a lot of time, and you still need to be prepared to receive many “not approved” messages along the way.

Assuming you obtain all the accesses and you manage to perform process mining, analyze the outcome, present the results to the client and get your ideas approved, can you then start working on your RPA development independently? Not really. The client needs to stay active at literally all of the subsequent stages, dedicating single points of contact (SPOCs) for the process and allocating their time for your needs. The client needs to constantly monitor your work to make sure it stays within the boundaries of the signed NDA. Remember, sometimes you are forced to use private cloud or even public cloud (Amazon S3). If your client decides there will be no development nor analysis outside of their firewall, you need to pack your bags and do everything onsite. It is not something that you will organize in a week.

Cooperative development methodology

So you did it. The process is analyzed. Accesses are granted. SPOCs are available.  Now the question is, what is the most suitable methodology for RPA development? The traditional answer is Agile. Yet the reality is Waterfall, at least for a project on a scale of less than 30 FTEs (automation equivalent to full-time employees). With a bigger project, I would still argue a bit for Waterfall, yet given the complexity of E2E automation’s ability to divide the work streams, you could probably do it in Agile. Just be fair with yourself and think, how many E2E projects of fewer than 30FTEs do you manage?

Moving forward with the overall RPA, you still need the client’s support. Without the client, are you able to . . .

  • Test the solution?
  • Test the whole infrastructure?
  • Perform all necessary management-of-change activities?
  • Train the client’s people and build support?

The answer to all of these questions is “no.”

In some initial stages it can be done, yet in my experience in this area, it is a no man’s land. People’s understanding of automation differs and their level of tech-savviness varies. So you need to prepare for the unexpected and always be ready to draft a new approach and customize the methodology. Only then will the solution reflect your clients’ needs and experience — and entice them to plan more scenarios for you to develop in the future.

No standardized implementation

I’m fully aware that everybody would like to hear there is a universal way to implement robotics or at least a rule of thumb to make it right every time. There are ideas and some patterns to map certain clients’ needs or requests. Unfortunately, other than that, you are on your own.  My personal take is that it is actually a good thing – you need to constantly adapt and keep a strong crew of people who are intelligent and skillful enough to make RPA more standardized and bring more value as a result of this standardization.

Piotr-Osipowicz-headshot-ironman_maskPiotr Osipowicz is a DXC Robotics and Automation Partner and a manager with more than 10 years of experience across several disciplines including Finance and Accounting, Lean, IT Support and PMO. An evangelist, strategist and digital transformation consultant, Peter focuses on empowering business decision-makers to integrate into their processes the new IT opportunities come from industrial revolution 4.


  1. Srinivas Turimella says:

    A really a great article on challenges with typical rpa deployment in multi dimensions. Thanks


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: