Sometimes, Simple and Inexpensive Can Beat Complex and Pricey

By Mark Rutledge, CIO, Commonwealth of Kentucky

When my son first got his driver's license, he immediately (and not surprisingly) wanted a car so he could drive to school. I was happy to be relieved of chauffeur duties, so he was halfway to his goal. They only remaining question was what kind of car would he get? Like any 16-year-old, he would have been happy with a Ferrari that could hit 100 miles per hour without trying. But given his goal—getting to and from school—a used Ford Ranger pickup truck worked just fine.

I tell this story frequently in my work as a chief information officer, for a simple reason. It's easy to think you want the coolest thing technology has to offer, but it's more important to know what you're trying to accomplish. In IT, we sometimes become so enamored with the Ferrari that we oversell its promise. We end up just disappointing the business side, who may have been dazzled by its speed but really only needed a station wagon to get stuff from here to there.

The sad thing is that we CIOs put ourselves in this predicament. Chief executives might say they have trust in their CIOs, but I suspect that what they really have is hope. We'll develop trust by going back to basics: say what we're going to do and then do it. We have to base our conversations about technology on what we know exists, not what we think is coming. That's how you change hope into trust.

I realized this when I started to look at how we purchased technology. As a state department, we have to adhere to regulations regarding procurement. When we had a technology project, we would put all of the requirements into a request for proposal (RFP). But it's hard to put all of a specific project's requirements into an RFP checklist. Everything comes out the same: Are you certified? Are you compliant? Do you integrate? All the vendors would adhere to the high-level requirements, and the only thing that separated them was the fee. But IT requirements are not commodities like No. 2 pencils, where price is the only differentiator of one supplier from another.

The problem was we were focused on the vehicle, not on what we needed the vehicle to do. To comply with the state's regulations, we set up a system to pre-approve a number of external IT consultants—potential partners with specific expertise—whom we knew would comply with our enterprise architecture standards and the Commonwealth's procurement terms and conditions.

Then, when departments came to us with technology requests, we would sit down with the stakeholders to compile a business problem narrative—not what technology they needed, but what problem they were trying to solve. That helped us in IT to have an open dialogue, asking questions and considering needs. When the narrative was done, we'd submit it to our pre-approved consultants and have the same conversation about what we wanted to achieve.

Whoever delivered the best value won the contract. It didn't have to be the lowest bid, but it did have to solve the problem. We are trying to help our IT vendors shift from being product suppliers to being strategic partners. They appreciate the new process because with checklists, the playing field was leveled and there was no way to validate vendor claims for meeting certain requirements until after contracts were awarded. We also took away their strategic advantage, which may have been something that was a key value for us. Up and down the chain, our new strategy allows interaction, dialogue, and a collaborative approach that benefits all parties.

The users benefit as well, especially in terms of the time it takes for contracts to be fulfilled. Because our vendors are pre-approved, we can shave two to three months off the timeline of a project. That makes everyone more productive.

When we adopted this new way of thinking, it helped us focus on the problem to be solved rather than on the technology. Best of all, it helped IT become part of the solution rather than part of the problem.