Former Ace Hardware CIO on IT failure [podcast]

Complexity rules any discussion of why IT projects do not achieve planned or expected results. Many projects cross traditional organizational boundaries, requiring collaboration between business and technical groups to achieve successful IT results. The high rate of failure suggests this collaboration is fraught with difficulty and needs improvement.

Paul Ingevaldson, former CIO of international retailer, Ace Hardware, is in a great position to offer insight into why IT succeeds or fails. While CIO of Ace, he was simultaneously Senior Vice President of International, had P&L responsibility for stores in 70 countries, and ran the company's Ace Canada subsidiary, all of which made him a large business consumer of IT services. Paul also writes and speaks on IT and CIO issues.

As you'll hear in the podcast, Paul is direct and not hesitant to speak his mind.

On the cause of poor business / IT alignment:

I've always had a hard time with that. If the officers of the company are involved with determining the IT agenda, why should IT be aligned with the objectives of the company any less than the sales, legal, or manufacturing departments?

Sometimes upper management mismanages IT, which does what it thinks is best, but not necessarily what the company needs. That's the source of the alignment problem. Management structure causes these issues rather than the individual tactical issues related to a project.

The alignment thing is one of the big issues and a very common occurrence.

On resolving alignment problems:

I feel very strongly that the CIO should report to the CEO, or at least the COO, to give the CIO independence and establish him at a peer level with other C-level officers. This allows him to service the whole corporation without just being left alone to do whatever he or she wants.

On users' responsibility to work effectively with IT:

IT is unique because it develops systems used by other departments. It's important for users to understand how to work with IT when creating new projects, implementing those projects, and making sure they're done correctly. Often, users want to have minimal involvement, which results in projects not fulfilling user requirements. Many problems come from users not understanding the level of participation they must have on IT projects.

On responding to criticism about blaming users:

IT falls down on many things that have been well documented, while the user's role is not discussed very much. Users must understand when they have to get involved in the project itself. At Ace, we required that users spend enough time with IT to specify the requirements, otherwise we would not work on their project; we only worked on projects where the user committed him or herself to define properly. That was a rigid process and many users didn't like it, but we felt it was important.

The blame is not just on the IT side; much of it has to do with the users. There must be mutual understanding if we are going to prevent projects from being the failures we see in the press.

On measuring IT's business value:

We don't do a very good job on this.

In every project development life cycle I've ever seen, the last step is an audit where we are supposed to determine if the project delivered on the recommended ROI. Seldom, if ever, is that done. Therefore, IT is never able to show the value it provides the company, while the user department shows the value in their P&L through reduced head count or some other savings that the project has delivered. The company never gives IT credit for that.

If CEO's are willing to spend the enormous amount they do every year on IT, they should know the value that IT is providing the company.

I recommend third party organizations conduct those measurements. In larger companies, independent audit should do it, as they audit any other kind of very expensive system. That is the only way to show the value IT provides to the corporation.

[Photo of Paul Ingevaldson via Enterprise Leadership. This post is an edited summary of the podcast.]