To ERP or Not to ERP?
Out of the gate, any organization considering a software upgrade must assess whether an ERP system is the appropriate software in the first place. This requires appropriately weighing the potential benefits (such as heightened efficiencies, improved business processes and the replacement of aging legacy systems) against the potential downsides (such as licensing and implementation costs, extended timelines, user acceptance, and the risks of system failure).Public entities are often more constrained than private companies in the upgrade options available. For example, whereas some companies are able to pursue a highly customized, “home-grown” system designed and built by internal resources or a leading outside vendor, this option might not be available to governmental entities. That said, public agencies might have some advantages, such as relying on systems already in place in other agencies.
Selecting the Software and a Systems Integrator
ERP software selection should not be treated as a standard procurement exercise; in fact, it is anything but. For one thing, it is usually a two-step process, involving a software selection phase (for example, Oracle versus SAP) followed by a software integrator selection phase (for example, Accenture versus Deloitte Consulting). Beyond that, the RFP/RFI process must be formulated with an eye toward drilling down into at least four crucial areas: software customization, project team, methodology and quality assurance. A public entity’s failure to address these areas during the selection phase can have lasting legal repercussions in the event a dispute arises as a result of system defects, scheduling delays or ballooning budgets.Software Customization/Fit — The “sales cycle” refers to the pre-contract stage when the vendor’s sales team conducts presentations touting the suitability of the software and the skills and experience of the team that will implement it. During this stage, public entities need to understand and discuss the degree of customization that might be required to obtain the needed functionality — i.e., to assess whether the software is a good “fit” for the business at issue. While most ERP implementations require some degree of customization to enable the software to run a client’s business, excessive customization can potentially lead to performance problems and higher maintenance costs. Moreover, even a reasonable amount of customization might still require consultants with a higher level of skill and experience. Accordingly, during the sales cycle, the public entity client needs to obtain specific assurances that the customization required will not undermine system performance, and that the vendor’s project team has the specialized skills necessary for properly customizing the software.
Project Team — Many ERP projects fail because the vendor’s team of consultants lacks the necessary skills and experience to perform the implementation. Sometimes, the vendor will provide the client with a roster of team members slated for the project, promising to deliver the “A team” — but, when the project kicks off, it is the “B team” that shows up. This risk can be pronounced in the public sector, where procurement rules might lead to a delay between the end of the sales cycle and contract execution. One way for public entities to avoid a vendor’s “bait and switch” is to obtain a contract provision that the team promised during contract negotiations is the team that actually works on the project.
Methodology — ERP projects often fail because the systems integrator performs its work ad hoc, taking shortcuts to save time or cut costs and, most important, failing to document its work, to conduct appropriate testing, and to identify and mitigate project risks. To avoid these potentially devastating missteps, applicable professional standards require that software consultants perform their work pursuant to a software implementation methodology. Public-sector clients need to know what methodology their vendor is applying, and to insist that it be scrupulously followed.
A software implementation methodology is a set of procedures and processes that a project team follows to ensure that (1) the project proceeds in appropriately structured phases, with clear milestones, lines of communication and adequate oversight, and (2) potential problems are spotted early through quality assurance (QA) reviews. While ERP firms often have their own proprietary implementation methodologies, they are all fundamentally similar and generally conform to the guidelines established by professional organizations such as the Project Management Institute (PMI).
Quality Assurance — QA is a vital component of basic project management methodology, and deserves special emphasis. It is imperative that public entities demand that their ERP vendors utilize rigorous quality assurance procedures to ensure that the state or municipality receives an objective assessment of project status and risk at regular intervals. The client must also be mindful that some consulting firms maintain an internal QA review process that focuses on the risk posed to a project by the consulting firm itself. The client should demand access to all QA reviews, and insist that the vendor be transparent about all project risks.
Contract
A public agency’s typical procurement contract might be unsuitable for addressing the unique risks posed by ERP implementations. While ERP contracts might contain any number of unusual provisions, three in particular deserve special attention: acceptance of work and deliverables, client responsibilities and staffing, and limitations of liability.Acceptance of Work/Deliverables — Virtually all ERP contracts contain provisions governing a client’s acceptance of interim work, or “deliverables.” Some vendors will, in the event of a dispute, seek to foreclose their legal liability by pointing to the fact that the client approved or accepted defective deliverables. ERP clients must therefore make sure that such provisions do not waive any of their rights, including their right to demand that defective software be fixed, or the right to seek compensation for defects about which they could not have been aware at the time they accepted the deliverable.
Client Responsibilities/Staffing — ERP contracts typically require that the client assign appropriate numbers of employees, including subject matter experts and executive sponsors, to the project. That can impose a unique burden on public entities facing resource constraints stemming from budget caps, union rules and other public-sector realities. At the contracting stage, procurement officers must therefore take pains to ensure that applicable contract provisions provide a public entity with a means of relief against a vendor’s unreasonable resource demands.
Limitations of Liability — Most ERP vendors seek to include provisions in their contracts that limit their liability to direct damages for breach of contract only. Such provisions usually limit a client’s recovery to fees paid to the vendor for defective work. But a failed ERP project can have far-reaching consequences in the public sector, affecting the provision of government services to citizens, public health and safety, and the ability of unionized workers to get paid. While state law may provide certain protections against contractual limitations of liability, procurement officers should insist at a minimum upon an exception to any such limitation in the event the ERP vendor engages in intentional misconduct or gross negligence.
