I started my career in IT in 1965, when I worked as assistant to the production manager for a company called Data Processing Consultants. I retired in December 2004 as the CIO and senior vice president, international and technology, with Ace Hardware. During those 40 years, I’ve witnessed the seminal events of the information age, from the introduction of the IBM 360 computer (the first family of mainframes with compatible operating systems) to the emergence of the Internet and wireless technology.
We all know how IT has revolutionized business. In a speech last year, Alan Greenspan credited IT in part for the resilience of the U.S. economy in the face of “stock market crashes, credit crunches, terrorism and hurricanes—blows that would have almost certainly precipitated deep recessions in decades past.”
Given IT’s impact, it would be natural to conclude that IT departments and the CIOs who run them are heroes. You would be wrong. Despite the dramatic and revolutionary changes implemented by IT, the IT department is still treated like a necessary evil in many companies.
We still have the reputation of taking too long, not delivering exactly what is needed and not being sensitive to the needs of the corporation. CIOs’ job tenure is still relatively short, averaging just under five years. Nicholas Carr has convinced many non-IT executives that IT doesn’t matter. Lacking a fundamental understanding of the value of IT, companies outsource some or all of the IT department. Many CFOs still look at IT as a cost rather than an investment. I’ve even heard comments by IT professionals suggesting that this is not a good career for their kids to pursue.
Painful as it is to admit, this is our fault, because we fail to exercise leadership among our senior executive peers. We don’t demand a strict adherence to the basic rules of project management, we’re too willing to accept the blame, we’re not always sensitive to the needs of the business and we fail to communicate our achievements.
Stop Taking the Blame
IT departments are staffed by people who thrive on getting systems to run. To many of them, time and budget is less important than getting it right. But business executives expect performance. When CIOs aren’t skilled at setting expectations or are not at the table when decisions are made, oftentimes IT bears the blame if something goes wrong with the technology.
It’s up to CIOs to change this mind-set by making sure business users and IT collaborate on systems development. CIOs should not allow development to go forward without clear specifications from users (who tend to hope that IT can figure out what they want). CIOs must also insist that when users make major changes during development, these are documented and that user management signs off on new costs and time lines.
Several years ago Ace implemented an incentive program for developers that paid off only if they achieved the agreed-upon budget and time line for a project. Immediately, they took their collaboration with user departments more seriously. Both users and developers realized that there was a strong incentive to maintain the original schedule and put requests for additional functionality into future phases of a project.
IT also documented any modifications in monthly project reports, which we provided to everyone in the company. As a result, no one could say that they were not informed of and involved with project changes. This took pressure off of IT and assigned business users some of the responsibility for cost increases and delays.
Use Business Smarts
CIOs should speak like businesspeople. We should talk about trade-offs, backup plans and business strategy. We mustn’t think that the toughest problems reside in the IT department. We must understand the cost structure of user departments and the pressures that users are under to achieve their goals.
IT must serve all of its masters in a company, not just the most powerful ones or the ones who shout the loudest. We must be aligned with corporate business needs, not with IT’s needs. CIOs must play an active role here by making senior management aware of new technologies and how those advancements can save the company money or increase productivity.
I learned this lesson back in the early 1980s, when Ace was using a very costly cut-and-paste process for producing our dealer catalog. We investigated what were then new laser printing technologies that could print both text and pictures. The system saved the company millions of dollars a year.
It’s hard to get recognition for your contributions when no one knows what they are. The post-implementation audit is one way to identify whether a system has achieved its promised results, but these reviews are seldom done in any formal way. As a result, advantages of the system become embedded in the cost structure of the user department and IT is never identified as the source of the improvements. Most IT departments don’t care about this because they are on to the next project. Meanwhile, the user department is more than happy to take full credit for the benefits.
I found it difficult to get my company to conduct post-implementation audits. A major reason is that these can’t be done just by IT. They depend on a collaboration between IT and the user department; the cost savings can be identified only by the users. The best way to achieve this is to make post-implementation audits a best practice within your company (and ensure that top management requires them). Making post-implementation reviews a function of a third-party organization such as internal audit helps to encourage all parties to participate.
When I have been able to do it, it has achieved the desired effect of proving the business case. For example, when Ace implemented a data warehousing system, our CEO demanded that the user departments quantify the long-term benefits before he approved the project. Once the system was implemented, he required the major users to report quarterly to the executive officers what benefits they were realizing from the system. By holding users accountable for the results, this approach ensures that future cost/benefit analyses will be more accurate.
If we can get users to understand that they must engage in pre-system development and post-implementation audits, we will ensure a higher degree of successful system delivery and accountability for results. Only when our colleagues know what to expect from us, when they understand what we do, and when they trust we understand their needs, will we begin to change many of the stereotypes that have followed us from the early days of computing.