Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Contract Review Pointers and Price Considerations

Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

section1.

qq1 10/15/01 4:24 PM Page 37

CHAPTER 7

Contract Review Pointers and


Price Considerations
At the end of the software selection cycle you are presented with three to four legal
agreements to sign. They typically consist of:

A) Software License Agreement


B) Maintenance License Agreement
C) Implementation/Training Services
D) ASP Hosting Agreement

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.

A) Software License Pointers

1) Licensed Company. What company is licensed? The division, the operating


company or the holding company? You usually want the highest parent
company in your organizational structure.
2) Modules. Which modules are you purchasing? Do you need all of them right
now? Can others be purchased later as an option? Are there any special
discounts if you buy more now?
3) Software User Pricing. The four predominant bases for software pricing
currently are a) module pricing, b) user seats, c) revenue based and d)
hardware power.

37
section1.qq1 10/15/01 4:24 PM Page 38

Contract Review Pointers and Price Considerations CHAPTER 7

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

CHAPTER 7 Contract Review Pointers and Price Considerations

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?

B) Maintenance Agreement Pointers

The general themes that need discussion in the maintenance agreement


involve these six areas:

1) Start Date. When does maintenance actually start? A wide variance


is presented:
• Upon Signature or Delivery
• Upon Installation
• Upon Actual Use
• Upon Warranty Expiration
• One Year after Delivery Date

The latest possible date always saves you money.

39
section1.qq1 10/15/01 4:24 PM Page 40

Contract Review Pointers and Price Considerations CHAPTER 7

Question: When will you actually start using maintenance/help desk services?

2) Percentage Rate. What percentage rate of maintenance exists?

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

CHAPTER 7 Contract Review Pointers and Price Considerations

C) Implementation/Training Services Pointers

Sometimes this can be a frustrating area. Many implementation service agreements


are poorly written and basically take the approach “you need us, please give us a
series of blank checks, sign here.” This is not fair or appropriate for the amount of
time and dollars involved. Therefore, consider the following key elements of a good
implementation agreement:

1) Expectations. The most important item to start with is a clear statement of


what you expect the consultant(s) to do for you.
2) Deliverables. It is crucial to have a listing of deliverables and some mutual
understanding of the level of detail in the deliverables and their form
(written/oral presentations, etc.).
3) Hours Estimate, by Phase. The estimate should include their best estimate to
work through issues that have already surfaced, such as: customization,
implementation, creation of standard reports, etc.
4) Integration/Data Conversion/Testing. A good proposal includes two or three
paragraphs, which describe in general terms the technical approach(es) that
will be used to integrate the software with each key system necessary. Data
conversion describes the amount of data planned for conversion and the
responsible party to convert the data: vendor, customer or both. Testing
refers to the creation of a viable test plan in general terms so you have an
understanding of its role and how complex the phase will be.
5) Administration of Open Issues. This describes the technique that will be
used to document, and monitor the progress made, on issues.
6) Project Control. The vendor’s project manager should provide a weekly/bi-
weekly status report summarizing accomplishments, work planned in the
next period and issues requiring management attention. The vendor’s project
manager should also meet weekly with the project manager and core team
from your company to facilitate issue resolution, escalation and to monitor
and direct day-to-day project activities.
7) Professional Standards. The vendor should warrant all services will be
performed by competent personnel suitable for the tasks at hand and in
accordance with applicable professional standards.
8) Review of Personnel. You should have the right to review and approve all
personnel assigned to the job.
9) Quality Assurance Process. Regular reviews by a qualified party shall
be performed at each milestone to ensure the work being performed is of
good quality.
10) Training and Documentation. Understand what training and documentation
is to be provided so your users are able to use the new software solution as a
tool to help them with their jobs.
11) Travel Time and Costs. Determine what costs are allowable for consultants
who travel to your business sites and a clear declaration of what, if any,
travel time is chargeable to the project.
12) Roles and Responsibilities. The roles and responsibilities of both project
teams should be described in outline or chart form.

41
section1.qq1 10/15/01 4:24 PM Page 42

Contract Review Pointers and Price Considerations CHAPTER 7

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.

These 16 points will get you started.

Question: What else do you need to add to your specific implementation vendor contract
to clearly communicate your expectations?

D) Application/Hosting Service Providers (ASPs)

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:

1) Security/Disaster Recovery. What descriptions of security and disaster


recovery are given in the agreement? Do they meet your concerns?
2) Performance Review. How often do you sit down and review ASP
performance? Do you have the ability to revise the contract accordingly?
3) Third-Party Applications and Customizations. Is your ASP able to host
third-party solutions as well as fulfill any customization you may request?
4) Dispute Resolution. Will the vendor be assigning a customer advocate and
technical liaison to your account? What procedures are in place to report a
service or application problem? What escalation procedures are in place if the
dispute cannot be handled by the parties, e.g., mediation or arbitration before
legal remedies? Does the Application/Hosting Service Provider belong to the
Application Service Provider Industry Consortium (ASPIC) and are they
planning to voluntarily adopt the “ASP Best Practices and Guidelines for
Dispute Avoidance and Resolution” procedures?
5) Transition Assistance. If you terminate the agreement, or the ASP/Host
defaults or goes out of business, what happens during the transition and how
do they help you transfer to another service provider?
6) Service Quality Measurements. See table on the next page.

42
section1.qq1 10/15/01 4:24 PM Page 43

CHAPTER 7 Contract Review Pointers and Price Considerations

43
section1.qq1 10/15/01 4:24 PM Page 44

Contract Review Pointers and Price Considerations CHAPTER 7

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

You might also like