Magazine article Government Finance Review

Contracting for Enterprise Financial Software: The Methodology of Parallel Negotiations

Magazine article Government Finance Review

Contracting for Enterprise Financial Software: The Methodology of Parallel Negotiations

Article excerpt

This article presents a contract negotiation approach that improves the value of financial software and implementation services by retaining competition throughout the final phases of the procurement cycle.

Motivated in-part by the Year 2000 problem, state and local governments across the country are improving organization-wide decision support by replacing legacy financial systems with integrated software, commonly referred to as enterprise resource planning (ERP) systems. ERP systems enable process reengineering, best-business practices, and seamless information integration across functions and agencies. While the benefits of ERP systems are well-known and highly touted, implementations are risky and challenge even the most resilient organizations. As Thomas Davenport recently noted in the Harvard Business Review, "If you're not careful, the dream of information integration can turn into a nightmare."(1)

Implementation failure risk can be reduced with a well-planned strategy for establishing a contract. A software/implementation services contract is an agreement by the two main parties that defines what is being purchased, outlines the implementation approach and timetable, presents expectations about software performance, and establishes penalties for non-compliance with contract terms or conditions. In ERP procurements, contracts often describe the roles and responsibilities of both the government and the software/implementation vendor. Experts often advise governments that when negotiating for software they should follow the general rule, "If it's not in the contract, it doesn't exist."

State and local governments often have difficulty negotiating technology contracts and they face other disadvantages. There are several reasons for this. First, government procurement procedures are generally designed for commodity purchases; public managers have difficulty conducting subjective "value"-based assessments for software and services. Second, the infrequency of system replacements provides public agencies with few incentives to retain in-house legal expertise with knowledge of intellectual property-rights law. Consequently, vendors that governments are negotiating with have considerably more expertise because they have repeatedly negotiated such contracts. What government agencies do once every decade or so, vendors are doing on a weekly basis. Third, with the demand for ERP systems estimated at exceeding $14 billion worldwide, public and private agencies are making decisions in an extraordinarily dynamic environment - a "sellers market" in which future patterns of industry structure, products, and services are difficult to predict. Lastly, because finance officers are no longer selecting software for the accounting function alone, they often find themselves spearheading the selection of packages that may include functions outside of their core competencies.

This article provides a contracting methodology for large-scale ERP procurements for state and local governments. A step-by-step methodology is provided that offers an approach for retaining vendor competition throughout the final phases of the procurement cycle. Checklists of factors to consider in developing a Statement of Work (sow) and for establishing a contract also are presented. Although the approach outlined in this article is especially well-suited for high-dollar ERP procurements, many of the tips and traps presented have relevance for smaller jurisdictions and projects.

Traditional Procurement Approach

Governments often approach the procurement of software and implementation services as if they were procuring tangible assets or commodities. The short-term costs are given more weight than the life-cycle value of the ERP system to the organization. Typically, a Request for Proposal (RFP) is released, vendor proposals are received, responses to business requirements are analyzed, and demonstrations/site visits are conducted. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed


An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.