Chapter 10 - Action Plan

10	Action Plan

When a craftsman repairs a timepiece he can still its wheels; but the living clockwork of the state has to be repaired while it continues to strike, the turning wheel has to be replaced while still in motion.

—Friedrich Schiller, On the Aesthetic Education of Man

Take time to deliberate, but when the time for action comes, stop thinking and go in.

—Napoleon Bonaparte

The preceding chapters have laid out what I believe is the best way to think about the role of enterprise IT in the context of digital transformation. Now we’ll address the digital transformation itself. We have at our disposal the new techniques and mental models of IT—DevOps, Lean startup, Agile. How can we use them to get better value from our technology?

Beginning with this chapter, you’ll notice that I am writing in imperatives, offering prescriptions rather than concepts. I’m doing so because of the urgency of getting started, and the difficulty in getting traction I’ve seen many enterprises face. Let’s go—it’s time to seize the initiative. Napoleon’s army is poised . . . wait a minute, forget that. It didn’t work out for him.

The Agile approach, remember, is both lean and incremental. It’s about moving quickly to avoid overplanning while constantly learning and adapting. It’s about immediately and frequently delivering chunks of success, provoking and observing, experimenting and then either pivoting or persevering. The best way to succeed at digital transformation is to start right now, with a sense of urgency. Minimize risk by working in small increments, yet keep moving toward the vision. Learn through action where the impediments lie, then focus on removing them.

Starting immediately doesn’t mean starting to plan immediately—it means starting to do immediately. Immediately means getting results within two weeks or so. They don’t need to be big results, but they need to be actual results. An example of something that is not a result is holding a meeting. There won’t be time for many meetings anyway. Other examples of things that aren’t results (quoting directly from self-assessments by some of my former employees) are “worked with stakeholders,” “drafted a plan,” and “discussed options.”

Instead, think big and execute small. Have a very clear vision that sets a direction, communicate it, then find the smallest thing that will move the enterprise in that direction. Instead of mitigating risk by planning, mitigate risk by taking small steps that produce results, then adjusting as necessary. Provoke, observe, repeat.

Just because someone is afraid of what is new doesn’t mean that what is new is risky. As I said in Chapter 6: Risk and Opportunity, the status quo bias leads us to perceive risk lurking in that which is new. But it’s riskier today to stick with the old ways of doing things—waterfalls, commanding from a remote redoubt, erecting barriers in the way of innovation. The digital way of working is now standard in countless enterprises across all industries. It is effective. It is not just a superpower of cutting-edge technology companies, but is also the way of large, old, sometimes stodgy (previously stodgy, that is) enterprises in retail, financial services, manufacturing, healthcare, media, government, nonprofit, and any other industry where companies use computers.

There are four objectives of the early transformation stages. Proceed toward these four in small steps, but proceed relentlessly. Your objectives are:

An IT initiative should not be organized around a fixed set of requirements, but rather an intended outcome. Requirements should be used only to the extent that they’re useful, and should be ignored if the team executing the initiative finds better ways to achieve the outcome. “Better” ways, in this context, means ways that accomplish the outcome more successfully or more simply. Minimize the amount of work done to accomplish the goal—the watchwords are lean, simple, fast, inexpensive.

To put this into action, you can charter a small team with an objective. The team should be self-contained. It should have all of the skills it needs to accomplish its objective and should have all the requisite tools and authorities. All management layers above it should be dedicated to removing impediments as they arise.

I’m starting with this objective because I think every organization can put it into action immediately. Don’t try to reorganize your entire enterprise into objective-oriented teams; create one or two and focus on making them successful. There is something in every enterprise that is waiting to be done. Start there.

An objective is a business result. It’s not something like “write x piece of software.” It may be what answers the question, “Why do we think we need x piece of software?” It may or may not be quantitative, but it must be well-defined and there must be a way to see how well it is being accomplished. A full business case isn’t necessary. Instead, cascade the objective down from a high-level strategic objective. You’ll control the initiative by frequently reviewing its progress and assessing whether it’s worth continuing to invest in. Clear time on your calendar.

The team charged with the objective should not know exactly how to accomplish it. If they do, then have them read the earlier Side Glance: Humility and Hubris. They’re on a journey of discovery together to generate hypotheses and test them, then implement the ideas that actually work. Together they’re responsible for the results. The team may include employees from IT and a business unit, perhaps from marketing or finance. The team should value good contributions no matter which team member they originate with. Good business ideas might come from the technologists and good technical ideas might come from a non-technologist.

Impact mapping, which I described in Chapter 7, is an excellent tool for the team to use. The technique works backward from the objective to formulate hypotheses about what might accomplish it. The team’s work will also be made easier if IT provides tools to work with, such as DevOps automation and cloud infrastructure.

Eventually you want to orient much of IT around objectives rather than requirements that have been tossed over the wall from the business. But getting started requires only a single objective and a single team.

Focus on the one important metric: lead time. Don’t get bogged down in the complexities of measuring it. Just take parts of the process—of introducing a change or innovation such as a new IT capability—map them out, and begin questioning every step.

Lead time is the time from when the organization conceives of an objective to the time that it is met. But it’s useful to start with a subset, such as the lead time from when a specific task or action item is conceived to when the corresponding capability is given to people to use. If we decide, say, that we’re going to deliver a web page to customers that will let them use a home camera to check on their bobbleheads when they’re out at the office, how long will it be until the bobblecam page is available?

Each step in the process of going from bobblecam requirement to bobblecam rollout should be identified, questioned, removed if possible, and otherwise shortened. Many of the steps won’t involve technology at all.

Perhaps the requirement has to find its way into a larger project. Does the governance process for funding the bobblecam take two months? Why? Does a meeting have to be convened that includes people whose schedules are hard to coordinate? Can it be done instead by a different group of people? A smaller group? Can you set aside a regular weekly time for them to meet? If the investment is small enough, can you skip the governance process? Can you then make the bobblecam investment small enough? Or can you stage the investment so that the initial commitment is small enough? If it takes time to put together a team to would work on the project, perhaps you can have standing teams that are ready to take on new projects.

Within the IT part of the process, adopting DevOps and cloud practices will reduce the technical lead time. It may require some new skills on the part of the technologists, but I’d suggest they learn primarily by doing. It’s easy enough to set up a sandbox in the cloud where they can play with the required new tools. The most difficult skill to learn for engineers used to older practices, you’ll find, is how to write robust automated tests.

If the bobblecam would normally have to go through a security review, perhaps you can eliminate it by incorporating security controls as the product is being built. Particular attention should be paid to setting up automated controls that function as guardrails. These take a short time to set up and will thereafter speed up work as well as improve quality, security, and reliability.

For quick improvements to lead time, use the cloud rather than physical infrastructure. Be relentless in reducing the size of projects and make sure that only a small group of requirements is worked on at any given moment. Make sure that the technical people aren’t getting distracted, but are able to focus on the work at hand. Try delegating authorities and eliminating sign-offs; you’ll be surprised by how dependent lead time is on waiting for Important People to deal with papers sitting on their desks. And for any step that will have to be repeated, find a way to automate it.

With just that paragraph-worth of tactics, most organizations can realize a dramatic speedup in lead time.

Raise the bar. The only measure of progress in the digital land is finishing things that add business value. Nothing should be 47% complete or “on schedule.” In the software world there is an expression, “Always be shipping.” Products rarely need to be “shipped” any more—CDs and floppy disks have pretty much vanished as delivery vehicles—but the concept has remained. The goal of a software engineer is to keep finishing things. The goal of everyone else in the organization should also be to keep finishing things.

If a task cannot be finished quickly, it’s too big. Bite off something small, finish it, give it to users, get feedback, incorporate the feedback, move on. Reflect frequently to see what can be improved.

I hear enterprises transitioning to the digital world say things like, “We have a plan to move quickly on this project. We’ve designed a prototype that is scheduled to be delivered in six months and then a version 1.0 that will ship a year later.” I usually suggest that they go back to the whiteboard and figure out what small thing they can deliver to customers or internal users in two weeks, then move on from there.

I know their response will be, “That’s impossible.” Sometimes it is. But very rarely. In those few cases where it’s impossible, my next question is, “What needs to change so that it can become possible?”

There is a way to deliver small—many companies, of all sizes and lifecycle stages, are doing it across their various industries.

I’ve chosen this objective—finishing results quickly—as one of the four places to start because it forces everyone in the enterprise—IT and business—to work together creatively to make it possible. To succeed in the digital world is to move at much higher speed than anyone is used to or comfortable with.

A good way to bring people together in accomplishing this objective is to expose a lead time metric that depicts their progress. You can create a dashboard that measures it, then help people focus their enthusiasm on seeing results there. The metric won’t budge unless products ship.

This is the most difficult of the initial changes, but it’ll drive the remainder of the transformation. It’s the ultimate step in coming to grips with uncertainty. It’s also the embodiment of humility in the sense I mentioned in the Side Glance: Humility and Hubris. The enterprise must stop thinking of its ideas as requirements to be given to IT. Instead, it must treat its ideas as hypotheses about what will accomplish business goals. It’s very tempting to assume that these hypotheses are correct. But they must be tested and refined, or possibly abandoned. The testing should be done as inexpensively as possible.

The first step is to identify what these (often hidden) hypotheses are. This takes practice. A requirement that “the system shall display data from the x database” is probably a hypothesis that “if the user had data from the x database, they could make higher quality decisions about whether to extend credit,” where making better decisions is the objective at which they’re aiming.

Once the hypothesis is explicit, the next step is to define how the outcome will be measured. How do we know whether the quality of the decisions is improving? Once we decide this, we can set up a way to measure it.

The next question is, what is the smallest experiment that will let us know whether building this capability will accomplish the goal? This can be a trivial experiment. What if we put a link on the adjudicator’s screen that offers to provide the information from database x? We could see how many clicks it gets, then give the adjudicator a message reading “Coming soon” when they click it. Next, we might try getting some of the information we think is most important and see if it makes a measurable difference. We do all of this before we fully implement the feature.

With each experiment, the risk of investing in the feature goes down. But with each one we also open ourselves up to surprises. Perhaps data item n is more important than data item p, although we thought the opposite. That may change how we eventually display them. Perhaps data item q is obtained from a third party and we have to pay every time we obtain it. Maybe we can learn in which cases to request it and in which it won’t be useful.

Users always surprise us. Operational situations also surprise us—something that seemed valuable in the lab might be unusable under real-world operational circumstances. Or perhaps it turns out that a feature we thought was extremely valuable is actually only somewhat valuable. In that case, maybe we decide not to invest in it after all. For this reason, the team that is creating the IT capability should work directly with customers or internal users to determine what they’re trying to accomplish, test ideas on them, and discover what works best for them.

The notion that a requirement is an IT command has cost us a lot—in building unnecessary or imperfect features, in missing perhaps even more compelling opportunities, or in taking unnecessary risks. By testing hypotheses, we get a tighter fit between what is built and what is needed, while opening up possibilities for learning and innovation.

These four principles are both a large part of the ultimate vision and a good starting point. Starting along these four paths holds very little risk. They are all matters of degree. There is no reason we cannot begin working toward all four, pushing for results right away while accepting that they are techniques we’ll get better at.

What is a small thing you can do right now to reduce lead times? Do it! What is a small initiative you can govern through objectives rather than requirements? Launch it! What is an important assumption you’re making and how can you test it? Test it! Agile transformations should be conducted agile-ly.

With these four directions set and the changes in motion, it’s time to begin working on the other transformations I’ve laid out. Here they are.

The hallmark of the old approach to IT was the large project. Requirements were collected and assembled into a single initiative. To avoid later scope creep, an increasing number of them were packed into the initial scope. As each project became larger, administrative overhead, management overhead, and risk mitigation were added. Results were not delivered until the end of the project.

In Lean theory, large batch sizes (of requirements, in this case) result in longer lead times and greater variability. Essentially, the project requirements are being held “in inventory” and are also in danger of “becoming stale” while they’re waiting to be addressed. Instead, work in small initiatives that build on one another incrementally, thereby reducing risk, enhancing organizational agility, and speeding value delivery. In turn, break each initiative into small pieces and deliver each piece independently and quickly. Alternatively, lose the notion of projects entirely and build incremental capabilities in a steady flow.

In an environment of uncertainty, complexity, and rapid change—the digital world—agility has high business value. It’s the most powerful reducer of risk, since it determines whether unexpected events become hazards or opportunities. It gives the enterprise freedom to innovate and drive the market forward, or to respond to competitors’ actions. IT is one of the enterprise’s most important sources of agility. Software is easier to change than physical assets; hardware can be replaced by cloud infrastructure to gain agility and speed.

Because agility is valuable, always consider it when making decisions. Buy call options to give yourself flexibility in the future. Make sure that any contracts you sign are flexible. When building new IT capabilities, see that they’re built with agility in mind, both in design and in the effort devoted to making certain the code is clean. Invest in paying off technical debt to increase agility. Simply put, invest in agility because it’s valuable.

The cloud is a powerful source of agility. Operating your own datacenter draws away resources that could be otherwise employed. The cloud lets you provision infrastructure, change it, increase it, or decrease it—virtually instantaneously. It’s the foundation for fast technical delivery processes.

The digital world is about the continuous, unobstructed flow of innovation. Instead of shooting for rare, big innovations, created by special innovation teams or approved by an innovation Star Chamber, think of innovation as a process of constant idea generation and testing, and part of everyone’s day-to-day work.

When an idea shows promise, double down on it. Encourage employees to try out many small ideas, which will create a portfolio of small successes and possible big bets.

Security is everyone’s job. Sales and marketing owe it to their customers to keep their data private, and they have a stake in whether the company’s products are able to continue operating. The CFO owes it to the owners and other stakeholders to manage security risk. Every employee should consider security an essential part of their job, not something that is forced on them or is something that only IT takes care of.

Among its other requirements, Europe’s General Data Protection Regulation (GDPR)—to which any organization touching any personal data of any European citizen must adhere—requires that every organization practice “privacy by design.” This means the organization should plan how it will treat personal data to keep it private, and build privacy into everything it does. This is a great idea, and not just for companies doing business with European citizens.

Much of security is inexpensive or free, but funds are sometimes required. Be prepared to support these investments, understanding that they’re difficult to justify formally when they contend with investments in new features. Security is the foundation of what you do, not an optional add-on.

Data is an asset whose value is often underexploited. The old way of managing it has been far from agile—we placed it in a database that was structured based on how we thought it would be used. As a consequence, it might not have been available for ad hoc or new and innovative analyses, nor available to the right people at the right time with the right tools. Data were held in different silos in the enterprise, or perhaps not integrated when a new company was acquired.

Supported by the cloud, a contemporary technique is to create a data lake that has data drawn from across the company’s databases, including those of newly acquired subsidiaries. A variety of tools, including visualization software and ad hoc querying functions, can be used to analyze and report on the data contained within the data lake, even if it’s a hodgepodge of different formats and provenances. Machine learning techniques are also now widely available in the cloud and provide new ways to analyze the data.

In the digital world, you want to automate as many controls as possible. The goal is to replace gatekeeping with constant assurance—in other words, instead of having periodic reviews or reviews just before an IT system is deployed to users, use automated controls to continuously enforce compliance. That way, problems are discovered and fixed immediately, and lead time is shortened because you can eliminate the review and remediation steps at the end of a delivery process. Teams can move very quickly once you’ve made sure automated guardrails are in place.

Use automated controls to enforce security policies and to manage compliance with PCI, HIPAA, and other compliance frameworks. Make sure the controls are not only applied unfailingly, but that there is an audit trail to show that they were applied. Use automation to enforce financial controls as well. For example, in the cloud you can:

One way to get more leverage from scarce IT resources is to set up self-service models that make it possible for employees to get what they need without help from IT. For example, many organizations now have an automated password reset screen, since forgotten passwords can take up more of the helpdesk’s time than anything else.

You can go well beyond password resets, though, for the principle is widely applicable and powerful. To draw another example from the IT world, software developers have often had to wait for system administrators to set up infrastructure for them. But today it’s common for the infrastructure operators to set up a platform for the developers to help themselves. Another area where self-service can be powerful is with data and analytics—some organizations have made it possible for data scientists to self-provision the tools and data they need to do each analysis. Self-service models are empowering and can free your colleagues to be more innovative and agile.

Off-the-shelf software can appear to offer best-in-class capabilities at a reasonable price, with none of the risks of custom-developed software. Sometimes it does—typically for accounting systems, generally for ERP systems, and frequently for tools such as analytics systems and office utilities. These are all areas where there is substantial common ground across businesses, where features don’t generally need to change based on company tactics or operational strategies, and where well-supported products exist in the marketplace. By all means, use COTS products for these types of applications.

But for other needs, be skeptical of the conventional wisdom that buying off the shelf is better than building. COTS software takes effort to configure, to customize, and to integrate with other enterprise systems. It reduces your flexibility when you need to make changes. It locks you in to a particular vendor—its contract terms, its product roadmap. At a time when good IT practice suggests that you should be working with users to design software around their needs, COTS software instead forces users to adapt to its designs.

Despite that conventional wisdom, you should be creating IT systems in house whenever possible. Use open-source frameworks and building block services available in the cloud to reduce the amount of building necessary and to be able to move more quickly. But tailor the software to your needs. Buying off the shelf is not the right solution in times of uncertainty and fast change—times when you need agility.

Along the same lines, outsourcing particular IT functions (e.g., testing, development) is not generally effective, especially when you’re trying to build long-term agility into your organization.

Discuss with your accounting experts how to best deal with capitalizing and expensing costs as you move into the digital world. The questions are both complex and case-specific.

Empower IT to take ownership of business outcomes, rather than just its product output. IT should be accountable for the results of the IT portfolio, not only for delivering according to requirements documents. IT should contribute to business strategy and be the enterprise’s guide to the digital world.

Businesses have tended to undervalue generalist skills. This was a consequence of organizing the company into functional, specialist silos. But as you move toward cross-functional teams to support digital initiatives, specialized generalists—that is, T-shaped people—become increasingly important, as they multiply the power of their teams. Such employees are good at many things, but are especially deep in a given area. And as we erase the boundary between IT and the rest of the enterprise, you should be hiring people whose skills cross those boundaries as well.

The surest way to fail at a digital transformation is to let it languish while you try to make risk vanish by planning. A hesitant, slow approach to transformation sends mixed messages when you’re trying to encourage your organization to move to a fast-paced, continuously innovative way of doing things. As John Kotter says in A Sense of Urgency:

“What is the single biggest error people make when they try to change?” After reflection, I decided the answer was that they did not create a high enough sense of urgency among enough people to set the stage for making a challenging leap into some new direction.1

Employees will be nervous in the face of transformational change. You can help overcome that nervousness with a steady hand, a clear vision, and a commitment to the urgency of transformation.