7 Thoughts on Value Pricing for Software Projects

The other day, I was having an initial “get to know you” phone call with a new coaching student. We are planning to work on a number of issues, but his primary interest is converting his consulting business from an hourly billing model to a value pricing model. Several interesting points came up during the call that I thought would be nice to share.

  1. You can underestimate just as easily with value priced project as you can with an hourly project. The difference is the fallout. Specifically, if I underestimate an hourly project, my punishment is angry phone calls, endless review of hours entries, running reports and billing statements... IOW, a bunch of administrative bs and fights with the customer.

    On the other hand, if I underestimate a value priced project, my punishment is... more development work. Guess what? I love development work. That’s why I do this job. Sure my profit margin is decreased, but doesn’t making $100/hr instead of $200/hr sound a lot better than arguing with a customer for an hour over a 30 minute hours entry?

  2. To really understand the difference between value pricing and hourly billing, I think you need to do at least one value priced project yourself. You need to feel the internal shift - the loss of the safety net. I believe that this shift will make you both a better developer and a better service provider.

  3. You don’t have to convert to value based all at once. And, it’s HARD to convert existing customers. Try it on a single project with a new customer first. Trying to reframe all of your experience from a value based perspective (“how would I have done all these deals with value pricing”) before internalizing the approach is recipe for failure.

  4. There are two numbers that you need to determine when bidding a value priced project: the cost to you and the value to them. So, when a talk to a client about a new project, I first guess at how many hours I think it will take me, and I multiply that by $200 to come up with X. Then, I guess how much it is worth to the client and I divide that by 10 to come up with Y. I then give the client a quote for the greater of X and Y.

    Success with this approach is dependent on the accuracy of the guesses, but if Y is significantly greater than X - say, five or ten times greater - then the risk is drastically reduced. The closer Y is to X, the more sure you want to be of your guesses.

  5. There is a difference between a fixed bid and value priced quote. Ultimately, both result in a static priced quote to the client, but fixed is based on a cost estimate to the developer and value is based on a percentage of the value to the client. Hence, fixed bids are almost always too low.

  6. Payment terms are intrinsically related to the way I practice value pricing. You could do value priced projects and take payment in installments, or in arrears, but I usually recommend against it. Rather, submit your quote with the most favorable terms (i.e. 100% up front). If the client balks - although I find that most don’t - it’ll give you something to concede in negotiations.

  7. I only price custom software projects on a value basis. I offer other services on the basis of time but the minimum unit of measurement for most of these other services is monthly. Also, they are fixed scope services that do not change much from client to client (i.e., ”productized services”).

More Info

For details about how and why to ask your clients for 100% payment up-front, check out this post - which was referred to as “life changing” by at least one reader!