Imagine yourself in this situation: Your company is in a hyper-competitive market and has identified a compelling new opportunity through leveraging big data and the Internet of Things. But capturing the opportunity requires that you as CIO lead the company in a business transformation initiative – a journey where many organizations typically falter along the way, delaying time to value. What can you do to avoid this outcome, or even failure? What are the winning moves?
I think the transformation that Amex made when it switched to agile software development and DevOps several years ago is a highly effective example that can inform your transformation strategy, no matter the focus of your transformation initiative. Neal Sample, CIO at that time, took three steps that were crucial to the transformation outcome.
When CIO Neal Sample joined Amex, software development at the conservative financial services giant was sluggish at best. They were too slow to market with new software and updates. In a company like Amex, where seconds matter when it comes to helping customers, the sluggish updates weren’t competitive. His mission was to transform the software development process from the slow, expensive, uncompetitive waterfall method to the much more productive and competitive agile process pioneered in Silicon Valley.
When I spoke with Neal about the business transformation, he said the goal was to make new software releases continuous and seamless. In fact, he said they wanted to get to a point where a release would be a non-event, and they wanted to get comfortable with doing a push in the middle of the day if a marketer wanted to change a promotional message.
It doesn’t matter whether you think of the three tactical steps the CIO took as “rules” or as “guidelines.” But don’t overlook the importance of these steps. In fact, the more strategic your transformation initiative is to the business, the more you’ll need to follow this path to achieve success.
1. Use breakthrough metrics
In any business transformation initiative, you’ll need to win the support of the business users/stakeholders. And the more radical the change that you drive, the more crucial it is that you overcome resistance so eliminate resistance causing a delay in the time to value.
Having previously led development organizations that successfully used agile processes, Neal understood the value of demonstrating progress. So he used what I call breakthrough metrics that tracked the progress and the eventual success.
What’s different about breakthrough metrics is that they define and monitor performance by the desired user experience instead of just by IT functions.
Change is always difficult. Neal explained to me that the metrics he put in place actually became a huge morale boost for the company, as they allowed everyone to clearly see the progress toward the end goal of delivering value to customers. They bolstered the faster-better-cheaper mantra with five specific measures that identified the approach. They baselined current performance and then made the bold claim that they would perform better on all five instead of just a few. As the metrics continually demonstrated progress on all five, it helped win the support of the business.
The five metrics were velocity, regression time, defect levels, release frequency and downtime. While these may seem like the usual functional IT metrics, let’s examine them closer to see how they are tied to the end goal of customer experience.
The velocity metric measured how much new functionality and new capabilities they shipped. This was important because the supposition was that after they hit their stride with agile, they could push more code and more functional capabilities than before without changing the size of the organization.
They measured regression testing in person days as well as clock time in how long it took. The goal was to reduce manual testing in the regression suite and convert those manual hours into productive development hours. They measured defects very closely to demonstrate quality improving.
The fourth metric, release frequency, demonstrated that they moved from the baseline of irregular quarterly releases to 40 releases in 2014. Of course that leads to agility and nimbleness in the business, the ability to respond to market needs and market changes very quickly. More frequent releases also enables pushing smaller releases and thus achieving less disruption.
The fifth metric, release time, measured downtime – how long the development platform was unstable or unavailable and the window for the releases. Remember, their goal was to be able to push releases in the middle of the day and have them be a non-event instead of hours of outage.
To create breakthrough metrics for your organization’s transformation journey, you first need to define the experience (or benefit) goal. Then determine how to accomplish that goal. What you’ll have at that point is the basis for a set of metrics that identify what your organization must do to progress to the desired business goal. Metrics that allow the organization to understand and configure against the goal.
For example, if you want to improve the speed of the employee onboarding process and establish breakthrough metrics that allow your organization to configure against that goal and track progress, you need to identify the technologies to put in place and think through the talent issues. You’ll also need to think through the policies and processes involved in employee onboarding. What are the consequences of changes to those technologies, talent, policies and processes? In determining the answer to this question, you’ll have the metrics that help guide the transformation.
2. Use consulting expertise
Demonstrating benefits as soon as possible always helps in a business transformation. If Amex had wanted to do a piecemeal transition, it may have taken about three years, according to Neal. But they wanted to quickly scale the rollout. They accomplished this objective by bringing in outside consulting resources to help with the program design and to train the trainers. He recalls that this tactic helped them quickly get to a critical mass in the organization to really get the process going.
3. Apply “Chernobyl” thinking
Sometimes, applications or portions of processes don’t fit with the planned transformation. This is especially true in moving to today’s new technologies such as cloud and automation. Your organization may balk at changing some components, especially if the cost of the change is more than the benefit the organization would receive.
Although AMEX was all-in with its agile transformation, it retained waterfall processes where it made sense in 10 percent of legacy apps not amenable to the change. Neal says they kept those “off to the side” and “chernobylized them, like encasing them in concrete and leaving them for 10,000 years.”
As I’ve blogged before about legacy technology and apps, you have to do what makes sense for the business, and we can expect that many companies will have a legacy environment for the indefinite future. But I’ve also blogged about how your organization can apply DevOps principles to your legacy environment and achieve a 50 percent improvement in productivity.
Did you notice that all three steps Neal took at Amex have something in common? They all aimed to overcome resistance to change – the Achilles heel CIOs encounter in any IT or business transformation initiative. In my prior blog, “Four knows about driving transformation,” you can read about the impressive results they achieved in this business transformation journey, as well as other tactics they employed to succeed in their goals.
This article is published as part of the IDG Contributor Network. Want to Join?