I am amazed that some of the things I hated about the Army back in the seventies are now making sense. As a young officer, I thought I knew better. To my dismay, some of that Standard Operating Procedure (SOP in Army-speak) really made sense. It still makes sense. It even applies to the legal aspects of obtaining computer hardware and software.
The Reverse Planning Process was SOP for many military tasks. The last step in your project is the first step in your plan. Decide where you need to be and when. From that result, work backwards to the present by making sure that each intermediate step fits into the plan. Don't do it the other way around. That same technique works wonders in the computing world. Start with the results you want, then decide how to get there.
To put it in a legal context: decide what you need (or want) and when you need it. Getting those two elements on paper will save you and the vendor hours of time— especially if it becomes clear that the proposed product will never accomplish the goal. And if a dispute arises between the vendor and purchaser, a clear statement of the end objective (the specifications and requirements) in a contract will be a key element in sorting out the legal responsibilities.
Simply put, a contract requires a "meeting of the minds" on various elements. It is an offer to sell something on certain terms, an acceptance of those terms followed by delivery and payment in accordance with those terms. Lawsuits on contract matters usually involve nothing more than proof that one or more of those elements were missing. My guess is that failure to pay is the most frequent breach of contract in most fields of law except for computer law. For the technology world, I suspect the biggest glitch comes in proving that there was a meeting of the minds regarding the specifications.
The biggest complaint has to be disagreement over what the program or hardware was supposed to do. The purchaser thought that the new gadget or program would do certain things. The vendor claims it never made that promise because they carefully disclaimed any warranties not expressly stated in the contract. Of course, you may have trouble finding any specific warranties in most "standard form contracts." In most cases, a lawyer for the seller prepares the contract and it is designed to keep that lawyer's client out of trouble.
Specifications and Requirements
In the contracting process you should prepare the specifications or requirements first. It is important to do so even if it involves a mass-market product and there will not be any personal negotiations. The buyer can still compare requirements to the specifications on the box. It may be a poor way to negotiate a contract, but it is the one that works millions of times every day. Also, if the product doesn't work, the buyer has strengthened any potential claims under consumer protection laws.
As the purchaser you want a product that accomplishes your tasks on certain hardware. If you have a Pentium Windows machine that only runs at 90 MHz (like my old Compaq) then you need to stay away from software and peripherals that specify a P200. I recently faced that very choice when I tried to find a new modem for that machine. Luckily I checked the system requirements before I placed the order. Otherwise I might have had trouble getting a refund. My argument that I thought it would work on my machine would be met with, "Look at the box where it indicates it must be run on a P200. So, no, you don't get your money back. We gave you exactly what we said we'd give you." In my case, I broke off negotiations and went elsewhere.
If you are the vendor (or as a software developer) you want to be sure that your product or services will work in the buyer's environment. In some cases your widget may work well on one type of computer but not others. Clearly stating the limitations up front helps to avoid many arguments. In more than ten years of practicing technology law, I have experienced all too many situations where the product would work but it didn't work very well. It was too slow or the vendor had to customize the product to work. Trust me, whenever the vendor or software developer has to "work around" a problem to make something run on your computer, the chances are good that it will never work the way either party thought it would. If a workaround is the only way to get to your objective, then make sure the "fix" is well documented to ensure that the steps can be duplicated (or reversed) in the future.
I do have one tip for purchasers of custom software or specialty hardware. Make sure that the specifications are clear on how the product will be tested. Vendors usually have a test program using dummy data. There is nothing inherently wrong with that. If the test data matches the real world then the test results are valid. In the real world, however, the purchaser only cares about its data. If possible, the purchaser should make a duplicate set of real data and insist on the right to test the product using the real data.
Support and Warranty
I consider these two items as one in computer technology. They should be considered at the same time as testing to ensure that both parties know when the warranty clock starts ticking. A purchaser may find that the testing and debugging time actually came out of the "free" warranty period because the contract stated that the product was accepted when it was used with real data.
I was fortunate enough to attend a computer law seminar many years ago at which an owner of a software company was very candid. When he was asked why most software warranties were so short he answered, "I'll make the warranty period as long as you want but I'll adjust the price for the product and extended maintenance." Most software warranties are very short and the remedies are few. Ninety-day warranties are not uncommon. Coverage for a year would be very long in my experience. That fact may not be too bad when you consider the rate that technology has advanced over the last ten years. I don't really care that my old copy of Multiplan that ran on my TRS-80 Model II is out of warranty. I stopped using it long ago.
Conversion
Make sure you understand how you will switch over to the new product. Will the vendor or software developer do it as part of the contract or do you have to do it? Make sure you understand if it means that you will have to stop using your system while the conversion takes place. If so, factor in that lost time in your calculations. I know of a conversion where it took a year to re-enter the old data into the new system because they were converting a paper system to electronic. They had to hire a temporary to type in all of that data, one book at a time. If the working crew needed the book, they had to go stop the temp worker because there was only one official copy of the record. On a big project, budget plenty of time and make sure the details of the parties' responsibilities make it into the contract.
The Contract
And a last tip is to get it in writing. Even if both parties shook hands and agreed to all of the details, a contract for more than $500 should always be in writing. In many cases that contract is not enforceable unless it is in writing. Recent (and proposed) changes in the law will give effect to contracts that are only in electronic form. But those may be good topics for future articles.
