By Lee Reese
In part one 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 one and two 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 toward 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” approach often produces problems when implemented in the real world, look at Gartner’s two speeds (or modes) in which they shoehorn all technology systems and services:
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 updates. 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. The categories “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—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 includes the following:
- 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 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—enabling investments’ benefits to be 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 will define what that placement means for the system’s investment, resources, treatment and benefit to the organization at each stage.
However, 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.