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.
"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."
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.
|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.
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:
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:
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.
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