IW500: Six Steps Satisfy Need For Speed

Whether you're a government or a corporation, six simple steps will help to make sure that your project or initiative keeps moving forward.
Communicate Up. It's not enough to collect metrics. You have to communicate them broadly within the workgroup and with upper management. So many managers only want to convey good news to upper management, out of fear. That's totally dysfunctional. Good leaders communicate bad metrics, because they are a call to action, and, hmmm, don't you think you'll need upper management support to resource or otherwise support that action? Rob Carter, FedEX CIO, called this "showing the ugly picture" when he spoke earlier at the conference. It's a key way to enlist buy-in for needed action.

But it's not just about the success metrics. It's about operating volumes and communicating the plan. The "top 10 projects" game plan going forward. One of the biggest complaints I hear from corporate IT and government IT alike is that "everything's a #1 priority." Well, it isn't. As an IT leader, you often work with divisions or agencies to "force rank" projects. If you try to do everything, you will accomplish ... nothing.

Communicating what the pecking order is to upper management not only gives them a chance to respond and say, "wait, X is not a priority, but Y is," but also puts those projects top-of-mind so that, during the quarter, if you need an executive to remove a project roadblock so that you can get the show on the road, it's not the first time they've heard about the project.

Lighten Up. Oftentimes, one of the biggest impediments to agility that I see in IT organizations is perfectionism. IT folks tend to be optimizers, and want to get the best value for the money. Problem is, time is money, too, and that needs to be factored into the equation. In this case, perfect can be the enemy of the good. HP Chairman Ray Lane spoke to this earlier in the day as well, saying that "When I was at Oracle, I watched enterprise IT teams spend a whole year picking between SAP and Oracle. In the end, did it really matter?" No, probably not. IT organizations need to be willing to simplify and thus shorten the selection process if they want to become more agile. In government, this can be tricky. My advice, however, is to focus on operational requirements rather than technical requirements. That is, instead of saying that the camera system needs to be so-and-so megapixels, with a zoom factor of XYZ and infrared feature of such-and-such, simply state that an officer needs to be able to recognize facial features in low light condition. Then, focus on the demonstration and the site visits instead of relying on a 6" thick requirements document. I'm not saying that such documents aren't needed; they are. I'm simply saying a little lightening of the load can go a long way towards speeding up the boat.

Burn Your Boats. Historically, Greek and Viking soldiers, when attacking by sea, would burn their boats, as a symbol of total commitment to victory over the enemy. It was a symbol that failure was not an option. How does this relate to the need for speed? I've found, over the years, that sometimes when the CIO or CTO asks staff to start investigating disruptive or status-quo-busting technologies (PCs to mainframes, virtualization, cloud), staff nods sagely, says, "sure, we'll …. do that in the lab. Maybe use it on some non-critical project." And then you never hear from them again.

Meanwhile, time is passing and your organization is missing out on a key emerging technology, perhaps losing money or competitive advantage by doing so. My answer to this is, instead of relegating that key technology to "the lab," burn your boats. Make it so that failure or retreat isn't an option. Don't use the technology on something non-critical; use it on something critical, where heads will roll if it doesn't work. I'm not saying be stupid about it. Obviously, your staff isn't up to speed, so rely on professional services--but your staff will have a clear message that they will be supporting it down the line, so watch them scramble to get up to speed on it with much more urgency than if it was in the lab.

Jonathan Feldman is a contributing editor for InformationWeek and director of IT services for a rapidly growing city in North Carolina. Write to him at [email protected] or at @_jfeldman.

See the latest IT solutions at Interop New York. Learn to leverage business technology innovations--including cloud, virtualization, security, mobility, and data center advances--that cut costs, increase productivity, and drive business value. Save 25% on Flex and Conference Passes or get a Free Expo Pass with code CPFHNY25. It happens in New York City, Oct. 3-7, 2011. Register now.

Editor's Choice
Brian T. Horowitz, Contributing Reporter
Samuel Greengard, Contributing Reporter
Nathan Eddy, Freelance Writer
Brandon Taylor, Digital Editorial Program Manager
Jessica Davis, Senior Editor
Cynthia Harvey, Freelance Journalist, InformationWeek
Sara Peters, Editor-in-Chief, InformationWeek / Network Computing