IT Contracts are not a necessary evil, although many people see them that way. In fact, the only purposes IT Contracts serve are to protect the organization’s investment, expectations and legal and business interests. IT contracting is a process, which consists of three interrelated and interdependent components:
- Business;
- Technical; and
- Legal
All three components are equally important and equally dependent on the others. Organizations need to think about IT Contracts as business management tools that combine these components, and protect the organization’s investment and expectations. The first step is to understand that negotiating IT Contracts begins when a business need is identified and vendors are sought to meet that need.
Pre-Contract
Many organizations tend to be proficient in identifying IT business needs. When an IT business need is identified, the organization typically selects devoted staff to drill down and find vendors capable of meeting the business need within a definable budget. Then numerous vendor site visits occur and multiple reference calls are made, all in furtherance of the process to find the right solution and the right vendor. Demonstrations of the vendors’ IT deliverables are also required and freely provided by each potential vendor.
Many organizations are also usually proficient in drafting and including identified IT system functionality within a request for proposal (“RFP”). Vendors typically respond to the RFP and such responses usually include sufficient information to ascertain the potential success, and potential hurdles, of any future engagement. A vendor is later selected by the organization. All seems well.
A few years ago I received an urgent call from a client’s General Counsel. She said, “The Vendor is in the next room talking to my CIO and we would like to get this deal done by the end of this month. We are acquiring an integrated lab system which is critical to my organization.” I said, “Send me the Vendor’s contract and response to the RFP.” While on the call I was e-mailed the RFP response, which had been delivered to my client more than eight months earlier. After a quick look, I commented, “The vendor will not stand behind third-party IT system components, they are AS IS.” Her response, “You have to be kidding me, that’s a deal breaker.”
Drafting and submitting a RFP to potential vendors is only part of the process. Organizations need to review each vendor’s RFP response to identify issues early in the process. This will not only reduce the likelihood of having a deal breaker identified after the preferred vendor is selected, but will also reduce the risk of an implementation delay.
Lesson: Read the response to the RFP early in the process.
In addition, beyond identifying basic functionality in the RFP, organizations need to begin to internally ask other fundamental questions. The most basic being: Does the organization desire to conduct acceptance testing to make certain the IT system will do what it is suppose to do? The answer is typically, yes, of course. However, I am usually the person asking that question and pointing out that the vendor’s contract not only fails to contain acceptance testing, but has acceptance (and usually a large payment) effective upon delivery.
Lesson: Discuss acceptance testing with each vendor early in the process.
Organizations should also internally ask a number of other questions, a partial list of which includes:
- How and when do we expect to implement the IT deliverables?
- Do we want to test the IT deliverables in a test environment and in a subsequent production environment?
- When do we want acceptance testing to commence?
- Do we intend to test in a “big bang” or in stages (either by modality or by site)?
- What are the desired performance criteria?
- What happens if acceptance testing fails? Do we expect to receive all money back?
- How long do we desire the IT deliverable performance warranty?
- Do we expect other warranties? For example, a response time warranty and/or a compliance with laws warranty?
- Do we expect the vendor to provide a minimum support commitment period? How long is the expected support commitment? When do we expect support to start and when do we expect to start paying for support?
- Do we expect to receive the source code from the vendor in the event the vendor fails to perform or goes out of business?
Only after due consideration of these questions, among others depending on the organization’s objectives, will an organization understand how to protect its business interests and expectations. The IT Contract is the vehicle for doing so.
Lesson: Ask these questions, at the very least, and discuss with each vendor early in the process.
Organizations should convey its IT Contract expectations to each potential vendor early in the process. I recommend including basic contract terms as well as important business provisions within the RFP submitted to each potential vendor. Organizations should advise each vendor that its RFP responses will be used not only to evaluate the vendor’s product and the vendor, but that its responses will also, at the organization’s discretion, be part of any final IT contract. Remember, read each RFP response.
If these pre-contract steps are followed, organizations will begin to think about IT contracts as business management tools. Such pre-contract steps will:
- Enable the organization to identify critical issues and risks well before selecting a preferred vendor;
- Enable the organization to obtain and protect its technical and business objectives (e.g., appropriate acceptance/warranty/support provisions);
- Enable the organization to manage its implementation (e.g., increase the likelihood that the IT Contract will be executed before the time scheduled for implementation); and
- Enable the organization to reduce its risks and to protect its investment.
Failure to include these basic pre-contract steps as part of the IT Contract process will almost inevitably lead to an accelerated negotiation which may unnecessarily compromise the organization’s financial and business interests. Absent these pre-contract steps, the organization will often find itself discussing important objectives and terms with the preferred vendor much too late in the process, in a way that disappoints the expectations of the organization’s executives, administration and staff.
Such pre-contract steps directly play a role in the negotiation and ultimate terms obtained in the IT Contract.
Lesson: During the pre-contract period, view the contract as a business management tool.
Conclusion
IT Contracts are not a necessary evil. They are an organization’s most effective tool for managing the enormous business risks associated with the organization’s increasing reliance on IT Systems to perform critical functions. Organizations should start to think about IT Contracts as business management tools. The first step is to understand that negotiating IT Contracts begins when a business need is identified and vendors are sought to meet that need. By viewing IT Contracts as the vehicle to protect expectations, organizations will reduce their risks.
