The fundamentals of setting up and measuring an automation program

The governance framework for implementing an enterprise-level automation program needs to be comprehensive, flexible, and robust – with clear visibility on targets and progress on achieving them.

There’s a story about a hiker in the countryside who saw a farmer leaning on a gate. “Excuse me,” said the hiker, “how long will it take me to walk to the next village?”

The farmer didn’t answer, not even when the question was repeated, so the hiker shrugged and set off.

The farmer called after her, “About twenty minutes.”

The hiker came back. “Why didn’t you say so before?” she asked.

“Because I didn’t know how fast you’d be walking,” said the farmer.

There’s an essential truth in this: unless you establish some basic metrics, you can’t gauge how well you’re doing. This is especially true in any enterprise-level automation program – when there are many interconnected processes, developments in each of which may have a bearing on others, it’s vital to lay down some ground rules and to measure progress against them.

There’s more than one way to tackle this, but in this short article I’m going to highlight just one of them.

Creating a lean IT governance model

The foundation of any approach is the governance model. In this case, we’re going to use the Agile software development lifecycle.

Lean IT governance is about creating the leadership, organizational structures, and streamlined processes to enable IT to make a real contribution in sustaining and extending the organization’s ability to produce meaningful value for its internal customers. The model specifies the controls needed to ensure a reliable, repeatable, transparent, and secure software development process while maintaining the momentum of software delivery through standardization, continuous process improvement, and the elimination of process waste.

It’s not just about processes, though. It’s also critical to define the “who” in the governance model and constantly keep all parties informed of any changes in this area. Measuring success isn’t only about key performance indicators, whether that be for project leaders within the organization or for any service delivery partners: it also requires a relationship with the people responsible for delivery. Everyone needs to agree on how these metrics are interpreted.

Weekly status meetings deliver metrics to the tactical leaders of the project. It is critical for the mid-level managers to know what the trend is so they can make adjustments before a trend starts to affect deliverables.

Monthly status meetings deliver metrics to the strategic leaders of the project. This is to ensure that the upper-level managers understand the key performance indicator trends so they can make decisions on capacity, personnel redeployment, budget, problem management, and more. They also need time to craft the messaging to senior leadership.

Quarterly business reviews (QBRs) are all about value realization. The senior leadership team needs data-driven assurance that the investment they made in the automation program is delivering the return they expected. The focus of the QBR is not on the details: it is a high-level metrics discussion about delivered value. The aim is to empower the automation development team to carry out its work as efficiently as possible, while ensuring the stability and security of the development through monitoring and mitigating risks in an open and collaborative manner.

Delivering usable, automated business processes

When an organization needs to embark on a digital operations transformation of its critical business processes, the lean IT governance model is a control that ensures automation development is agile, secure, and elegant. Unlike standard IT development, the focus is the delivery of a usable automated business process to operations as quickly as possible.

To facilitate this prompt delivery, the primary function of IT governance is to prevent roadblocks to automation development, and if not to remove them as soon as they arise. The aim of the governance team should be to give developers a clear framework to work within, and then get out of the way.

The approach needs to be streamlined and lightweight. A heavy governance strategy will lead to heavy mitigation strategies by those being governed.

Communication must be clear, honest, and timely. Expectations should be set in an open, honest, consistent, and continuous manner.

It’s important to trust, but also to verify. The agile software development methodology is based on trust, but to ensure the right thing is happening within the development cycle there needs to be verification. To prevent roadblocks, automated metrics are better than status reports.

With a lean IT governance model, the aim should be continuous improvement. It’s a living document, and frequent changes are welcome and encouraged. If something in the model is creating a roadblock to progress, it’s the responsibility of the governance team to work in collaboration and challenge it.

Getting there

In short, what’s needed is a governance framework that is comprehensive but that doesn’t sacrifice attention to detail. It needs to be flexible, but also robust – and it must also be unambiguous, so that everyone can understand what the targets are, and what progress is being made towards achieving them.

Otherwise, no one will know how long it will take to reach the next village.

This article is published in the new edition of our Innovation Nation magazine. Read more from our special feature on “Automation and the data-powered organization” and download the full magazine.