News Stay informed about the latest enterprise technology news and product updates.

CIO advice: It's OK to fail

Many CIOs don't take risks because they're afraid of failure. Failure is good, says one CIO. Without failure, you can't innovate.

DALLAS -- Every year, Hollywood studios release movies that bomb at the box office. Record companies press albums...

no one wants to play. The auto industry introduces cars that tank -- remember the Ford Edsel?

Businesses in every vertical industry take risks when they innovate. When they try something new, they know there's a chance for failure. But in information technology, CIOs rarely feel they have the breathing room to fail.

"Success in IT is creating value," said Tom Halbouty, vice president and CIO of Pioneer Natural Resources, an Irving, Texas-based oil and gas exploration and production company, who spoke at this week's Society for Information Management SIMposium.

CIOs often have to take risks in order to create that value. Whether it's trying to innovate how the company does business or trying to drive new cost savings, projects always run the risk of failure.

CIOs need to push back when their companies expect a 100% success rate, Halbouty said.

More on innovation
CIOs are catalyst for business innovation, say CEOs

CIO Alert: Watch out for stressed users

When a project fails, put the failure within a context that a company understands. At Pioneer an IT project failure can be compared to the number of wells drilled that came up dry: Plenty.

"If your success rate is higher than the business's success rate, your success rate is good," he said. And if that is the case, you're able to train your people to innovate rather than play back-office roles.

"Companies that appreciate innovation usually are creating value through innovation," Halbouty said. "If you're a commodity company, instead of creating value through innovation you're creating value through cost reduction."

This doesn't apply to every project, Halbouty warned. "If I'm implementing a canned payroll system that's been done a thousand times before, as part of my business case I should expect a very high success rate. I should not accept failure."

He said if he tries to create a system that creates animated visualizations of underwater drilling projects and puts them out on the Web for his worldwide users to use, he has to expect some risk.

"No one has done it before, and I'm not sure I'm going to pull it off," he said. "What I'm really trying to say is if what you're trying to do is highly innovative and really differentiating and has never been done before, then you should expect some uncertainty around the outcome."

John F. Cole, CIO of Kansas City, Mo.-based Midwest Consulting Group Inc., agreed with Halbouty's notion that CIOs must be prepared for the occasional failure.

"Make sure you manage the expectations off your business partners," Cole said, alluding to Halbouty's comparison to digging the occasional dry oil or gas well. 'Figure out whatever that is in retail, banking. Put it in the lexicon of the business. Then educate them on the fact that the more return you want, the more risk you've got to take."

On the flip side, Cole said CIOs should also be sure they are communicating the successes.

This same principal of not fearing failure should apply earlier in the project management process, too. CIOs should not be afraid to cut their losses with projects on their way to failure.

"When I say kill a project, it could be, 'We're going to build a portal for the first time,'" Halbouty said. "You fire off a project, do an assessment and pick a product to build it on. And then we find the product isn't getting it done. I would say more times than not companies will continue to fight with the product and try to work with it."

Halbouty said on many occasions he has stopped a project, articulated why the product he is using in the project doesn't work, and then asked a vendor for a full refund. After that, sometimes the project doesn't need killing. The CIO can start over with a new vendor. Halbouty said this takes courage, to admit mistakes and the support of corporate counsel.

Halbouty said any company should be willing to take a risk on something that has potential for a high return, but the CIO has to know the state of his company before he takes a step in that direction, especially if he is new to the company and hoping to lead innovation right away.

He has to spend time to know what the CEO and other top-level executives expect the company to achieve. And he must also understand the state of the IT organization within the company.

"Is IT trusted or disliked? Is it a respected partner or a scapegoat?" Halbouty said. "Does it have solid fundamentals? Is it a strong integrator? Does it have clear cost drivers?"

Cole said, "One of the first things you have to understand is what is the company perception of IT and what is the perception IT has of itself. You have to understand that perception because then you know how bold you can be. If IT is seen as order-takers you don't propose a strategic effort to do an ERP implementation. You have to earn a reputation as a solid business partner before you can promote innovation."

Cole said IT organizations that are perceived as back-office organizations will find it hard to launch high-risk, innovative projects. Those organizations will have to be less aggressive and deliver that 100% success rate that some CIOs feel bound to doing.

But Cole said the CIO should continue selling high-risk ideas within the company. He should also take care to reward risk takers within his own organization so that when the time comes to move into high-risk projects, he has the team for it.

Let us know what you think about the story; email: Shamus McGillicuddy, News Writer

Dig Deeper on Leadership and strategic planning

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.