Chapter 4
Iterative Execution
It was midnight on Tuesday, October 1, 2013. This was D-day for the team leading the project on the federal web portal for the Affordable Care Act (ACA), HealthCare.gov, more popularly called the Obamacare exchange. As the website opened for business, watched by teams from the Centers for Medicare and Medicaid Services and their contractors, the initial reactions were somewhat positive. The traffic on the exchange was higher than expected, but that was good news for a White House that had worried about hitting enrollment numbers.
However, at the offices of CGI Federal, one of the main contractors that built the site, the mood was decidedly darker. IT technicians were realizing that the software running the exchange was starting to crumble as customers faced delays in creating accounts. Shortly after that, the website crashed. This was an inauspicious start to the HealthCare. gov launch for President Barack Obama, whose signature legislative accomplishment would eventually become successful, but was tarnished slightly by a substandard technology project.
The reality is that the Obamacare website issue was more a discipline failure than a technology failure. Unfortunately, it’s a simple tale of an IT project gone terribly wrong that’s all too common in organizations. Though the HealthCare.gov project was big and complex, there’s no reason why it could not have been developed iteratively, thus breaking up the risk of a big-bang start into many smaller deliveries. In IT software development, this technique is called agile software development, and although it was used in parts for the ACA portal development, the predominant mode of delivery was a big-bang technique known as “waterfall,” where long durations of design and development are followed by the big launch.
When it comes to digital transformation executions, however, the bigger they are the harder they fall. De-risking a digital transformation, whether Stage 1 or higher, by chunking the work into smaller iterative deliveries while constantly learning is a key tenet for avoiding big, embarrassing failures. Unsurprisingly, these principles are applicable beyond software development. Lean startup, the methodology drawing attention from large and small enterprises to shorten product development cycles and accelerate determining if a business model is viable, is based on the same principle. The goal is to use several small experiments based on hypothesis testing to validate learning before iteratively launching products.
De-risking a digital transformation, whether Stage 1 or higher, by chunking the work into smaller iterative deliveries and constant learning is a key tenet for avoiding big, embarrassing failures.
Amazon.com’s first website, which launched in July 1995, had none of the slick designs, intelligent algorithms, or indeed any of its current capabilities at all beyond perusing a catalog of books and placing an order. Their internal operations were equally basic, with employees manually procuring books, packing them up, and driving them to the post office. However, this afforded Amazon the opportunity to leverage what worked and discard what did not, inexorably moving toward its founder Jeff Bezos’s vision of one day becoming “an everything store.”
How to Apply Iterative Execution to Complex, Multi-Project Programs
The HealthCare.gov website hiccup provides excellent lessons on avoiding a big-bang failure using iterative execution beyond individual project levels. How do you apply this to complex, multi-project programs like an entire organization’s transformation?
The principle of breaking up a large risky effort into smaller iterative chunks still holds. You can think big without betting the farm on one idea.
Transforming an entire enterprise will take more than one project; it takes a portfolio of projects. In this situation the strategy of de-risking execution is as simple as creating a portfolio of projects that include some big bets and other sure bets so that the total portfolio is sufficient to deliver the overall targeted goal. This was the lesson that the Denver International Airport program learned very painfully thirty years ago.
Why the Futuristic Denver Airport Baggage System Project Failed
In 1989, the city of Denver started work to build a bold new state-of-the-art airport. It was meant to be the largest airport in the US and a major hub for airline transportation, doubling its capacity to process fifty million passengers annually. Aircraft turnaround time, which is the duration between when a plane lands to when it takes off again, was envisioned to be cut to thirty minutes. For contrast, regular airlines even today take forty to sixty minutes for short-haul flight turnaround and multiple hours for long-haul. Faster turnaround time means a bigger competitive advantage in the airport business.
To drive this level of efficiency, a new, highly automated baggage-handling system was envisioned. The idea was futuristic. At check-in the agent would attach a glue-backed label to the bag. A fully automated conveyor belt would then take over. All baggage movement between check-in, transfer, aircraft loading, and pick-up would be automatic. This was an excellent example of a technology-driven disruption that could lead to competitive advantage.
What it actually led to was a delay of sixteen months in opening the new airport and cost overruns worth $560 million.19 Even after that delay, instead of connecting three concourses, the system supported one concourse, and even then, only for outbound flights. And in that small execution, the baggage system still tore up and lost bags. In 2005, the only airline left on the system finally pulled the plug. And it gave the world another great example of an ambitious transformation gone horribly wrong. What the Denver airport envisioned was the future;20 what it got was a Godzilla of a system that happily chewed luggage and even at its best speed would not match human baggage-handler timings.
Executions of entirely new systems and capabilities must be based on a portfolio-effect assumption—that some parts of the high-risk portfolio will be successful and others will fail.
The lesson to be learned from Denver’s system is that when it comes to digital transformations, vision and hope are not strategies. Executions of breakthrough new systems and capabilities must be based on a portfolio-effect assumption—that some parts of the high-risk portfolio will be successful and others will fail. Higher risk, big-bet digital transformations need to be based on portfolio-sufficiency plans, not very different from what financial wealth planners do. The portfolio in total must be sufficient to deliver the outcome.
An Iterative Execution Approach to Digital Transformation
Iterative execution for large-scale digital transformation is designed to address issues such as those of the HealthCare.gov and Denver International Airport baggage system rollouts. It blends the principles of breaking up waterfall methods into smaller iterative pieces for each project and creating a portfolio of different projects of different levels of risk/return.
At P&G’s Next Generation Services, we applied this mash-up successfully. We applied fast two-week iterations to individual experiments (projects) and subprojects and created a portfolio mix to ensure sufficiency of the entire transformation program. This broke up the “one big bet” approach to digital transformation into smaller lower-risk projects by running a portfolio of initiatives.
Successful transformations blend smaller iterative execution for each project and a portfolio of different projects. Each project has a different level of risk/return.
Figure 7 depicts the approach that was used at NGS. The overall NGS business opportunity (#1 in the figure) was to deliver very specific cost savings, top-line improvement, and user-experience improvement. The disruptive idea (#2) was to create the NGS ecosystem and operate it as an industry disruption forum. The portfolio of experiments (projects) (#3) was a collection of very specific disruptive needs of P&G’s GBS that additionally had industry-wide replicability so the development partners we brought in could commercialize the products outside P&G. Every project followed an iterative execution using design thinking (#4) to generate the big idea and a series of iterative product deliveries called minimum viable products (MVPs) (#5), and each project was either killed (if it did not meet success criteria) or rolled out if it did (#6).
Figure 7 Combining iterative execution and a portfolio of projects
Here is a quick summary of the six steps:
Step 1: Identify the big business opportunity.
This is the big transformation goal-setting exercise for the overall program. This could be the massive transformative purpose (MTP), which is a highly aspirational tagline that has the ability to drive extreme motivation, as described in Salim Ismail’s book Exponential Organizations. For NGS, the MTP was “disrupt the shared services industry.” The goal was to deliver specific ongoing cost savings, top-line growth, and user-experience gains that were identified at the outset.
Step 2: Identify the transformation ideas.
This is the big idea creation that will be detailed in chapter 6 on digital leverage points. This happens as part of the business strategy. For NGS, this was to create an exponential organization that would be run as an industry ecosystem.
Step 3: Create a portfolio of projects.
Break up the big disruptive idea into a portfolio mix of many small iterative projects. In NGS, we used a strategy of 10-5-4-1, where for every ten experiments (projects) undertaken, we could kill five, and of the remaining ones, four might turn out to be 2X or 4X types of ideas, but the remaining one would be a 10X. This process allows many small-bet projects to fail in the pursuit of a few big home runs.
Step 4: Use iterative design processes to design each project.
At NGS, we used design thinking to come up with the big transformation project ideas. A design thinking approach is superior to process mapping approaches when used for 10X transformations. Design thinking helps focus only on the desired business outcome (e.g., a room to stay in, in the case of Airbnb) and does not presuppose historical processes (e.g., the ownership of hotels as an asset).
Step 5: Use iterative execution methodology such as lean startup or agile.
Iterative execution approaches force you to break the idea into customer-focused building blocks and then build and field-test minimum viable product (MVP) executions. This facilitates building on the MVP building blocks until you have built out the big idea fully. In the case of the Denver baggage system, the MVP could have been as simple as field-testing a small part of the vision first (e.g., electronic baggage tagging for one airline or one concourse).
Step 6: Roll out only the successful projects.
The advantage of the previous five steps in iterative execution is that it helps not just to pivot within a project but also to choose to use only the most successful projects among the portfolio.
This iterative execution approach has one other major benefit—it delivers speed, or “innovation velocity.” Because you successfully chunk the big transformation into many small executions, the time, money, and risk involved in each small execution is significantly smaller. The ideas are therefore able to move along much faster. Speed is a very big enabler of success in transformation. Traditional thinking suggests that “better,” “faster,” and “cheaper” are together a zero-sum game, i.e., if you increase some, you reduce the others. My experience on digital transformation is that if you push for speed, you get “better” and “faster” as side effects.
The Importance of Speed and Acceleration in Digital Transformations
Speed of execution matters in digital transformation not just because digital transformation is an urgent issue but because speed generates enthusiasm, momentum, and the right mindset.
I’d like to offer the analogy of an airplane takeoff for digital transformation takeoff. In the case of airplanes taxiing for takeoff, acceleration, which is the rate of change of speed, is directly related to the distance rolled on the runway. The slower the acceleration, the longer the distance needed before the aircraft achieves takeoff speed. If the aircraft never achieves the required acceleration, it cannot take off on the given runway. That’s not too dissimilar to digital transformations. Acceleration, or rather the lack of it, can become a challenge. The initial experiments take so long that both stakeholders and organizations never see momentum develop. The disruption never takes off.
This issue is compounded for Stage 4 and Stage 5 transformations aimed at surviving industrial revolutions. The rapid pace of change in technology means that each digital idea has a shorter-than-usual shelf life, which gives digital transformation much shorter runways to work with. Or in other words, digital transformations need higher acceleration rates during industrial revolutions.
Speed and iterative execution complement each other to dramatically reduce risk of failure of digital transformations.
I would recommend that organizations on the path to digital transformation adopt speed (or in particular “innovation velocity”) as a key metric. Speed and iterative execution complement each other to dramatically reduce risk of failure.
Speed (Innovation Velocity) as a Metric
Innovation velocity—the pace of invention—is a key metric in many forward-thinking organizations. Given the shorter runway for digital transformations, evaluating a large funnel of ideas, each executed at low cost and high speed, is the best bet for hitting a few successes. This focus on speed is an even bigger challenge in larger, more stable organizations that aren’t usually known for rapid or low-cost iterations. Successful tech companies like Amazon, Netflix, and Alphabet have built this expectation of fast iteration into their cultures. Start-ups, on the other hand, tend to work on one big idea but are excellent at low-cost and high-speed iterations. The motivation system in a start-up helps with agility. When the money runs out, the game is over, and you need to find a new job. This obviously doesn’t quite work the same way in larger organizations, given their cultures of job security and stability. The answer is to set up a model for processing ideas rapidly and iteratively that works equally well in large organizations. Money will never be the same constraint in larger organizations as in start-ups. The alternative is to make time the big constraint instead.
Why More Organizations Don’t Drive Speed (and What You Can Do about It)
Most leaders already know that speed is an important driver of success on digital transformation. I strongly believe that the reason most organizations are not able to drive transformation at speed is related to structural issues. There are two main reasons for this.
I call the first the “clock speed” issue. A “clock speed” of operation is the normal pace at which decisions and operational change happen at the organization. (I have borrowed the term from the computing industry, where clock speed is the operating speed of a computer.) Since digital transformation efforts require operating at higher speeds, they generate conflicts within the organization, but this can be overcome, as I’ll discuss later. The second issue is the “two worlds” situation, wherein the core organization’s normal operations conflict with the change driven by the transformation team who wants to change it. This could be in the form of policies, practices, or other conflicts related to changing the operations. Here are ways to address both issues.
An Approach to Address “Clock Speed” Issues
At the NGS team, we had set about creating a new model that would deliver high-speed, low-cost iterations in 2015. If time was to be made the design constraint, then our operating model would need to visibly measure and publicize innovation velocity. The operating model had the usual five stages involved in innovation—landscape assessment, design, hypothesis testing, field testing, and rollout. To bring the element of innovation velocity into it, each stage was assigned a time goal. NGS came up with a convenient exponential series in months that would be associated with each respective stage—1-2-4-8-16. The exponential series related to the maximum time available for each of the five stages of innovation. So, landscape assessment would be one month long, design stage would take two months, and so on.
To be fully transparent, this was a totally contrived and simplistic series of deadlines at first. However, as NGS gained more experience, these targets were fine-tuned for each project. So, for example, highly disruptive experiments (projects) could be assigned longer timing goals for field-testing and rollout than lesser transformational ones. Over time, the actual speed goals became less important than the sense of motivation that they created. Each project status was prominently displayed on an eighteen- by six-foot dashboard in real time, with a ticking clock showing results accomplished vs. time passed for the stage. The transparency via this dashboard of metrics generated more pride and self-motivation than any other reward system based on project outcomes alone.
Addressing “Two Worlds” Issues
The two-worlds issue occurs because most organizations become inherently slow due to checks and balances introduced over the years to manage risks. There are legal- and procurement-related boxes to be checked, IT policy and technology standards to be met, HR and labor relations compliance issues to be addressed, global work-process organizations to be aligned—the list goes on. To be clear, each of these steps has a purpose and value. The question is whether the full brunt of all these processes is necessary during the nascent stages of an idea or whether they can be applied iteratively and with increasing intensity over time as the transformation matures.
At NGS, we developed the idea of an innovation “firewall” to protect transformative ideas in the early stages of development. This wasn’t a technical or physical firewall but a process firewall designed to shield disruptive innovation work from the normal brunt of corporate processes (except for mandatory ethics, security, and legal ones). Examples included the following:
While normal vendor qualification might take weeks or months, any NGS vendor that met certain narrow criteria could be qualified within a day or two.
Information security and risk qualification within certain boundaries (e.g., not involving proprietary or personal data) could be done in days vs. months.
New technology architectures beyond those that were normally mandated standards could be used by NGS under specific conditions.
HR processes were tailored for a high-agility environment (e.g., killing a nonperforming project was rewarded in NGS, whereas the overhead and personal risk of any project failure in the core organization would have been high).
Next, within the NGS team, we developed a set of reward systems that would encourage smart risk taking. A certain amount of intelligent failure for learning was allowed. I mentioned the 10-5-4-1 model earlier that allowed several project failures, some medium disruptions, and a few 10X disruptions. This was fine as long as the portfolio effect of all of them was still hugely transformational. Between the innovation firewall and the 10-5-4-1 risk system, the team felt comfortable to think big.
Chapter Summary
The initial HealthCare.gov website hiccup provides an important lesson on breaking up large “waterfall” projects into smaller iterative executions.
When dealing with large transformations that include several high-risk projects, it is important to have a project portfolio mix that combines some high-risk ventures with other lower-risk ventures to ensure that the total mix delivers sufficient transformation.
NGS created a six-step iterative execution approach to de-risk the digital disruption strategy by breaking it up into a portfolio mix of many projects and then using iterative execution within individual projects.
Speed of transformation (innovation velocity) is a great complementary part of iterative execution. Transformational projects executed at high speed and low(er) risk/cost have a better chance at success.
Most organizations recognize the need for speed of transformation. They are unable to act upon it for two reasons—“clock speed” and “two worlds” issues.
At NGS, the clock-speed issue was addressed by assigning each stage of the transformation project a limited time to complete.
The two-worlds issue was addressed by creating a “firewall” that insulated the early innovations from the full brunt of normal organizational processes.
Your Disciplines Checklist
Evaluate your digital transformation against the questions in figure 8 to follow a disciplined approach to each step in Digital Transformation 5.0.
Figure 8 Your disciplines checklist for iterative execution