The Integration Challenge

The case of the dueling vendor tables is a prime example. A federal agency's procurement office maintains a supplier vendor table as part of its automated purchasing system. This table contains vendor information and addresses needed to generate procurement contracts and purchase orders. The agency's finance office maintains a payee vendor table as part of its automated financial management and accounting system. This table contains information needed to process payments to vendors. About 75 percent of the information in these two tables is duplicated. However, the tables exist on different hardware platforms, and the information is stored in different databases. The process established to keep the tables in sync flails around in circles like a one-legged turkey. And the Grand Canyon separates the procurement and finance organizations. This is not a systems problem. Technology that could keep these two tables in perfect agreement does exist. This is a business-culture and organizational problem, one approaching the level of tribal warfare. Both groups understand the key elements of the solution. With a commitment to finding the right process, the technical challenges could be met and the needs of both procurement and finance satisfied. But what's the best way to get there?

A Study in Failure

At one entity with a $5 billion budget that's partly funded by the federal government, the procurement and finance organizations set out to launch new software applications to improve their operations. The procurement office was focused on helping to get goods and services as quickly as possible for the best prices. The finance office was focused on assuring its customers-financial managers, taxpayers and other funding sources-that purchases were made within budget, using the right funds.

Procurement and finance at this organization had a long history of mutual distrust and dissatisfaction. Now the government had embarked on a major effort to improve efficiency and was committed to implementing new automated information systems to support the two operations. Thus, representatives of the two project teams-one from procurement and one from finance-came together to link their applications. The procurement organization's project team was supported by contracts with three vendors, one for project management and strategy, a second for such implementation activities as training and data conversion, and a third for software development. The finance organization's project team was supported by one vendor, providing all of these services. I was the project leader for the finance team. Managers for each of the project teams faced the usual challenges of maintaining a schedule and controlling costs. But as work began on what became known as the interface development teams, it quickly became apparent that the primary challenge was dealing with the history of distrust between the two operations.

In early meetings among representatives from procurement and finance, it became clear that neither side understood the other. Procurement viewed finance as an impediment and the keeper of unnecessarily complex accounting records. Finance had a poor record of fulfilling its obligations in the procurement cycle, having made little effort to understand the needs of procurement officials. The following organizational flaws created fundamental problems for the joint development effort:

• The chief procurement officer and the chief financial officer failed to establish a good working relationship. Without an understanding of the challenges in implementing an effectively linked procurement and financial solution at this senior management level, second-level managers were unable to raise important issues with senior leaders who could work out solutions in the best interest of the whole organization.
• The procurement office committed very few employees to the project. Most of the work was handed off to several contractors, whose efforts were not well coordinated by the procurement staff.
• The CFO did not commit a deputy-level staff member to the development effort. These organizational flaws were rooted in each side's long-held misunderstandings about the other's business process and user needs. For example:
• While the procurement process touched thousands more users than the financial management process, the finance office did not appreciate the importance of creating a simple way to capture critical financial data from all of these users.
• The procurement team did not grasp the importance of the complex process for determining whether funds were available for certain purchases.
• Neither organization saw the other as a partner in solving problems, but rather as a major impediment to reengineering their business processes.

After 16 hours of meetings, the interface development teams produced an implementation plan that specified cost, schedule, development responsibilities and software design. The lead project managers approved the blueprints, but the chief procurement and finance officers never were briefed on them, nor were they involved in the open discussion of process issues embedded in the flawed design.

As work progressed on the software, serious questions about the implementation of the procurement system surfaced. The financial management project team had expected that the new procurement and financial systems would be launched simultaneously. But the procurement system had been delayed by several changes in software vendors and approach, while the financial system had become operational the previous year. In the interim, the procurement office implemented a manual process based on a paper purchase-request form.

To minimize disruption, the new procurement system and the new interface with the financial system had to be rolled out together. The transition from the interim procurement process to the new software required close cooperation between the procurement and finance offices. But at each important milestone on the procurement system project schedule, efforts to coordinate with the finance team failed.

As problems with the rollout of the procurement software arose, the procurement team blamed the interface with finance for the difficulties. The problems that surfaced included the following:

• The procurement office strongly believed users would not be able to provide the accounting information the finance office required.
• The procurement software could not validate any accounting information provided by users because procurement and finance managers had determined in the design stage that requiring the procurement system to edit accounting codes would impose too much coordination between the two applications.
• Software vendors and the contractor leading the procurement office's effort failed to understand the importance of several key data elements that had to be passed correctly to the financial system, leading to a high error rate in data processing.
• The procurement software had not been designed to handle an interruption in transactions while action was being taken in the financial system, which meant the procurement system had to be modified.
• The new procurement software allowed vendor purchase orders to be printed without approval from the finance office, which meant users could generate "official" purchase orders without proper certification.
• Neither procurement nor finance was prepared to provide resources to operate the interface, an effort that would initially require daily monitoring of files passed back and forth between the two operations.

Given these gaps in understanding and commitment, failure was inevitable. The volume of users on the new automated procurement system was far smaller than planned. None of the projected cost savings from use of the integrated supply schedules were realized. All of the key project leaders at the procurement office left their jobs, including the chief procurement officer.

Overcoming the Past

The challenge of implementing a new business process across organizational lines is clearly more difficult when the offices have a history of poor working relationships. In private industry, where managerial failure affects profits, the incentive for cooperation is strong. But failure to collaborate in government-where organizations form hard parochial shells for self-preservation and the costs to taxpayers are hard to add up-can easily sink a large-scale technology initiative.

Mistrust among employees at this organization's procurement and finance offices festered for a number of reasons, including previous failed attempts to find a common business process and automated solutions that supported each other's objectives. Each office blamed customer dissatisfaction on the other. Neither valued the contribution of the other. A lack of leadership and flaws in organizational structure led to conflict.

Interfaces between large-scale, complex business applications need not be so difficult. The development effort must start with a shared vision of a fully integrated solution. Compromises may be required to achieve results within given schedules and budgets, but a strong integrated solution should guide the overall effort.

The long delays in implementing the new procurement system in this case should have made procurement officials even more aware of the importance of close coordination with the finance office. Strong and clear communication from the top down should have emphasized the importance of developing integrated business processes and on building close working relationships with the financial side. The opposite was true.

This effort appears to have been doomed from the start, but too many systems projects struggle against such unfavorable odds. Systems teams, with their technical skills and powerful tools, are expected to overcome cultural and organizational obstacles. This project should not have proceeded until those barriers were overcome. A strong third party, such as an independent project steering committee, should have provided oversight.

The story of this failed project may seem inevitable in hindsight. But take this challenge: Look around at the automated systems efforts getting started, under way or just finishing up in your organization and ask yourself, "Will the end result be well-integrated, or will it be held together with heavy-handed interfaces because those responsible for designing the system linkages and the business process did not begin the project with an understanding of the integration challenge?"