Project Selection Process S300

S300 - Negotiate Terms with Vendor(s)

DEFINITION

Negotiate terms with the preferred vendor(s).

SUMMARY

The team should participate  where possible in the finalisation of the details concerning the software modules and services required, including  the negotiation of best possible terms with the vendor(s). This will involve price, service levels, and the precise components/modules to be acquired.  This process does not include the legal clauses and conditions which are dealt with in Process S310.

PATH PLANNING GUIDANCE

This process is optional.  Negotiation is normally required, but it is optional whether this involves the Application Software Implementation  project team.

DEPENDENCIES

Prerequisites (Finish-Finish):

• Agree final marks and issues (S230)
• Benchmark (if required) (S240)
• Prepare and agree Selection Report (S250)

Dependent procedures (Finish-Finish):

• Agree contract with preferred vendor(s) (S310)

RECEIVABLES

• vendors’ proposals as modified by any subsequent correspondence
• reports / questionnaires from vendor demonstrations
• report from Package Fit tests (if any)
• findings from the final evaluation of marks and issues
• findings from Benchmarking
• Selection Report

DELIVERABLES

• Agreed terms for the acquisition and support of components of the preferred solution

TOOLS

• Guidelines: Software Contract Checklist

DETAILED DESCRIPTION OF TASKS

Note that this process concentrates on the negotiation of terms with the vendor(s).  The agreement of the detailed contractual clauses is treated as a separate issue in Process S310.  This is because it is often conducted by specialist staff within the vendor and client organisations, and is often performed after the details have been negotiated in principle.  It is not normally appropriate for project team staff to participate in the legal aspects of the negotiations.

Important note

When negotiating or discussing the details it should always be clear that the statements made are not to be considered legally binding until the final agreement of the formal contract (see Process S310).  Expressions like “in principle subject to contract” may be used in any written communications.

About negotiation

The project team may participate in the agreement of detailed terms with the vendor. It is proper and reasonable to do so, because the team has the best knowledge of the actual needs of the project and the client organisation.  Note that this excludes advice concerning the precise format of the contract.  Contract negotiation is a specialist skill and the precise wordings may require legal advice.

Good negotiation depends upon the skills of the negotiator and the tactics employed.  Most vendors are used to negotiating commercial deals with their customers even where they claim to have standard prices, terms and conditions.  It is not recommended that any participant act dishonestly to gain an advantage during negotiations, but it is often best to conceal or manipulate the truth!  Remember that there may well be future occasions upon which the same people need to agree deals and it is not helpful if there has been unscrupulous maneuvering in the past.

It is usually a good idea to hold open more than one possible solution until a satisfactory deal has been reached.  This will ensure that the client organisation does have a fallback position and it can lead the vendors to negotiate in a competitive atmosphere.  Never be afraid to ask for a discount.  Note that discounts in excess of 50% have been agreed with some vendors whereas certain others refuse to offer any reductions in price in any circumstances.

Bargaining with the vendor should be done in good faith, avoiding any unreasonable demands.  Negotiations should be done only with a vendor representative who has the authority to bind the vendor.  It is important that the client enter into a good contract, but since the vendor should become a long-term business partner, the contract should be fair to both the buyer and the seller.

Although the project team may advise and participate in the negotiations, it is important that all parties understand that the ultimate agreement must be between the vendor and the client organisation.  Full agreement of the project sponsor and the key decision makers of the client organisation will be required.

It is recommended that several people participate in the negotiation team, for example, including the client sponsor, IT manager or lead analyst, the related user department manager, the client’s attorney (specialising preferably in computer contract law) and the purchasing agent.

Oral promises should be documented and included in the contract.  The vendor’s proposal should be attached to the contract., and its details should be made part of the contract (unless superseded).  The final contract should clearly specify all costs and payment terms.

It is important to follow any formal approval procedures the client may have and to seek consent through regular channels.  The process may also include special approval forms (e.g., Capital Expenditure Request) that are unique to the client organisation.  “Shortcutting” the client’s internal processes may damage the Consultants’s image with the client and may create an excuse for assigning blame if difficulties arise later. If the client has no formal approval process, sufficient documentation should be prepared to ensure that client management can comfortably approve the evaluation process.

If the existing hardware is being replaced, the client may request the Consultant to assist with negotiating quotes from used equipment resellers.  Because of rapid changes in technology, used components generally have little more than scrap value.  Also, prices quoted by resellers may vary greatly within a very short period of time.  Trade-in options sometimes provide the client with an attractive alternative.  If possible, obtain quotes early from the reseller and try to “lock-in” the price with a “pick-up” date after conversion.

In the case where systems are being implemented in more than one country, the vendor’s pricing structure may differ between country.  It may be valuable to assess the best country to purchase the software from.

Points to be negotiated

There are many aspects to negotiating the terms for the supply of the preferred solution.  The project team should examine all aspects of the proposed solution to make sure the full arrangements and their consequences have been considered.  An example list of contractual considerations may be found in “Guidelines: Software Contract Checklist”.  Note that this is only intended to suggest areas deserving consideration.  Specialist legal advice should be sought as appropriate.

The Software Contract Checklist is a list of issues that the Consultants may wish to advise the client organisation about when assisting in software contract negotiations.  The checklist may also be useful in determining areas where the client's attorney could benefit from the Consultants technical expertise.  Since each engagement is unique, the checklist may not include all issues that should be considered, and the  practitioner may wish to tailor the checklist as an early step in the negotiating process.

The following table shows a number of common negotiating issues and discusses some of the tricks or catches that should be noted.

Consideration	Comments
Price	Different components may be priced in different ways.  Typically there are one off payments and/or regular payments.  Most vendors will agree to discount their prices.  Note, however, that whilst it is easy to focus on purchase price, the initial payment may be a small component of the total costs of the system and it is wise to negotiate the other details as eagerly.
Recurring charges: rental charges / licence fee / maintenance charges	Most hardware and software items have regular charges for their use in addition to the initial “purchase” price.  These are often calculated as a percentage of the full quoted price, which means they are not automatically discounted if the purchase price is discounted.  It may be worth negotiating discounts separately (although vendors are usually keen to defend these charges as it is their main recurring source of income).
First year fees	First year recurring fees are often included in the initial payment.
Stage payments and acceptance	It is common to agree to pay initial payments as a number of part payments during the installation, configuration and acceptance of the system.  For example, it might be agreed to pay 25% upon delivery, 25% upon installation acceptance, 25% upon system test acceptance and 25% upon live running.  It may also be possible to negotiate a “free trial period”.
Acceptance	The precise format of the acceptance criteria and tests should be agreed.  Installation acceptance will normally only indicate that the system has been successfully installed - it is not a full test of functionality or suitability.  Note that vendors frequently have standard test data to demonstrate that the software is correctly installed and may resist any attempts to define other criteria.  This is not a major issue provided that the installation acceptance is not the final acceptance of the system.  Try to ensure that some form of leverage is maintained even after the acceptance of the system, for example a final stage payment upon successful system testing or live running.
Definition of where licensed items can be used, and by whom.	It is important to define the limits of the licence and support arrangements to be suitable for the planned methods for development and live running.  It is also wise to anticipate possible changes in the use of the system and either agree that these are allowed in the initial deal or agree discounts and terms that would apply.  In particular, check: external staff and consultants working for the client organisation can have access to the system the software can be run on development, testing, live, and standby computer configurations the system can be transferred to another computer or the existing equipment can be upgraded without undue difficulty and at a reasonable agreed price the system can be sold or transferred to another party, particularly, for example, in the case of mergers or demergers use by subsidiary or related organisations, in the event of the financial failure of the vendor, the client organisation will retain the right to use the software and have access to the source code.
Hours of operation and support	Support out of office hours may not be available unless agreed.  It may require additional recurring payments or it may be charged on an ad hoc basis.  Vendors will often agree to specific standby arrangement during critical times subject to additional payments.  This might be of particular value during the transition to live running.
Free training	Establish the amount and nature of any free training included in the purchase price.  Try to establish that this may be used at the team’s convenience.  Agree whether training should be provided at the vendor’s specialised facilities or on site.  Check that proper set-up time, preparation and training materials will be included.
Training facilities and pricing	Establish the prices and availability for additional standard training by the vendor.   Establish the scale of charges that would apply if the vendor were to be sub-contracted to develop specific training sessions for the client organisation.  (Note - it is not usually cost effective to use the vendor’s facilities for the eventual training of end-user staff.  Such training should always be customised for the specific needs of the organisation, eg their business procedures and their codes, and in line with the specific way the system will have been configured.)
Vendor support and consultancy	Support and consultancy from vendors can be of variable quality, particularly if the client does not have the choice of personnel.  In addition to agreeing prices and discounts, the availability of appropriate staff should be guaranteed along with guarantees of the overall quality of work performed.  If appropriate, negotiate the availability of specific known specialists.
Error correction, costs, response times	What guarantees does the vendor give concerning response times to correct errors?  What is the escalation process to ensure due attention is given to urgent problems?  Are there any costs attached to urgent support?  How long would it take the vendor to get a support specialist to the client organisation’s site?
Provision of routine upgrades	Are all upgrades free, regardless of size?  Are routine error-correction upgrades provided free of charge or at what charges?  Is there a need for specialist assistance to apply upgrades?  Are automated tools supplied to assist in the transfer of data between releases, and at what cost (if any)?
Technical performance levels	Try to establish solid undertakings regarding performance, based on the stated client organisation requirements.  For example, the client’s needs can be met by a specified hardware configuration, response times will be less than a quoted time for specified transaction types, disk storage space should not exceed a given limit. Note, however, that vendors are usually reluctant to do this as it is very difficult for them to make such accurate performance predictions.
Liquidated damages for non-performance	It may be possible to negotiate standard penalty payments for any failure by the vendor to meet the agreed contractual undertakings and standards of service, technical performance etc.  This should not, however, be allowed to affect the overall right to reject the solution and demand full compensation if it is wholly unacceptable.
Documentation	Which manuals and what other documentation are included in the purchase price?  What are the costs for additional  volumes?  What arrangements are there for the issuing of updates to the documentation, eg automatic or on request,  prices etc?
Other components which are necessary or recommended for the system	Establish how to meet the overall needs for the full business solution.  This will frequently involve other items which must be purchased or which are strongly recommended.  In some cases, the vendor may also be able to supply these although it may be appropriate to seek alternative quotations before agreeing to purchase the sundry items from the same vendor.  For example: hardware - disk and processor upgrades, etc software - compilers, databases, database tools, query tools or transaction processing software, etc communications - networks, PCs, terminals, terminal control software, consumables - disks, magnetic tape cartridges etc
Dates and plans	The availability and delivery dates should be clearly stated and agreed.  The vendor should agree to deliver components and services to meet any declared overall project plan.  (Acceptance of this and knowledge of the plan can affect to their liability to consequential damages should they fail to deliver.)
Attachments to the contract	It should be explicitly agreed (and noted in writing) that all statements made by the vendor, particularly those made formally in the proposals and further correspondence, will be considered to become part of the agreement unless more specifically excluded or overridden.  This may include the proposal, subsequent correspondence, supplied literature and advertising materials, meeting notes, vendor supplied documentation etc.
Modifications or custom programmed components supplied by the vendor	Any solution involving modifications to the packages or custom programmed components will deserve special consideration and negotiation.  Considerations may include: costs, support charges, delivery timetable, client’s right to monitor progress, client’s right to monitor quality, acceptance criteria, support, maintenance in future releases, ownership of any custom code developed, use of the custom built components in future releases of the main packages, warranties, guarantees, quality management, languages, tools used, escrow, etc.
Client’s right to amend source code	Is the client organisation permitted to amend the source code of the standard or modified components and what effect would this have on the support, maintenance and charges etc?  Will the unchanged elements be supported?  Should the client organisation maintain a pure version of the system upon which they would need to replicate faults before support would be provided?
Maintenance of old versions	Will the client remain supported and receive maintenance if they choose not to move to new releases of the system?  How long does the client have to move to the newer version?  How many older versions are supported?  How are the maintenance charges affected
Increases in charges / charges for new versions	Attempt to establish limitations or at least a policy statement regarding future increases in the recurring and ad hoc charges.  Establish what costs (if any) are attached to taking upgrades to the supplied package.  It is common practice for upgrades to be provided free of charge, but this tendency is becoming less normal with smaller cheaper software packages.