Underestimating Process Changes

This is far from the only way that the business/technology disconnect can reveal itself. Our next example of a real-world disconnect is framed by a common dilemma that IT professionals face: After installing a new enterprise application, they find a gap between the business processes it supports and the processes that are already in place. To bridge this gap, they face a critical choice ”to either pay for expensive modifications to the software, or change how the company does business to fit what the technology supports out of the box.

Carl Wilson, Executive Vice President and CIO of Marriott International, Inc., is a strong proponent and successful practitioner of alignment. Marriott, lauded for its progressive alignment initiatives, enjoys the fruits of Wilson's previous experience and lessons learned. Throughout his extensive career in IT, Wilson has witnessed firsthand how disconnects caused by underestimating the impact of process changes can bring about real damage to the business. In this example, he recounts the story of a CEO who wanted better visibility into his human resources (HR) information so that he could assess his company's equal opportunity compliance:

The CEO started out with what he thought were some pretty basic questions: How many people do we have working at each geographical location? Can we figure out what skills each of our employees has? What training have they received? But when he approached his head of human resources, he found the problem was worse than he imagined. Not only was it impossible to answer these questions, but the HR department couldn't even track straight forward data like the number of people who worked at the entire company.

The CEO quickly kicked off what he expected to be a straightforward project: implement an HR system for the company. But in the end, the disconnect between the new software and the company's established business processes, ended up costing the company millions.

From the start, the project was put on the fast track, and the company hired a large, high-profile consulting firm to implement the system. After a short evaluation period, the consultants recommended three ERP packages from leading vendors .

The consultants were under intense pressure from the executive team to fix the problem as quickly as possible. To save time, they assumed that all HR processes were essentially the same, and brokered a deal with a vendor whose product had been successfully installed a number of times for companies in the same industry. The contract, Wilson remembers, was the standard consultant's contract; there was minimal negotiation, and the company signed right away.

Early on, however, it became apparent that the installation wasn't going according to plan. When the new system came online, employees clung to their familiar business processes and demanded that the software be customized to fit the processes they were used to. The team eventually yielded and undertook a massive customization program. As a result, the project, which was originally budgeted at $4 million, instead ended up taking three years longer than expected and costing $9 million.

Consider what happened in this example: The project started out with the sound business objective of better visibility into HR. But because process changes weren't addressed until after the technology had been designed and implemented, a disconnect cropped up between process and technology (see Fig. 1.2). Modifying this technology to match up with the processes cost millions.

Figure 1.2. In Wilson's story, a disconnect resulted when process changes weren't addressed until after new technology had been finalized

A better solution, of course, would have been to adjust what were essentially low-value HR processes to fit those that the software supported out of the box. But the consultants on the project didn't make the connection between the new software and its affect on existing processes. They never collaborated with the end-users to find out how their processes were carried out today, and never communicated how those processes would have to change. As a result, Wilson says, end-users fought change from day one, even though doing so cost millions in customization:

Nobody likes change, and they don't want it imposed upon them. So they have to have the benefits clearly demonstrated to them before they'll actually move along and accept any kind of change. So the problem wasn't really the technology. The truth was, ninety percent of the functionality was there. But to make it work they would have had to spend significant time and effort reengineering their processes.

Projects that overlook processes when they make changes to technology do so at their peril. Instead, Wilson argues, companies need to acknowledge that process management is a central component of IT change:

My early career background was as an industrial engineer, so I'm accustomed to applying the principles of process management. But some companies don't want to invest in the up-front planning that this takes. This is a mistake.

People in leadership roles who kick these projects off often have a good understanding of what the end result will do and how it will affect them, but a lot of times they don't bother to communicate this to other people to get them involved in the process. As a result, the first time people are brought into a project is when it's being implemented and they're being trained on it. So you end up with a huge backlash and people fight this tooth and nail even though you tell them that eventually it'll benefit them. Until they can see it for themselves , they'll resist embracing new business processes.

Early involvement through process management settles issues up-front instead of forcing people to react later on. If they're brought in early and convinced that the new technology will impact them on a day-to-day basis, they're more willing to accept it, buy into new business processes, and make it work to their advantage.

When you just tell people to stand up and salute the flag they'll do it. But they won't believe it until they get involved and see for themselves the benefits of changing their processes.