The CIO automation handbook, part two

This article is part two of a five-part series about how the unique capabilities of the chief information officer (CIO) can contribute to a business' automation program. The first part discussed how automation can help realize the vision of the CIO as a transformational role, as opposed to merely managing the IT budget. Here in part two, we’ll discuss how the CIO can enhance the automation mindset within the business.

Tortoise vs. hare

Around 600 BC or so, the Greek fabulist Aesop popularized one of the most enduring stories in history. In this story, a tortoise challenges a hare to a race, to great ridicule. The tortoise eventually wins because the hare, in his hubris, takes a nap halfway through the race.

The mainstream message of this story is "slow and steady wins the race." In other words, you should be more like the tortoise. But the interpretation that probably occurs to most automation people (like me) is: "How can I be a hare who doesn't take naps?"

In large businesses, the CIO’s organization is the tortoise. It takes a particular mix of stoicism and focus to concentrate on the swirling chaos of business desires and requirements. Let alone reconcile them with what is technically possible. Then, we pile on the need to temper the absurd expectations of organizational fantasists, and slowly but steadily move the ball towards the goal one step at a time.

The business, on the other hand, is undoubtably a hare. It's fast, agile, and responsive, but incorrigibly distractable.

Tortoisifying the hare

One significant impact of the UiPath Business Automation Platform has been to enable the agility and speed of the hare, with the discipline of the tortoise. But applying that discipline doesn't come easy, and this is the first place where the unique position and skills of the CIO’s organization come into play.

I've seen a lot of automation programs attain degrees of success. We talk a great deal about qualities that distinguish great programs from less successful ones. There are a lot of factors: executive buy-in, pipeline strength, establishing a proper operating model, evangelizing the program... Much ink has been spilled on this subject.

To me, there's one quality that distinguishes great programs from weaker ones. And that quality is relentlessness.

And relentlessness forms the core of the CIO mindset.

Relentlessness in action

There is a myriad of ways that you can bring the relentless mindset in a way that improves a business’ automation program. The ways that apply to you depend on the strengths and weaknesses of your program. Some programs are strong in capturing business benefit, but weak in operational controls or monitoring. What follows are a few ideas to get you thinking about how you can apply this principle.

Focus

Automation programs can stall at any time or maturity level. They can also accelerate and grow exponentially at any maturity level. To leverage imagery from my previous blog post, the amount of gray in the backlog is omnipresent, and ever increasing.

To keep programs from stalling out, or to restart them when they do, there needs to be a constant focus on incremental progress. Save ‘big bang’ projects for IT transformation initiatives¹ (the green part of the backlog).

Hares are poor at remaining focused. This is a place for you (as the tortoise) to bring considerable value simply by instituting some lightweight organizational discipline. Examples include agile project management, defect tracking, or simply keeping track of development versus maintenance efforts.

Engineering discipline

One big silent killer of automation programs is a lack of what I call "engineering discipline." Engineering discipline is the set of skills and behaviors that infuse quality into solutions. These are things like test-driven development (TDD), end-to-end monitoring, modularization, and code reuse.

Automation solutions are particularly sensitive to failures in engineering discipline because some of the individual techniques that we need to employ can be brittle. Engineering discipline is a way to buttress our solutions.

Unfortunately, engineering discipline is a rare quality earned through experience. And it often withers under the pressures of project timelines and business priorities.

Providing the relentless drumbeat of engineering discipline and quality is another place where the CIO skillset is uniquely valuable in an automation program. Simple stage gates like design and code reviews and pre-production checklists handle this cleanly. But they need to be accompanied by an engineering discipline mindset. Otherwise, they become perfunctory and symbolic. And this is worse than useless because it gives the entire fragile construct a patina of stability.

Bringing in the engineering mindset is thankless work. At first, those whom you're helping will roll their eyes and chuff at the necessity of it all. It's important to keep your interventions as light as possible (but no lighter, of course). Eventually, you'll rescue them in a serious, obvious, and undeniable way. And this is how new engineers are finally forged.

There's one more thing to keep in mind as you begin pushing this rope. Done well, engineering discipline speeds up implementations, even though it adds steps to the process. One example of why that happens is towards the end of projects. During this phase of implementation, it's very common to encounter bugs that can only be found during integration testing. In monolithic projects, this can only be done by a single developer. And, that developer needs to run a transaction through the process end-to-end to reproduce the problem, which might take minutes for each iteration. And minutes more for each tweak to attempt to fix the issue.

In a project with high engineering discipline, we find the bug initially by running through the end-to-end process. But fixes will happen in modules that several engineers can test in parallel. Because we're using TDD, we add this scenario to the collection of automated tests as well. Moreover, we're alerted if there are regression issues, as opposed to needing to find them manually. It might have taken a small amount of additional time for developers to implement the original modules early in the project. But they save many times that investment when you near release, timelines are tight, and pressure is high. In this case, slow and steady really does win the race.

Benefits discipline

The unique proposition of robotic process automation (RPA), in part, is about giving the business the operational agility to create value and remove cost without resorting to rigorous IT solutions. The most important part of that proposition is the creation (and capture) of value.

Despite the importance of rigorously defining, measuring, and capturing the value of automation solutions, few programs do it well. There are myriad reasons for this, but in the programs I've seen, they have two main root causes:

1. The means: the automation program lacks the means to measure value conveniently. It's just not very easy to get a dashboard of the overall value of a particular automation. The solution to this is simple, if not easy. Provide a centralized, supported set of design patterns and code which makes it easier to build your automations with value instrumentation than without.

2. The discipline: the automation program lacks the governance to define and capture the value. Again, the solution to this is straightforward, if not easy to put into practice. On the process definition side, each opportunity should have a potential value tracked against it. And during this stage, the business should define how it will capture the value. Every process definition document (PDD) should explicitly state what the value of the automation will be, and how the business intends to capture it. As a simplistic example, consider an automation opportunity that's expected to yield $100,000 per year worth of cost savings to the business. One quarter after this solution goes into production, the business could lose $50,000 of budget per year. Everybody wins. More complex patterns exist, but that's a subject for a later article.

Businesses usually excel at measuring and capturing value. But automation programs often lack aspects of this crucial step. By providing basic tools and governance, the CIO organization can seriously magnify the value of an automation program. All it takes is relentlessness and knowledge.

¹In this context, "big bang" projects are complicated and take a long time. This says nothing about the value of those projects. It's quite common for relatively simple projects to have huge benefits. By all means, if you have an opportunity to build one of those with automation, do it!