The IT Train That Could: Getting Agreement on Major Initiatives

Have you ever had difficulty getting agreement on which major initiatives your IS department should pursue? And when expenses get cut, which applications do you eliminate or slow down? Those were a couple of the challenges I faced when I became CIO at Union Pacific Railroad in 1992.

I knew the overriding solution had to revolve around two principles: 1) IS needed to focus its resources on what was most critical to the business and would have the greatest impact, and 2) the major internal IS customers had to be involved in the decision making and have “skin” in the outcomes. During the next two to three years we evolved a process, called UP/2000 (later renamed UP/21), that worked well for us?in fact, it was ultimately adopted by many other companies. I’d like to share with you how it worked.

The Right Links

The job I filled at Union Pacific had been vacant for six months, and there was little new development in progress. A long-range systems plan had been developed several years earlier, but there was no current plan or process to determine what new development should be done or what should be cut during budget revisions. Companywide, there were many pent-up needs for IT systems, and we needed to determine on a rational basis?not a “who you know” basis?what new systems should be undertaken. Owing to a reorganization before I arrived, the IS department reported to the CFO, who was very much in favor of establishing a process for objective decision making.

An essential part of our solution was to tie all IT work to the company’s business processes. First, by interviewing our internal customers and inviting them to critique our existing business process documentation, we defined the business process flows within and among customer departments. Next we mapped the existing IT systems to those business flows and characterized each system by whether it supported the business flows, needed modification or needed to be replaced. For example, we found gaping holes in the systems that supported the maintenance of locomotives. By inserting an expert system to analyze the diagnostic data already captured in those locomotives, we could not only speed up the business process of determining what needed repair but also send advance information to the locomotive shop for more efficient planning and scheduling. Increasing the uptime of each locomotive meant fewer new locomotives had to be ordered.

We then organized the involvement of our major internal customers according to the business processes they used to accomplish their business objectives. This approach was based on the fundamental belief?shared by me and senior executives, including the president?that a company should first decide what it is going to do (its revenue goals, profit goals, strategies, for instance) and then what business processes it will use to achieve those objectives (such as how it will interact with its customers, what performance criteria it will meet, what payment methods it will use). The IT systems should then flow from these first two steps and enable and support the business processes.

We had a tough time deciding how to group the business processes. We started out with 11 groups that we quickly reduced to five. We then further reduced this grouping to four: customer product (those dealing with the external customer?marketing, selling, assisting, servicing); transportation (those dealing with planning and providing the actual transportation from one point to another); physical resources (those dealing with procurement and supply, maintenance of equipment and physical structures and so forth); and managerial (the remaining business processes, including financial, human resources and legal).

We felt it was critical to get the major department heads as stakeholders and participants in this process. But the organization of the company into departments did not always mirror its business flows. So we sat down with each of the department heads and got their ideas on which of the four groupings their business processes mostly fell into. We then got them to commit one or two hours every month or two for process team meetings. We also asked especially influential and knowledgeable department heads to lead or colead a process team. For example, the customer product process team was cochaired by the vice president of customer service and a vice president of marketing and sales. The chairmen conducted the process meetings; members of their departments and my IS team did the work to prepare for each meeting and recorded the results.

Checks and Balances

The purpose of the process team meetings was to establish and rank the major IT initiatives for each business process group and to assure that there were good business cases for each initiative. They were also an opportunity for department heads to build consensus and support for common initiatives such as replacing core legacy systems. In addition, each meeting was an excellent opportunity for IS to give a brief progress report on its current deliveries to those business process areas as well as any issues that needed resolution.

At least quarterly, we brought all the process teams together for companywide discussion to build consensus, arrive at decisions and engage support for the major IT initiatives. If we couldn’t get consensus, we at least gained understanding. In those meetings, the major IT initiatives were presented by the sponsoring internal customer departments, who also argued why the initiatives were critical to the business.

At least annually, the department heads prioritized all of these IT initiatives. There was usually a lot of healthy discussion, and we could see cross-company understanding build. We then used the prioritized list for budget discussions on where to draw the funding line; the final decision came from our president and included input from the four executive vice presidents.

Overall we found that this process produced a number of benefits. It confirmed that the company was spending money on IT initiatives that were deemed most important to corporate objectives. Each project had a good business case, and the highest levels of management were committed to making effective use of the systems once they were installed. The finance department did post-installation audits to ensure that the “hard” benefits stated in the plan were actually achieved. The results were shared and thus visible at all levels. IS’s morale reached new highs, and there was more true partnership between IS and the rest of the business.

After our newest president had been on board for close to a year, he said to me one day that he didn’t hear the grumbling about IS that is common in many other companies. My reply was that that may be because IS is doing the work the company believes it needs.