Pricing Software - Modest How To Guide
Friday, November 04, 2005
Pricing software products is not rocket science, but it is a mixture of computer science, software engineering, and accounting.
In order to understand internal software pricing issues, we need to first understand the costs of production: In almost all software development undertakings, the main cost driver is the work-hours necessary to complete the system.
In this case, a cost driver is an activity such that as the volume of the activity is decreased or increased, the cost of its action is decreased or increased, respectively. I.e. The greater the number of hours you spent engineering the product, the greater the cost.
While building a software product, it makes no difference what operating system you are working under (Windows or Linux); what architecture you are following (.NET or J2EE); what programming language you are using (C++ or Java). The underlying cost of your development effort will always be dependent on work-hours required.
So, knowing that the number of engineering hours is directly proportional to the cost of building software, how then, do you price a complete product? Either a shrink wrapped application or a custom application.
There are different ways you can arrive at the price of a product. The easiest method you can use is the "Cost-Plus" methodology: find the total cost of production, then add a bit more to the cost depending on the profits you want to generate.
The costs of manufacturing or building anything can be classified as Fixed Costs and Variable Costs.
Fixed CostsFixed costs are not affected by cost drivers - This means that you can be engineering four different software products at the same time and still only pay for one building's worth of office space, as long as all your employees fit in one building.
Fixed costs include, but are not limited to: rent of your office space, computer equipment, salaries of your executive team, and sometimes your own workforce's salary.
Variable CostsVariable costs are directly proportional to cost drivers. I.e. The more work-hours you require to complete a project, the higher the variable cost.
Determining either cost is a matter of classification: fixed costs are more in tuned with operational costs; variable costs, on the other hand, are attached to cost drivers. How then, do we determine the variable costs of building software in a software engineering environment?
In order to be as accurate as possible when determining variable costs you need a good understanding of
Requirement Engineering and must be able to generate accurate schedule estimates.
It all boils down to
what the system is supposed to do and
who will develop it. I.e. The more you know about both, the needs of the client and the skills of your team, you'll end up with more accurate estimates of variable costs.
Accuracy of estimatesEstimates are necessary in order to price application development. For example, I would like to know if a particular undertaking will be profitable or not. In other words, we need to calculate costs before the product is built; And the more accurate the estimate, the better the price will reflect the total costs and desired profit margins.
One of the biggest problem we face due to inaccurate estimates, aside from unhappy stake holders for receiving late software, is
free work.
We all know that there is no such thing as "free work" - It's similar to the conservation of energy laws: energy can be transformed, but not destroyed nor created - In the end someone has to pay for the "free" part.
For example, if the price of your product is based on your engineering department's estimate of 100 hours of work, and the production task is actually completed after 150 hours of effort, then the extra 50 hours are, essentially, "free" work.
Who pays for the extra 50 hours? The 50 hours of "free work" are eating up your profit margins. I.e. Your employees are being paid regardless of your tardiness (fixed cost). Somehow, your company is paying in lost productivity.
Using the past to predict the futureWhat about historical data to make estimates and pricing decision? This, in fact works very well, if and only if, you have accurate historical data.
If your company or software shop has been around for some time and it has been using the same work force from project to project, it has the advantage of having historical data or organizational memory of past performances. I.e. Knowing how long it took to complete a particular project, it now gives you a good reference to quote a similar project and be as accurate as possible.
Sometimes though, using historical data is much harder than we would expect, as most times, history is only available as an after thought on some software manager's memory.
This very reason, of enterprise amnesia, has led to the proliferation of formal documenting methodologies in new Software Engineering parlance. I.e. The CMM initiatives look very appealing, since the more you know and have documented your processes, the better you'll become at predicting costs and pricing.
As a recommendation (I'm sure we all do it), we should always keep metrics on past project's results in order to make comparison from project to project - Even if these tracking methodologies lack the sophistication and standards that CMM (or any other) gives you.
Note that there are other estimation methods that promise yielding accurate variable costs. You've probably heard of some of them: LOC (Lines of Code), function points, etc. They are all dandy and have professional looking formulas with different ratios you can use in different situations, however, who is to say that 10 lines of code in a week are not productive? In other words, be cautious of the usage of such findings - They are not applicable to every case.
Total CostAnd we've arrived at the simplified equation:
Total Cost of Software Development = Fixed Costs + Variable Costs.
Answering the question of pricing, becomes a matter of figuring the break even point, or the exact volume of "whatevers" you need to sell in order to recuperate your costs of production. In other words, how many "whatevers" you need to sell to make 0 (zero) profits. Once you know this number (I mean, who wants to generate 0 profits), it's easy to see how you determine profits above your costs: how many units to sell and at what price to generate 25% profits.
In most cases, you determine the break even point as follows:
Break Even Point = Fixed Costs / Contribution Margin per Unit, where Contribution Margin = Revenue per Unit - Variable Cost per Unit
With such a simple formula, you wonder why it is so hard to come up with a good pricing model for software.
The answer is painfully obvious: in Software Engineering we don't have a "unit" of software, nor do we know exactly how much our variable costs will be, as we are always working from estimates, as discussed above, which may or may not be accurate. The formula is there, it just need to be properly understood to apply it to a software product.
Will we ever be able to accurately price our software product to be competitive in the market place and, at the same time, generate profits in the long run? The answer is a big resounding
yes - Many companies are very successful software vendors, so it is possible.
In addition, new models of distribution allow new software companies to take a hit in the production cost, to be later made up in volume of sales and 0 (zero) distribution cost. I.e. Distributing software is quite cost effective via the Internet - Forget about paying retailers for a cut of revenues, for a measly 3D point of sale - Who buys software from a software retailer, anyway?
Total cost of production, then, depends on the
what (requirements Engineering) and the
who (The team implementation the requirements) - Everything else around product production becomes the
how (methodologies), which is part of your cost drivers - Which we now understand how to calculate.
Will the simplified total cost and break even point formulas work in every case? Probably. But you have too look at your overall operation to come up with all the fixed and variable costs - Do you need
help arriving at these costs within your organization or future projects?
Notes:
- In order to make this read manageable, I have ignored all market theory, as my intention is to bring out the internal issues of costing software products and not to discuss micro/macro economics.
- When we are discussing Fixed Cost, we need to understand that given enough elapsed time nothing will remain a fixed cost. Hence, a fixed cost is only relevant in a specified period of time or volume of whatever you are building.
Another important point to keep in mind is that determining what a fixed cost is varies from company to company.
- I'm not getting into the issues of proper Team Design, but you must realize that highly effective software development teams need good direction and leadership - Either as a Software Architect or Project Manager, someone has to estimate and schedule the work - I think, the task of estimation, though, is more appropriatly executed by someone with technical skills, rather than only managerial skills. I.e. It's the Architect's or Team Lead's responsibility estimate project schedules, of course, with the input team members. In more detail, estimate the overall time with the aid of each engineers specific task's estimation - The parts of the estimate, make the whole.
Comments:
I can boil it down. It is much easier than that.
Price your software as high as the market will pay. If your competitors charge $10,000 for a product and it costs you $100 to produce the same thing, you would be stupid to charge $110 for it. Charge $9,999.
The question I'm trying to answer here, is: how do you know it will cost you $100.00 to make your product, before looking at the market?
Though, internal pricing issues are not entirely separated from the market place, once you bring in all the outside influences, things change.
But, you bring up a good point: if the market is paying $10,000.00 for software that cost $100.00 to make, would you charge $110.00 for it or $9,999.00?
The answer is not so simple, as it appears.
The correct answer is: "it depends."
Look at what Microsoft did with Internet Explorer.
Microsoft spent millions of dollars creating the browser, and in the end charged 0 (nil, zilch, nada) in order to demolish the competition. Did it work? Ah, yeah - Netscape became a shadow of the original money days afther their IPO.
My point is that Microsoft still had to figure out how much they spent in creating the product. Did they take into account fixed costs and variable costs? You bet they did.
Did they price their software according to their costs? If you think with your "big picture" glasses on, yes, they did.
Did they get in trouble for doing so? Yeap - A few laws were broken.
So, pricing software is not just a matter of looking at the price the market will bear. Cost of production should be your starting point.
Ok, you can also look at the price first and then determine if you can build it within known cost constraints. I.e. If you know you can price your software for $10,000.00, how much are you willing to spend in order to build it. I.e. If it will cost you $9,999.00 to make and you decide to make it, I would fire you. On the other hand, if you figure out a way to build it for $100.00, a big bonus will await you at the end of the year - Better yet, quit your job and become a consultant to sell your secrets of creating cheap software.
BTW, if you say use Open Source Software to decrease your costs of production, you are on the right track - But, it's not the silver bullet everyone hopes it would be - Software support is still expensive, even if you don't pay licencing fees. Also, Gates will call you evil and anti-patriotic for using "free" software.
If you use OSS, they win. :) I don't personally believe so, as I use OSS software every day.