June 21, 2013Doug Hadden
Doug Hadden, VP Products
The answer is far more complex than the question. FreeBalance enjoys a significant competitive advantage in Total Cost of Ownership (TCO) and price flexibility in software licensing.
Before I lay out the answer of value-based pricing, here are the parameters:
- Scope: the public financial management scope that many vendors call “modules” because you don’t want to pay for modules you won’t use
- Breadth: the functions or components within those modules because you don’t want to pay for unused functionality
- Depth: the user behaviour within the functions because you don’t want to pay for functionality that some users are not using
The enterprise software market has set expectations for pricing models. Frankly, most of these models are designed for the benefit of the vendor, not the customer. The difficulty with the FreeBalance model is that there are so many options in order to align with real use and true value. We made the decision to sacrifice simplicity in pricing models to achieve value alignment.
First Important Consideration
Many studies show that the software cost may not be material to TCO(We look at this as financial sustainability – the ability for a government to afford maintaining and upgrading the software and, most importantly, leverage the software to enable reform and modernization)
I’ve averaged many studies that show that software represents 20% to 25% of initial costs. There is sufficient evidence to show that implementation costs are more relevant where these costs range from a 1:1 services to license ratio in the private sector to from 3:1 to 15:1 in the public sector with examples where services significantly exceeded other costs. There are also risk costs with average ERP implementation variance of 2 and 4 months over schedule in one study, 230% of schedule in another study , where up to 80% of ERP exceed time and budget estimates in a third study. TCO is a critical concept in GRP because of the high risk of IT failure in the public sector and the high failure rate of ERP in government. The monitoring of upgrade costs, employee retention, customization burden and electricity draw is an early warning system for IT failure. And, TCO tells you whether your GRP project is financially sustainable. There’s more on TCO in our good practice document.
Towards Value-Based Pricing
I’ve done a lot of research into software pricing models in the past. The “holy grail” is perfect alignment between pricing model and value. A 2004 analysis by analysts IDC, The Future of Software Licensing: Software Licensing Under Siege, was a wake-up call in the software industry. To be very clear, we take pricing trends seriously. (My analysis in 2005 consisted of 129 pages with a detailed appendix of almost 500 pages. My current pricing sub-directory on my computer has almost 1,000 files.)
The typical approaches used in pricing include:
- Lower cost per user through software volume. The premise of this model is that each new user in an organization has less utility from the software. A sliding scale of price per named user is typically used. The problem is that this method is often leveraged by vendors to sell “shelfware” based on potential long-term use that often never happens. And, customers pay maintenance fees for shelfware.
- Power of the servers being used. The premise of this model is that the burden on computing hardware represents a proxy for how the software is being used. This is a model that I’ve never liked because customers are penalized by purchasing equipment designed to enable growth. Much of the power of the data centre is unused. In the age of virtualization many servers are used for multiple applications. This unnecessarily increases costs. And, the formula for calculation is so complex and dependent of specific equipment that it is almost impossible to maintain. And, who is to say that levering more storage or memory for applications has anything to do with value?
- Cost per transaction in some formula. The premise of this model is that organizations receive some utility based on the number of transactions consumed. The problem with this model is that pennies per transaction can add up to significant costs. Other traditional models are often less expensive.
- Budgets or employee numbers. The premise of this model is that organizations benefit from software based on total budgets or total number of employees. The total budgets idea is crude measure, especially in government because some organizations have high volumes of small transactions while others have low volumes of large transactions. The number of Full Time Equivalents (FTE) is a good measure for the value for human resources software but is somewhat crude for other financial applications.
- Population size. This has not been used to my knowledge in government pricing. Population size might be a good proxy except that more developed countries with similar populations to less developed countries are likely to gain more utility.
Our journey to value-based pricing
I was reflecting on the product licensing model that I developed in October of 2007 and was live in the first release of the new FreeBalance Accountability Platform in June of 2008. One of the objectives was:
FreeBalance may need the flexibility to support other licensing methodologies such as concurrent licenses. This licensing method is not supported by many vendors, although there seems to be some RFPs that expect concurrency. There seems to be a way to combine component-level control with a hybrid of concurrent and named users.
The thinking at the time was that we needed to support more granular licensing and concurrent licensing because the user profile in developing country governments is far different from the commercial space in developed countries. The utility curve shows such a drop that many experts think that custom-developed or locally-produced software should be used for more occasional users. That’s because traditional pricing models are inappropriate. Our model is different.
The FreeBalance pricing model Exposed
The FreeBalance pricing model consists of five factors:
- The modules to be used where different modules have different value.
- The underlying component functionality to be used because we can license in a very granular fashion.
- Licensing options that combine site license (based on FTEs), named users and concurrent users based on what is most appropriate to the government. Subscription pricing is also available based on a cloud or a shared services model. And, pricing per user and per FTE drops based on volume.
- User profile licensing for named and concurrent users based on professional (can reconfigure), power (all functions except configuration), data entry, approval (such as manager functions) and reporting.
- Consideration for the re-use of underlying functionality across multiple applications
These 4 elements combine the scope, breadth and depth requirements to achieve maximum value for our government customers. Models can be combined.
What does that mean in real life?
We keep track of price quotations that were publicly disclosed in Request for Proposal (RFP) processes. That enables us to compare prices with competitors. Most of these public proposals were for turnkey systems that include hardware, software, implementation, training and maintenance. The scope for these proposals differs. I analyzed the scope of these proposals where:
- 1 unit = smaller module such as budget preparation, asset management or procurement including installation and 5 year maintenance with required middleware
- 2 units = larger module such a complete financial management with treasury or human resources with payroll including installation and 5 year maintenance with required middleware
- 1 unit = complex “country-specific” functionality such as custom reports, custom interfaces or support of an unusual language – where multiple integration points, particularly with custom software can mean as much as 4 or 5 units
- 3 units = complex customization for functions such as revenue administration
- 1 unit = for servers required to run the software
- 1 unit = all workstations required to run the software
- 1 unit = unusual additional support (i.e. set up and operate a local help desk)
- 1 unit = extra training and capacity building (i.e. rather than “train the trainer” approach)
- 1 unit = additional middleware such as a package of virus protection, systems administration, help-desk and load balancing
- Doubling the number of units when the requirement is for national and sub-national levels.
So, an RFP that includes budget planning, financials [including accounting, treasury, bank reconciliation, commitment controls, cash management], civil service management [including HR, payroll and travel], fixed assets, custom reports and servers with Spanish and English only at one level of government is (1 + 2 + 2 + 1 + 1 + 0) * 1 = 7 units.
The analysis shows that the average unit price per 1,000 population across all vendors, including FreeBalance, has been $140. The average unit price per 1,000 population for FreeBalance has been $103.
A country or province of a population of 5 million people with the scenario above will have average quotes from vendors of under $5M +/- 30% with the FreeBalance price around $3.6M +/- 15%.
An analysis of Integrated Financial Management Information Systems (IFMIS) by USAID found “from successful installations, a rough guideline for estimating the cost of installing the complete hardware and software platforms for a comprehensive government IFMIS is to estimate about US$6 per capita.” Our figures show that this estimate might be valid for the total cost across many years for all possible modules where many governments are acquiring multiple modules from different vendors across many RFPs.
There are some other key observations to consider:
- The analysis does not include the “breadth” of functionality within modules where the requirements for “asset management” in one country could be more complex than in another.
- Some of the proposals include options of fully bespoke systems, something that can have a very high risk.
- Some of the proposals were not compliant with the government requirements. These tended to be at the low range of quotes.
- The number of users per module differs to where it is not always proportional to the population. Some governments roll out to core users only in the initial 5 year period.
- A World Bank analysis of IFMIS suggested that the period required to fully implement systems is 6 to 7 years yet all of the RFPs were for 3 to 5 year periods.
- The World Bank IFMIS cost average, not including Russia, was $12.6M ranging “Typically, the range of costs is between $610k (Cape Verde) to $12M on average. This broad range reflects the differences in the focus of the systems (Treasury vs. FMIS), as well as differences in the size and complexity of projects. Generally, the average total cost of completed projects (including advisory support, training, project management, etc.) was roughly $25M—although this figure is muddled by the differences in scope of the projects.”
- The World Bank analysis found a range in cost of about $15K per user where the cost per user is reduced based on volume.
- A World Bank IFMIS analysis from 2003 found an average cost of $12.3M at that time.
- Cost overruns and late delivery is typical when Enterprise Resource Planning (ERP) software is used rather than Government Resource Planning (GRP) like FreeBalance. The RFP analysis covers quotes rather than the actual price. For example, in an African government, the quote for ERP was for under $24M but the actual price is expected to be $42M.
- Governments rarely provide sufficient information in RFPs to support our granular pricing method that can save money.
- Governments rarely request concurrent licensing or site licensing that can also save money. In 2004, Gartner Group predicted that “Concurrent user pricing will be virtually extinct by 2008 (0.8 probability).” Yet, Gartner estimates that organizations “can reduce required licenses by 50-75% when using concurrent versus named/dedicated licensing.” That’s why we support concurrent as an option.
- The per-unit cost is slightly higher in countries with a lower population. This makes sense because risk tends to scale incrementally lower based on the number of users.
- Price discrimination is used by many vendors who try to achieve the maximum possible price. (Lower cost per user based on volumes is considered second degree price discrimination. The maximum possible price is the first degree of price discrimination.) It should be noted that some government organizations have different implementation risks because of capacity, corruption and lack of clarity on RFP requirements. So, “price discrimination” is not as nefarious a phenomenon as it sounds.
- The cost for ERP systems, in our analysis, is almost twice the cost of GRP. The total cost of so-called Tier 2 ERP tends to be less than Tier 1 ERP. (We don’t consider FreeBalance to be ERP because we focus on government rather than multiple enterprise vertical markets. It’s clear that FreeBalance and the two major Tier 1 ERP vendors are the Tier 1 providers for government IFMIS systems in developing countries.)
- ERP systems are designed for multiple “vertical” markets. These systems are often built on legacy client/server software including proprietary software languages. This generates the need for more computing hardware to support requirements with a web to client/server translation layer, more code and more database tables.
- The increase in annual software maintenance fees by a major ERP player is a disturbing trend for customers whose TCO can increase over time.
- ERP vendors have proprietary middleware. These vendors often tactically reduce the cost of this middleware in RFPs because of the strong competition from open source vendors.
What did I learn from my 2005, and is it relevant today?
In my May 2005 analysis that I’ve been reviewing, I made the following observation about what I called the “pricing con”. There’s what vendors claim is the average starting price. This price tends to assume that all sorts of functions are missing. There is the true price of what it costs to get everything working to your satisfaction. That can be orders of magnitude higher although many vendors are prepared to discount software licenses to preserve services revenue.
My analysis of price points in developed countries, eight years ago found that the average per-user price for licenses was:
- Core financial (accounting, commitment management, reporting) was $4,235 +/- 35%.
- Budget preparation and analysis software was $2,199 +/- 45% (there is a lot of variability on budget preparation from simple spreadsheet plug-ins to software, like FreeBalance Performance Budgeting, that handles MTEF, scenarios, multiple versions and support budget transfers during the year).
- Performance management and reporting tools was $1,149 +/- 60% (because of major functionality differences in products.)
There was insufficient information to make any conclusions about Human Resources software at that time. My sense is that prices have not changed significantly in the past 8 years – functionality has tended to improve at a similar or slightly higher price. Subscription pricing has become more common today. These prices, of course, did not include TCO.
How do we achieve this high degree of price flexibility?
The FreeBalance Accountability Suite is built on a modern component-level Service-Oriented Architecture (SOA). This enables us to re-use underlying components across multiple applications and to license based on these components. (These are typically called “business objects” but we call them “government entities” because we’re not in the “business” market.)
We leveraged SOA in the design of the licensing module so that we could support granular pricing and multiple pricing options. Adding licenses was also facilitated through the use of single license key.
This approach enables us to arbitrarily assemble underlying components to meet government needs. We package these components in what we call: modules, sub-modules and add-ons. This is used to conform to expectations set by enterprise software vendors.
So… what is the FreeBalance Price?
To be very clear, our salespeople are not being coy when they suggest that the answer to the question is complex. There are many factors involved designed to better align price with value. I hope that this provides enough information to estimate the price for a GRP system from multiple vendors.
You will need to analyze your user requirements if you want to know the FreeBalance price for your unique situation. This includes a profile of users by role (professional, power, data entry etc.) and determining whether concurrent licensing makes sense in your situation.
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016