The pricing model of a software application refers to the contractual arrangement between the vendor and the jurisdiction. It includes the application fee schedule, contractual terms and conditions, and vendor operational plans. These items together establish the financial basis of operation as well as define the scope of work to be performed. For the vendor, the pricing model must show that adequate revenue is received to perform the necessary maintenance, operation, and enhancement of the application. For the purchaser, the model must prove that adequate value is received for the work expected from the application. Even government-developed applications (Government Off-the-Shelf Software, or GOTS) have an underlying pricing model. Although the fee may be waived, the terms and conditions will be defined, including any plans for ongoing support.

It is important to review the model of a software application early in the selection process so that time is not wasted on evaluation if that vendor cannot support a pricing model appropriate for your jurisdiction. This guide will discuss the components of the model, assessment of viability, potential constraints of your business, and possible futures of application pricing.

Pricing Model Components.

"Ever since commercial organizations began to make use of computer systems, one area has been consistent in its ability to bamboozle IT professionals. License schemes and, more importantly, the cost and complexity of their administration, have been a cause of concern, bewilderment and frustration to every IT manager."[1]

Three elements of a pricing model are of primary concern: application fee schedule, contractual terms and conditions, and vendor operational plans.

Software is not actually"sold", but licensed; i.e., you pay for the right to use the software according to the terms and conditions of the license. As the quote above indicates, a nearly infinite variety of licensing schemas exists. Still, most fall into one of five categories (see table below). Any of these schemas may be appropriate if the ultimate price fits your budget and the conditions are acceptable.

Software may be provided without an up-front cost. So-called"freeware" may be work in the public domain (i.e., developed by a government entity) or"open source" (code available to anyone to build upon). Although there is no licensing fee, it is still important to understand the overall pricing model. What is the availability of maintenance? Are there plans for upgrading the functionality over time? Can you request additional features? Is there a plan to migrate the software to work on successive operating system upgrades? All the same aspects of viability should be assessed for the provider of this type of software.

The trend in industry is toward more subscription-style pricing. With the need for increasingly complex applications, many organizations find it difficult to budget the large sums required for traditional per-machine or per-user licenses. The ability to pay a monthly or annual fee can give you predictable costs as well as the freedom to upgrade to the most current software at any time. Additionally, because the vendor essentially must win your business again each subscription period, some users believe that this style of licensing results in better service.

Licensing per concurrent users is also more common today among smaller applications. Originally, only large tools (i.e., computer-aided engineering) were offered in this model. Today, several vendors recognize that an organization may be more able to predict the typical usage base (i.e,. 6 nurses and 3 appointment clerks per shift) than the total number of users or machines involved in use of the application. This model offers the freedom to provide access to many "casual" users who need to occasionally view or enter a record by only purchasing one or two additional user"seats."

Exhibit 3-1 provides more definition of each category, suggests situations that may best fit that schema, and includes an everyday example. Except for the subscription and volume categories, a maintenance or upgrade fee will be required in addition to the initial license cost. Usually, maintenance or upgrade fees cannot be avoided. Your license may require an active maintenance agreement to be valid (essentially a variation of the subscription model) or may require that you purchase all intermediate releases when you upgrade. Access to help or support organizations may be dependent on the existence of an active maintenance agreement. Count on a cost of 10-20% of the initial license value.

Category Definition Characteristic Situations Movie Example
Freeware Software is provided "as is" to third parties for little or no charge Single-user systems; small user base; unusual requirements Home movie
Flat rate $ per computer where a flat fee is paid to use the software on every computer on which it is installed Server-based systems; small user base; long-term potential DVD rental; view multiple places
Processing Power Cost is associated with the processing power of the computer on which it is installed. Larger capacity machines cost more Server-based systems; well-defined processing power requirements Purchase of the high-definition version of a movie on DVD
Per User $ per "named user" or per "concurrent user" Small number of users; undefined number of users; distributed users Attend a movie
Subscription Usage fee for a stated time period (per month, per year). Similar to a rental fee Constrained budget; short-term usage potential; lack of capital funding Rent a movie
Volume Price is set for an entity, location, or project. May allow deployment of an unlimited number of licenses as long as the limitation is met Changing user base; large user base Buy multiple copies at a warehouse outlet

Explanation of common licensing categories.
Modification or service pricing also should be considered. Most applications will require some customization. Some vendors restrict access to the code base such that you will be required to buy modifications from them. This policy does go a long way toward ensuring the stability and performance of the application (because the vendor can maximize those things), but can be costly if many changes are needed. The ability to add fields, users, or reports through a vendor-provided interface may reduce your need to pay for alterations. Always validate the appearance of and capabilities for such "user-defined" features. Many systems have provided these features as an after-thought; i.e., they are not well-integrated into the application or they require a software professional to navigate.

back to Top

Pricing Model Viability. If it sounds too good to be true, it probably is.

When considering an investment of the size and importance of a TB PM software application, it is important to pick a vendor that will be in business to support your future IT needs. Predicting the durability of companies is not easy, nor is it something you can learn from a guide like this. However, you can qualitatively assess the viability of a vendorĖs pricing model with the answers to a few questions:

  • What is the vendorís target market? Define the characteristics of the buyers - size, jurisdiction level, program area, geographic area. he more potential buyers there are, the more likely that a vendor can stay in business for the long-term.
  • What are the vendorĖs expansion plans? Look at the promised future functionality. The ability to extend the application to other areas (e.g., hepatitis, STD) and to other capabilities (e.g., billing) will increase the opportunity for the vendor to grow.
  • What is the vendor's history in expansion? Get a list of the releases or add-on capabilities that have been added to date. The ability of the vendor to add new capabilities will grow linearly, not exponentially. If they have delivered only one release in the past 2 years, it is unlikely that they will be able to deliver three releases in the next year.
  • What is the vendorís contingency plan? No one likes to think that their business will go bankrupt, but that is a possibility. A vendor should have their code "in escrow" with a third party. In this situation, the vendor provides a copy of the source code to an escrow agent (trusted third party). The vendor will establish an escrow agreement that specifies the conditions under which the code can be released to a licensee (customer), such as bankruptcy, failure to meet contractual obligations, failure to maintain the code, etc. The escrow agreement is a type of "assurance policy"; i.e., it provides the assurance that you will be able to maintain operation of the software regardless of the vendorís financial situation. Additionally, it is a demonstration of the maturity and strength of the vendor.
  • Does the cost for the application appear to be in line with other applications of similar size or complexity? A "magic bullet" for software development has not been discovered. If a vendor is charging significantly less than everyone else, a cash flow problem may arise that could affect their ability to deliver or even survive.
  • Does the price list for modifications or services appear to be in line with other applications? Again, a large difference (higher or lower) in price for these items may indicate an unsound pricing model. High prices for modifications may discourage the development of additional functionality. Low prices for modifications may impact the quality or timeliness of delivery. Either will ultimately impact the future of the application.
Combined with your financial advisorĖs appraisal of the company, this assessment should allow you to rank the relative viability of the candidate applications.

back to Top

Business Constraints.

Business constraints typically fall into two categories: financial and policy. Financial constraints beyond access to funds (limited budget) or types of funds (capital vs. operating) may include the inability to contract over a fiscal year, the inability to combine jurisdictions in a contract, or the need to have a visible product delivered. Subscription-based pricing may alleviate many of these problems. If all else is equal, consider proposing an acceptable pricing model to your vendor of choice. Smaller vendors may not automatically offer a variety of options, but be open to them.

Policy or regulation constraints typically come into play when considering the terms and conditions of the license. If you do not have a contracts specialist available, it is worth paying for the time of a legal consultation for review of the proposed license. Your advisor will have a longer list, but some of the things you want to know are:

  • Allowed usages (daily production, development of new business?)
  • Allowed users (are temporary staff and subcontractors covered? Subsidiaries? Branches?)
  • Modification possibilities (does this affect your maintenance or warranty?)
  • Future fees (is the license dependent on payment of maintenance?)
  • Third-party maintenance (can your IT outsourcer do the support activities?)

Whenever we buy software, we are making a judgment that the current needs of our organization will stay constant long enough to recoup the investment made in the application. At the same time, the environments that we work in, as well as the capabilities of the software application, are changing. It is important to select a vendor that has plans (and ability) to upgrade and expand the application in directions that will meet your future needs. To accommodate this, look for a vendor with a standard release cycle. New features should be available on a periodic basis (annual, biennial). You should have the opportunity to suggest changes through user groups or help desks. The likelihood of your change being adopted is never assured, but a good vendor wants to hear directly from the user community. If the ultimate choice comes down to a build vs. buy question, you should consult one of the many available guides to this type of analysis.

back to Top

[1]Bloor, Robin. "Treading the software licensing minefield" 25 Sep 2002

Skip Navigation | Assessment Guide | How to Get Started | Requirements Definition | Business Models | Support | Data Migration
Local Enhancements and Customizations | Costs | Funding | PHIN Compatibility | Decision Model Tool | Glossary | Results