CIOs who are intent on delivering new waves of value to the enterprise often arrive at a common discovery – they realize they need to disrupt how the IT organization delivers support and services to the business in order to make it much easier for the company to consume those services and to deliver them more efficiently. 

This is one of the fundamental reasons why a growing number of CIOs are shifting to an Agile methodology to help make their IT teams more responsive to the business. In fact, 75% of executives polled for the 12th Annual State of Agile Report from VersionOne have adopted Agile to accelerate software delivery while 64% and 55% have done so to better manage changing priorities and to increase productivity, respectively. 

Vipul Nagrath, Global CIO at ADP, has taken Agile to a new level for the global provider of cloud-based human capital solutions. HMG Strategy recently caught up with Nagrath to learn more about ADP’s approach to Agile and the results it has generated.

HMG Strategy: Tell us about the genesis for the Agile program at ADP.

Vipul Nagrath: Our vision statement was to create an Agile organization that relentlessly automates processes and supports the growth of the organization. What we want to do is engineer great processes. 

In going about this, we needed to organize ourselves in a way to achieve the results that we want to gain. We had a specific savings target and timeframe we were chasing. We would achieve those savings in 18 months in run-rate savings. In Year One you don’t get all of the savings but the run rate was fully achieved. That was our North Star. 

Then we got into the ‘how’ of it – you have to look at your processes and you see things that take 100 days to complete and how can we dramatically reduce that from 100 days to 1 day? Can we take a week’s worth of work down to 8 hours or even four hours?

How did you go about this?

VN: We organized ourselves into a concept called ‘Chapters’ where we grouped our teams by like-skillsets, such as our chapter of database engineers. We created 26 chapters and each chapter has a charter. We also made sure we had the right metrics applied to each chapter. 

The reason for the chapters was to have global consistency in the approaches taken - whether it be SQL or another technical domain - regardless of the technology involved. We’ve used the metrics which we’re measuring to determine how well the chapter is going.

Then we developed ‘recipes’ which get at the heart of the work we do on a day-to-day basis. A team of people – typically 10-to-12 – are focused on an outcome to deliver that solution. On one recipe team you’ll have one database engineer, one network engineer, one systems engineer and a few programmers. 

Once we assembled this, you take the skillsets in each of those chapters, put them together and built this capability and these recipes. 

Just as with cooking, a recipe is not successful unless you add chemistry to it. Each one of these recipes is organized with self-empowered teams to set up and achieve these and there’s autonomy provided to these teams. For instance, system administrators and database engineers might interact with each other but they haven’t historically worked together as a team. This recipe model forced them to work together as a team. Magic has happened. It’s the combination of the chapters and the recipes where we get consistency, speed and agility. 

What are some of the results you’ve achieved?

VN: We’ve realized tens of millions of dollars in cost savings in the first 18 months.

The efficacy we’ve seen is to reduce the headcount to get the work done. We’ve taken processes that from the time of the request to the time of execution that had taken 100 days are down to 11 minutes.

Can you point to an example?

VN: We dramatically improved the provisioning of servers, whether virtual or physical. We started with virtual servers and what once took a week’s worth of work has been cut to 11 minutes. 

We’ve streamlined many things, everything from the team doing a clean sheet exercise to seeing how many people it took to get this done in the past to determining how many are actually needed. Why do we need to go back to finance 4 times for approval instead of just one time?

Part of the cultural change was getting people to think about the Art of the Possible. Could this be done? Let’s test it and try it. 

How did you approach the executive team on selling this vision and gaining buy-in?

VN: As you know, engaging in a full-scale digital transformation is a major endeavor. From the evaluation and planning stages, through each development gate, I was presenting updates, garnering support and soliciting feedback from our C-suite and ultimately the Board. 

To clearly communicate our findings and plan of action, we did our homework and walked in with data. What percentage of the program was project management, how much was operations and what burden would engineering assume? Are there other ways to do it? Of course, there are many options and decision points, but we didn’t want the project to drag on. We showed them [the C-suite] the time and cost it takes to do certain activities and the impact of each tradeoff. We were introspective, but we solicited third-party reviews as well.

Have you assigned someone to oversee the goals and progress of each chapter?

VN: Yes. We have established `Chapter’ charters, which include each team’s clearly-articulated vision, scope, goals and metrics for success. Every chapter has a global chapter lead and three regional leads. It is their responsibility to govern over all members of their chapter, as well as the technology strategy and the agreed-upon standards of that chapter. Governance review meetings are scheduled quarterly and annually.

You mentioned some of cultural aspects associated with this initiative. Did you have to work through any issues in getting IT professionals from different disciplines (e.g. network engineering, SQL programmers) to work together on the recipes?

VN: Absolutely. It was one of the more challenging aspects of our transformation. Like with many large companies, employees were comfortable operating in their divisional silos. Outside of an all-hands-on-deck crisis situation, teams were not structured for collaborating cross-platform. Sysadmins, database engineers, network engineers, site reliability engineers and solutions engineers were even speaking different languages and not communicating effectively. 

Today, we use Python as a common language and we’re in the process of eliminating our silos altogether: teams are comprised of diverse members from various disciplines. This new approach has made all the difference, as we are all accountable for considering the full journey versus a compartmentalized section of it. 

Collectively looking at the desired outcome speeds up decision-making and action and helps us learn quickly what works and what doesn’t. And when everyone is aligned, we end up with a better, more holistic solution. As a result, I was pleased to see that feedback from associates has been very positive.

Did you have someone who served as a project manager or the equivalent of a COO who oversaw this initiative?

VN: Yes. Both. The GETS (Global Enterprise Technology & Solutions) Transformation lead was Mark Chamberlain (VP, Global Head of Infrastructure at ADP) and, as the executive sponsor, I enabled him with the project management and portfolio support he needed.

What were the top challenges you and the teams faced throughout this journey and how were those challenges overcome?

VN: Number one was the cultural shift – Introducing a whole new way of working, with new methodologies, processes and tools required employees to align skills and capabilities with products and solutions. We could tell them we were succeeding, but the key lesson was sharing success stories (which may include quickly failing forward) and encouraging those behaviors across our organization.

Number two was communications – I’ve long believed that it’s important to communicate consistently, and over-communicate change. At the heart of any major change initiative is a robust communications plan. By establishing two-way communications vehicles—including virtual and live town halls, podcasts, a CIO mailbox, and an intranet collaboration site—regular updates were provided to the individuals doing all the hard work, promoting and celebrating problem-solving and value creation.

The third challenge was around empowerment. Part of our new “way of working” calls for each recipe team to be empowered. That empowerment—not asking for permission, or if you have an impediment, ask sooner rather than later—enabled us to responded quickly to planned and unexpected demands. Now, individuals are operating like owners, with real responsibility.

Looking back on it, what have been the biggest lessons learned from this undertaking?

VN: I’m going to paraphrase the godmother of computer science, Grace Hopper: “The most dangerous phrase an IT manager can use is ‘We’ve always done it that way’”. You’re going to have naysayers who don’t agree with your approach. Many will come to see your perspective. Some won’t. I found it surprising that some of our progress happened much more quickly than anticipated. Trust that humans are resilient and will learn quickly…especially when they see the team winning with real results.

I talked about communications already, but it’s worth reiterating. No matter how often you communicate, some will still walk away with a different perspective and understanding. Additionally, we recognize that different people like to receive information in different ways. Many of us are part of a multi-generational workforce. It’s important that key messages are delivered it in multiple ways through various media. Don’t underestimate the amount of communications required to truly `reach’ each individual.

Also, you can have a gut feeling, but you must use your data to test it. Have a point of view, but proving out your thesis is key to long-term success.

Key Takeaways

  • Culture is the biggest challenge facing any extensive enterprise transformation effort. Be sure to engage with all stakeholders involved to understand their concerns and to clearly communicate goals and expectations.
  • Provide autonomy to individuals and teams to execute and achieve goals and to demonstrate your trust in their ability to get the job done.
  • Don’t underestimate the amount of communications required to truly `reach’ each individual.

Vipul Nagrath will be giving a keynote presentation at HMG Strategy’s 2019 CIO Summit of America in New York on March 27. To learn more about the agenda and to register for the event, click here.