Contract Review Pointers and Price Considerations
Contract Review Pointers and Price Considerations
Contract Review Pointers and Price Considerations
CHAPTER 7
Sometimes you will also have hardware purchase agreements and third-party license
agreements. In each agreement you need to focus on key definitions and variables.
Although there is no such thing as a typical or standard agreement, we will highlight
some general pointers.
37
section1.qq1 10/15/01 4:24 PM Page 38
a) Module Pricing is the easiest to calculate. One takes the price for each
module selected for purchase and adds up the total. Sometimes there are
price breaks for certain groupings.
b) User seat pricing can be based on one of the models described below or a
combination of them:
• Named Users—those individuals licensed to use the system based upon
their specific name or function. Only those users, their replacements or
people logged onto their computers can access the licensed software.
• Concurrent Users—the number of users who are on the system at the
same time. The next person will not be allowed access to the system.
• Web Users—those who only access the applications via the Internet.
• Casual or Inquiry Users—those who make inquiries or print reports.
• Unlimited Users—an unlimited number of users at any given time
within the boundaries of the license agreement.
c) Revenue-base pricing is based upon the annualized revenue of your
company. The price can incrementally increase each year when annual
revenues are compared to the base revenue at the time the product
was sold.
d) Hardware model numbers were used years ago. Now with the increased
flexibility of hardware options, such things as CPU power and database
size are used. This is an attempt to approximate transaction volumes.
Questions: • Is your hardware sized just for the business package you are purchasing
or does it run other applications that should not be considered in the
pricing model?
• Have you calculated on a reasonable basis what your number of named,
concurrent casual or Web users are?
• What happens if you exceed that number during a peak period vs. on a
regular basis?
• Is the revenue of the company which licensed the software representative
of users of the software package or are there many users of other
packages included that should not be?
38
section1.qq1 10/15/01 4:24 PM Page 39
4) Terms of Payment. There are wide variances in the terms of payment for
software licensees. We have constructed a table with the major options below,
which all favor up-front payment. The percentages indicate the amount of the
software license that is paid upon the event occurring:
Most contracts start with column two and move during contract review, at
most, one column to the right. Don’t expect the best column, we only see it
a few times in every hundred contracts.
5) Warranties. Most software has limited warranties at best that state the
software will perform substantially in accordance with documentation for
a period of 90–180 days and then clearly states there is no fitness of
purpose guarantee.
6) Refunds and Remedies. In practicality, very few refunds are actually given to
the customer once the software vendor has your money, unless an arbitrator
or judge rules on your side.
Question: Have you negotiated a fair software license where neither party feels taken?
39
section1.qq1 10/15/01 4:24 PM Page 40
Question: When will you actually start using maintenance/help desk services?
3) Base Price Used. Which base software price is the percentage maintenance rate
applied to?
• List price on the date of purchase.
• Discounted price on the date of purchase.
• List price for the year in which maintenance is paid.
• A negotiated base price.
4) Uninstalled Modules. What happens if you purchased modules but never install
or use them? Must you pay maintenance on them for the next 5-10 years?
5) Hours of Support. What are the daily, weekend and holiday hours of support?
6) Escalation. Is there escalation and different response times offered based
upon the severity of your problem?
40
section1.qq1 10/15/01 4:24 PM Page 41
41
section1.qq1 10/15/01 4:24 PM Page 42
13) Change Control. All changes to project scope should be done in accordance
with a defined change control process.
14) Issue Resolution and Escalation. There should be an issue resolution and
escalation process among various levels of management that explains what
to do when things go awry.
15) Rates by Consultant Type. A rate chart by type of consultant should be
presented and adhered to for the duration of implementation.
16) Payment Terms. Payment terms should cover terms plus the discount
percentage applicable.
Question: What else do you need to add to your specific implementation vendor contract
to clearly communicate your expectations?
This agreement will apply if you desire to have your business system managed
offsite rather than on your own premises. (See Chapter 9 on ASPs for further
descriptions.) Among all the pointers that could be given for this area, six unique
ones stand out:
42
section1.qq1 10/15/01 4:24 PM Page 43
43
section1.qq1 10/15/01 4:24 PM Page 44
SUMMARY: We have reviewed a number of the more common business issues that need
discussion and resolution during contract review and negotiation. We have not
covered many of the legal issues that may arise. Use your attorney for those matters.
We usually suggest using a competent software license review firm first, then have
your attorney make the final review. Your goal should be to create options and reach
agreement where both parties feel understood and neither party feels taken. The
contracts need to be fair. Satisfaction comes from shared expectations and
predictable fulfillment.
44