Two-Speed IT: Not As Sexy As It Sounds (Part 2)

In part 1 of this series, we explored a pair of competing requests many modern IT leaders receive from their stakeholders:

1. Produce new innovative, strategic technology-based capabilities.
2. Do so with reduced resources.

We investigated one buzzwordy solution—Two Speed IT—and how implementing this solution often creates more problems than it solves. We proposed an alternate five step framework for handling these requests. In steps 1 and 2 of this framework, we revealed how the above two competing requests are old problems, best solved with an old, proven solution—and not buzzwords.

In part two of this series, we will walk you through the remaining steps in our practical framework, and lead you down a path towards implementing this proven solution—the technology lifecycle.

Step 3: Think Technology Lifecycle, Not “Innovation” vs “Operations”

To better understand why the good-on-paper “Two-Speed IT” often produces problems when implemented in the real world, look at Gartner’s two speeds (or Modes) they shoehorn all technology systems and services into:

Mode 1: Development projects related to core system maintenance, stability or efficiency. These require highly specialized programmers and traditional, slow moving development cycles. There is little need for business involvement.

Mode 2: Development projects that help innovate or differentiate the business. These require a high degree of business involvement, fast turnaround, and frequent update. Mode 2 requires a rapid path (or IT ‘fast lane’) to transform business ideas into applications.

In these definitions, Gartner fails to consider one crucial point: No piece of technology is only a core operational system, or only an innovative differentiator. All pieces of technology start out as innovative differentiators and eventually become core operational systems. “Mode 1” and “Mode 2” don’t describe two fundamentally different types of technology—they describe two different points within a single lifecycle that all pieces of technology move through.

Thinking in terms of technology lifecycle—and not technology “speeds”—holds several advantages. Crucially, the technology lifecycle can incorporate every “Two-Speed” technology discussion you and your stakeholders want to have. But the technology lifecycle also:

• Keeps the IT group whole, allowing shared importance, contribution, and status for every member of the IT team.

• Offers the opportunity for a more mature, ongoing discussion of technology introduction and investment that will last and provide value beyond your organization’s modern technology transformations. The lifecycle adds flexibility and specificity to your technology definitions, and acknowledges each piece of technology’s unique needs at each point in its lifecycle.
• Allows you to embed your technology across the entire enterprise—instead of applying it only to the function that requested it—proliferating investments benefits are shared across multiple functions.

The best performing IT groups have always had a formalized technology lifecycle, and always used this lifecycle to frame stakeholder conversations about technology introduction and investment. But now, in the high-technology-integration era, stakeholder requests for, and visibility of, technology investments and infrastructure have increased. And the systems lifecycle can no longer be used only by the best IT groups. Every IT group needs to use one.

If your IT group doesn’t have a technology lifecycle, consider adopting this one:

Step 4: Make Your Technology Lifecycle Real in Your Organization

A formal technology lifecycle will create logical placement for technology at different points in its lifecycle, and define what that placement means for the system’s investment, resources, treatment, and benefit to the organization at each stage.

But it isn’t enough to just have this lifecycle. You must make it a real, lived part of how your IT organization operates, and engages with your stakeholders.

Here’s how:

1. Establish the vocabulary within your own team.
 Adopt a common vocabulary for each stage of the system’s maturity. The same name, the same set of resource and benefit expectations, for each stage. It’s imperative everyone sings from the same choir book in front of IT teams and business stakeholders.

2. Place each of your systems within your lifecycle.
 Evaluate and visually map each of your systems to the lifecycle. Attach your budgets—where and how much you are spending—to the different stages of the lifecycle. This will immediately show you which technologies you are over-funding relative to their maturity.
3. Spread your lifecycle through the entire organization.
Everyone needs to know what the lifecycle, and each stage of the lifecycle, means, and where each of your systems sits within the lifecycle at any given time. And, most important, what that means for investment and expectations in the system. 

4. Refresh technology placement once a year. 
Once a year, during your annual planning phase, work internally and with your stakeholders to review your systems and make appropriate changes. Be sure to communicate those changes within IT and the rest of the organization through an annual mini-marketing meeting so everyone in IT, and the business, understands where each current technology sits within the lifecycle (and what they can expect regarding funding that technology for the coming year).

In short: With your stakeholders, reach agreement on your technology lifecycle, what this lifecycle means for investment resources and dollars (not only amount, but also where those dollars shift from CAPEX to OPEX), and where each of your current technologies sit on the lifecycle, and you will have an effective framework for filtering your stakeholders’ competing demands.

Step 5: Use Your Lifecycle to Frame New Stakeholder Demands

With your technology lifecycle, you will provide a mature, agreed-upon framework for processing stakeholder requests.

• When your stakeholders ask you to innovate and invest in new technology development, the lifecycle will help you agree where that development will be most valuable.

• When your stakeholders ask you to “consumerize” and reduce resources, your lifecycle will identify which systems are due to provide increased efficiencies and reduced or eliminated investment.
  
• And—most important—you can use the lifecycle when your stakeholders feel upset that IT is spending too much money and they don’t know where that money is going, you can use the lifecycle to manage their expectations about when they will start seeing benefit on their investment.

Today: Move From Awareness to Action

As much as we’ve taken the concept of “Two Speed IT” to task in this series, the concept has performed an important job: by putting our stakeholders’ competing demands front and center, it has shone a light on IT leader’s increasing need to adopt a formal solution to underlying tensions of their technology’s lifecycle.

Traditionally, only best-in-breed IT groups have put in place real structure and governance around balancing their new and innovative technology with their legacy systems. With digital and technology transformation increasing the speed and importance of technology within the business, this tight focus on technology lifecycles has become a requirement for all IT leaders who wish to stay relevant stewards of technology in their companies.

---

Interested in learning more about management frameworks that work in the real world?

Learn more about our proprietary frameworks by clicking here.