One of the concepts that Gartner analysts have talked a lot about at this year's Gartner Symposium/IT Expo is that IT can no longer afford to move at the slow pace that it does. They’re talking about how other parts of the business are choosing to circumvent IT with projects of their own that can often be fully implemented in the same time it takes IT to gather requirements.
There’s no doubt IT is under a lot of pressure, but there’s also a reason for doing some of what they do in the methodical pace they often choose. Those “rogue” projects carry risks and some critical projects require taking the time to get them right. Gartner suggests that CIOs divide their departments into business-critical projects that need to be done slow and methodically using traditional IT methods and projects that can handle “just good enough” practices where some rules get broken to allow quicker response times.
Dividing your company IT strategy into the slow lane and the fast lane makes sure when you need to concentrate on uptime and security and other traditional IT issues, you’re still free to do it, but when you’ve got to break some rules you’ve got the flexibility to do so. But Gartner VP Dave Aron says that only 19 percent of larger enterprises have the right staff on hand to start producing fast track, agile projects. The rest have been stuck so long that they don’t have the right skills, mindset, and management to do it.
Because of that, Aron believes more enterprises are going to turn to smaller, more agile vendors to give them abilities they don’t currently have. I think this might be one way to look at it, but I also think leadership can fix that problem as well.
Of course, exactly what two-speed IT looks like to you depends on your department and needs. But I saw two excellent and different examples of it from two CIOs while at Gartner. I don’t know if either was consciously practicing the Gartner concept, but both are clearly, intrinsically aware of the problem.
The first I’d like to talk about was Alexander Pasik, CIO of the IEEE. Three years ago, when Pasik was hired as CIO at IEEE, he wanted to instill an innovative culture. Based on the idea of Google's “20 percent model,” where people used 20 percent of their time on side projects, he sent his people to the task of innovating and tried to free their time to do so. But the project didn’t work. No real innovation came. So in the second year, he hired a consultant. And everyone was gung-ho until the consultant left. No real innovation again.
But Pasik decided to do something radical. He picked an especially bright member of his staff and told them that they now had no job responsibilities. They didn’t report to anyone except Pasik himself. This person had no rules and only one responsibility -- he was supposed to innovate.
Free from the constraints of the system, the “innovator” (basically a one-man fast track) came back with an idea. And within three months that idea was an entirely new line of business for IEEE, and it is also the first patent ever filed by the trade organization. Since then, projects two and three from the same innovator, also new lines of business, have been implanted. The first went from concept to live in less than 90 days and each future project is following the same path.
Space doesn’t allow me to go into the details of the project here, but trust me when I say it is a project that using traditional IT principles often would have taken years.
Similarly, CIO Gary Hoberman from MetLife was asked to work on a new project for the company that would bring a lot of disparate information from multiple sources into the hands of the business in a better way. The project was massive. Essentially, it was a redesign of how insurance and health records would be aggregated and visualized moving forward both for customers and internally.
Hoberman saw it as an opportunity to show IT’s value, and instead of allowing the business to dictate timing or asking for more time, he made an audacious move. He told them he’d have it in production in 30 days. The goal was to have IT dictating the timing to the business and not the business looking at IT as a hold-up.
Hoberman went to his team leaders and told him what they had done and told them to drop everything to keep the promise he made to the business. He told them to take the best people off whatever they were doing (the fast lane) and backfill the rest (the slow lane) with consultants. The project was completed on time (and the demo looked beautiful).
When Hoberman asked his team leaders how many consultants they needed to hire and how expensive it was, he was pleasantly surprised to find out that they had hired no consultants. The developers were so excited about being given something clearly business-critical to do with a fast deadline they were so engaged they got it done.
Whether either of these CIOs actively had a “slow lane” and a “fast lane” approach isn’t as important as they realized IT needed to find another gear. They needed to free up resources from the constraints of best-practices and metrics and risk assessment and requirement gathering in order to get something done fast and right. And it worked splendidly in both cases. What do you think? Does this excite you or scare you? Do you think it was really about fast lanes and slow lanes, or just good IT that made this happen? Are you ready to lead in the fast lane? Comment below.