Margin Analysis during Quotes

The single most important thing to know before creating a quote is the actual number of hours that will be needed to complete the development and implementation. (You also need to know the cost of anything else that is needed to complete the project for the customer.) I have already discussed all of the various factors to use when finding those hours. Note that any contingencies due to risk should be recognized and included in this initial cost evaluation. If there are risks and associated costs that would be present if they become actual issues, then they should be factored in as costs at the initial cost evaluation.

The project manager has the ultimate responsibility for the accuracy of the estimated cost of the project.

Once you are confident that you know the actual costs of developing the solution, you then need to consider the other factors involved in developing the actual price that you quote the customer.

Let us look at those factors.

First of all, each company should have a business model that they have developed indicating the profit level that they expect from their custom software projects. One such marginal profit level that I worked with at one company is 50%. In other words, when you made an estimate for that company, you took the estimated cost and doubled it and used that value as the estimated price to charge the customer. In the simplest scenario, you simply apply the business model multiplier to your costs and – voila – you have your price quote.

A second factor to consider is whether or not some profit will be made from the sale of equipment (hardware) or other things such as service that would be associated with the use of the custom software. Based on my own personal experience, there are tines when this is important.

One company for which I managed custom software development projects made 90% of its revenue and well over 90% of its profit from equipment and not from software. At that company I worked on some projects where $100,000 software costs could produce $1 million of hardware revenue with profits well in excess of $100,000. In such cases, a good business argument could be made to “give” the software away as sort of a “loss leader” since the company ends up with a net profit. (Hardware profits are also much more reliable than the profits on custom software development projects.)

A third factor is that for custom software, often the amount of revenue received for enhancements can far exceed the initial development cost. I have seen estimates stating that, in many cases, the customer’s cost for the initial software development may be only 10% of the total investment in that software product over the life time of that product.

That’s been my own experience as well. I worked for a few years as a self-employed consultant. I wrote a program for a consulting (head hunter) firm to do their payroll. I charged $2000 for that initial development. (It was a very long time ago.) Over the next four years I billed that customer for more than $50,000 for enhancements to that program. It ended up doing much more than payroll. But in that case the ratio of the initial software development revenue to the final revenue was a bit more than 1:25.

While I don’t believe that it makes sense to give the initial software away, you should still consider the extent to which it can be expected to lead to future revenue due to enhancements.

The reason that the customer bought custom software is to have the software support the way that they run their business. Over time businesses change the way that they run. The extent to which the software that you developed supports their business is the precise extent to which the software will have to be enhanced as the customer’s business changes and, hopefully, grows.

This is a key consideration. Back when I was self-employed, I initially did a lot of things to find new customers. Eventually I found 33 customers for which I did billable work. However after about two years I found that I could keep busy by merely fielding requests from those customers for enhancements to the software that I had developed.

It’s important to remember that because it is custom software, the only vendor that the customer can effectively go to for enhancements is the original developer. Even if the customer has a copy of that source code (a subject that I discuss elsewhere) the original developers are the ones who understand it best. So there can be little doubt that they can do the best job of modifying it. Even if the original quote was competitive, quotes for enhancements won’t be.

The extent to which this should be a factor is dependent on the extent to which the software is used on a day-to-day basis. Things like ERP programs are constantly used and will be undergoing constant enhancements. At the other extreme a program that is used rarely, possibly as infrequently as once a year, and then only affects a small group of individuals probably will have very few, if any, enhancements added.

A final consideration is whether a particular customer has an idea for a software program that other customers might be interested in. This should only be a consideration if the vendor has a good marketing department that can do legitimate research into such issues. But in such cases working with a customer to develop a very useful program would make developing a similar piece of software for other customers much easier. In my experience this is the most problematic consideration. But it deserves discussion.

In summary, when establishing a price for a custom software solution the process should be:

Define the requirements in detail.

1. Develop the best possible cost estimate, factoring in risk and anything else that might affect that cost.
2. Apply the default profit margin.
3. Consider lowering the margin if extra revenue for hardware and service sales is likely.
4. Consider lowering the margin if the software is going to be a key piece of software used constantly by the customer. In that scenario the customer will probably pay much more for enhancements over time.
5. Consider lowering the margin if the software being developed has generic features that might make other customers interested in using something similar. This is the most problematic consideration and should only be done if the software development company really has a good marketing department.

All of the considerations should be well documented. It is good to keep a history of such quotes and use them to help evaluate other quotes that will be made in the future.