prev next front |1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 |12 |13 |14 |15 |16 |17 |18 |19 |20 |21 |22 |23 |24 |25 |26 |27 |28 |29 |30 |31 |32 |33 |34 |35 |36 |review

Often it is desirable to have two vendors selected as finalists for negotiation.  This will improve your position if one vendor becomes difficult during negotiations.

 

Often software is licensed by number of users or by number of sites (or some combination).  It is important to define these terms.  Development and testing users and sites are often not included in the costs but make sure this is spelled out.  When counting users, ask if they count concurrent users (users at the same time), active users (users who have been active within a defined period of time), or named users (everyone who could possible access the application).  You will have to understand these conditions and relate them to your usage pattern to calculate the cost.

 

Ongoing support costs will be significant and should be carefully negotiated.

There should be a specified cost and response time for dealing with problems.

Maintenance updates should be scheduled with a response time.

The rate for support is usually a percentage of the cost of the software.  Ensure that this rate is capped to prevent unreasonable increases in the future.

When you have open source software, it gives you more flexibility in dealing with vendors since you are not locked into a particular vendor and can choose a different vendor if one becomes unreasonable.

 

There should also be a specified rate for customization and modifications to the software.