Barry Shapiro Authors, "Avoiding Disaster When Purchasing Software" for Business Long Island

Publication Source: Business Long Island

Although companies have been negotiating and implementing software development agreements for decades, the same risks (some of which can be crippling and very expensive) await the unwary. Late delivery, delivery of software that simply doesn’t work or which doesn’t do what it is supposed to do and unexpected cost overruns are only a few of a virtually unlimited array of perils that may result from a poorly thought out and improperly structured software development contract. Here are some suggestions to facilitate your software development project.

• Check the developer out carefully. Seems simple and fundamental, doesn’t it? Yet, you’d be surprised how many companies enter into development agreements for company critical software without making certain that the developer has the experience and financial stability to deliver on time and on budget. So, do what you would do when hiring a contractor to put an addition on your home (or at least what you ought to do). Ask for and check references. Talk to other business owners who have used the developer and find out which members of the developer’s team worked on the project. If the reports on a particular team or team member are favorable, insist that those people work on your project and put it into the contract.
• Insist on a proposal from the developer. After you’ve discussed your project with the developer, insist that he give you a detailed proposal. This proposal serves a very important function because not only will it force the developer to give you, in detail, what his product will do for you, but it will also be an attachment to and incorporated into the contract. So, in the event that there is a problem and the software doesn’t do what it is supposed to do, you’ll have the developer’s promises incorporated right into the contract and it will be easier to assert a viable claim against him.
• Don’t rush when putting the specifications together. This is very important. Often, either prior to the contract, or as a critical step after it has been signed, the parties will put together a detailed, technical description of how the software is supposed to function. Your information technology professionals will be intimately involved in this. Make certain that this document is very, very thorough. As discussed below, it will be the gold standard against which the developer’s performance will be measured and, read together with the proposal described above, constitute critical ammunition (if you ever need it) in a dispute with the developer.
• Use great acceptance tests. Although fundamental, it is often overlooked. Here is how it works. The developer is paid only when it demonstrates that it has developed the software to your satisfaction. This is not measured only at the end of the process, but at specific milestones. As each module of the software is developed, it should be tested according to a test agreed to in the contract or the specifications and which is intended to demonstrate that the software performs consistent with the specifications. If it doesn’t, then the contract should state what happens. What’s fair if the software fails its test? Most contracts provide that the developer gets another chance to make it work. If the second shot fails, then you should have the right to cancel the agreement and get all of your money back, not just for the module that failed, but for all preceding modules (after all, you contracted for an integrated system with all modules working with one another; you didn’t contract for anything less than that and you shouldn’t have to accept less). After one test is passed, the next test should measure the performance not only of that module, but should also demonstrate that the new module works with all previously modules so the system works as an integrated whole.
• Get a great warranty. Your warranty should provide that not only does the developer have all right, title and interest to the software, but that the developer’s rights in the software have not been previously assigned or encumbered and that your use of the software does not infringe anyone’s proprietary rights. The developer should also warrant that the software conforms to the specifications and documentation. Simply put, the developer should warrant that the software will do what it is supposed to do. Obviously, negotiate for as long a warranty as you can and make certain that if the software crashes or doesn’t do what it is supposed to do and the developer can’t fix it (at its sole expense) or can’t replace it with a software package that does the same thing as the one you bought, you can return the system for a full refund. Expect the developer to resist this but insist on it. During the acceptance period, you could have gotten your money back if the software failed its acceptance test. You should have the same right after acceptance.
• Get access to the source code. Even if you don’t have substantial knowledge of software, all you need to know is that the source code is the key to understanding and dealing with the software’s inner workings. The developer will resist giving it to you. It’s considered very proprietary, and rightfully so since it gives you the ability to conduct all maintenance and upgrades and even to make the software available to third parties. Under certain circumstances you will need it (for example, the developer goes out of business or defaults in its obligations to maintain your system). Handle this by arranging for the code to be put into escrow with a third party. Be sure to spell out clearly when the source code will be released to you.
• Protect your confidential data and keep benefits away from your competitors. You’ll be giving the developer all sorts of confidential information about your business. The contract should contain an agreement by the developer to keep the information confidential and not to disclose it to anyone. However, you may wish to go beyond this. Let’s say that you’re in a specialized industry and are developing new software that will give you a decided competitive advantage. The last thing you want, after you labor to design and install the software, is for the developer to walk into the competition and say, “Do we have some software for you!” So, be certain to restrict the ability of the developer to resell your software to those users who might present a threat to you.