STATE AND LOCAL MODERNIZATION PROJECTS USING COTS/MOTS SOLUTIONS
Let’s stop beating our heads against a brick wall: 4 fundamental disconnects with outmoded contract terms and conditions
In the last decade, state and local agencies changed the way they implement large software modernization projects; however, the same is not true for the contracts that govern these projects. For this article, we discuss four categories of terms and conditions that are outdated and don’t reflect the evolution of software products or the product implementation approaches required for today’s modernization projects. Consequently, vendors, procurement professionals, lawyers, and client leadership spend significant time, money and emotional capital trying to solve the proverbial “fit a square peg in a round hole” conundrum during negotiations.
In that same decade, we’ve witnessed a shift from custom-developed software solutions toward a model of reusable, configurable and extensible off-the-shelf software products. These solutions, sometimes called Commercial Off-The-Shelf (COTS) or Modified-Off-The-Shelf (MOTS), reduce project risk and cost and provide an upgrade path to improve long-term return on investment. More often than not, vendors use Fit-Gap implementation approaches that feature the product heavily as the instrument of change, and for project planning and change control.
While changes in software design and implementation have reduced project risks and costs, an outdated contracting process is precluding state and local agencies from realizing additional cost savings. Four categories of terms and conditions are the culprits behind the fundamental disconnect. And, those same four culprits are responsible for nearly every rocky relationship, negotiation breakdown, or even RFP cancellation.
1. Intellectual Property (IP) Ownership
We need to retire the “I paid for it, I own it” philosophy.
Cost reduction (Total Cost of Ownership) is the primary reason that the industry has moved toward products over custom development. Cost reductions occur because software products aren’t developed from scratch for every client project. Instead, vendors implement an existing product that the vendor continuously improves. No individual customer bears the cost of developing that product. However, this shared resource model doesn’t work if every respective client owns that product.
What customers need is a license to use the vendor’s product. The particular rights and the specific terms and conditions governing those rights are a matter for discussion between the provider and the client, but ownership should not be.
2. Limitation of Liability
It’s clear that clients want vendors to take responsibility for their products and services, and they should. However, contracts often request unlimited liability. But no vendor can accept the unlimited economic risk, and certainly not for any one project. This isn’t limited to our industry. It’s an economic reality in every industry.
There’s one more point to be made on this topic. A limitation isn’t real if there are exceptions for every potential source of liability.
Vendors can’t accept indemnification as an alternative approach to unlimited liability. That happens when indemnification provisions are overly broad. Perhaps the best example would be an indemnification for breach of contract. In effect, there is no limitation of liability when there is an indemnification for breach. For this reason, indemnifications should be limited to intellectual property infringement issues.
4. Objective and Subjective Standards
All too frequently, we see contract provisions that give the client sole discretion to determine whether contract obligations are fulfilled. This can apply to anything — from acceptance of deliverables to duration of User Acceptance Testing, or even the perception of usability.
However, when sole discretion provisions are combined with fixed price contracts, there are immediate disconnects regarding schedule adherence, resource management, risk management and anything that resembles project management 101.
The best way to avoid those misunderstandings is to define objective measures for all contractual obligations. Ideally, they should be defined as part of the RFP itself, but at a minimum, they need to be reflected as part of the contract. Objective measures push both the client and the vendor to think through, talk through and carefully document those measures.
Room for improvement
We believe there are two overarching reasons why state and local clients are routinely dealing with these contract problems.
The first is that contract assumptions haven’t caught up with the reality of how large software modernization projects are implemented now. They neither reflect the market shift toward the model of reusable, configurable and extensible off-the-shelf software products, nor the shift toward Fit-Gap implementation approaches.
Secondly, we see generic fixed price contract provisions being carried into software modernization projects, increasing the “square peg in a round hole” challenge. For example, we see contracts with shipping terms, performance bonds, and other provisions that have no application to these kinds of projects.
In both cases, contract negotiation is slowed. The inapplicable contract terms must be identified and addressed before the terms applicable to the project can be addressed. Time is wasted, and client-vendor relationships can be unnecessarily strained.
What’s needed is a departure from contracts based on old business models and from one-size-fits-all procurement processes. A small group of stakeholders from the vendor and procurement community (e.g., National Association of State Procurement Officials) could take that on. Working together, that group could revisit and reset expectations for both clients and vendors.
About the Authors
Rick Deshler is a Senior Partner at Sagitec Solutions and has been involved in state and local modernization projects for over 20 years. He can be reached at email@example.com. Tim Keller is an attorney in Minneapolis. He has been practicing in the technology law field for more than thirty years. He can be contacted at firstname.lastname@example.org.