Determining Value-Based Fees for Software Projects

Question

There is another post on here "How to quote project development cost" where user SpliFF commented:

This is not a labor market, you are selling knowledge and solutions. Some solutions are better than others. 10 hours of failing is worth much less than 10 hours of building a killer app. You need to stop thinking about time and costs and focus on the value of the outcome. Compare it to products of similar value. Slapping an arbitrary 40% on 'project cost' to determine value is ridiculous.

While I generally agree that Value-Based Fees (a la Alan Weiss) are the best way to charge and get what you're worth as a consultant, I don't know how well this approach translates to the software development domain.

How do you determine value to the client without spending inordinate time performing requirements discovery and analysis? How do you manage change requests in a Value-Based fees approach?

Answer 1

Interesting question.

In value based you would charge the customer:

• per transaction
• per application processed
• percent of savings ....

In this case the customer is paying for something being done, not how it is done. So if the customer comes afterwards and says "this form should be a different color", then this would be a change that would be charged on time and materials.

Answer 2

Mark

Software development is one of the key areas to be adopting a Value-Based Pricing approach -as you indicate following the Alan Weiss/Ron Baker et al model.

I think you've almost answered your own question here. You DO need to discover a lot of information before you can suggest a Value Based fee but not, I would argue, specifically to do with requirements, and not in a time consuming manner.

There are efficient ways of finding out as much as possible about the client's PROBLEM and the circumstances surrounding it. Then you can go through the remaining stages of the 'Sales Conversation' and present your options (see A Weiss) and then the associated fees - all in the space of say an hour or two.

I'm guessing that your 'value (to the client - not the price tag) package' options might all start with a research project to work with the client to discover and agree the detailed requirements of a software solution to the problem.

Having agreed (in writing) with the client the scope of the 'value package' they have selected and your FIXED fee, any 'Change Requests' can be simply dealt with.

If it's within the scope of the project, it gets done for no additional fee! If it isn't, then this is a separate chargeable project! You will be asking the client if they would like you to stop work on the current project while you complete the new one, or whether they'd like you to finish the current one first. As Jonathan Stark (another Value Based Pricing disciple, from the software world) points out, you can only run one project with any one client at any one time!

I hope this is of some help.

David (@davidwinch on Twitter)

Answer 3

I don't have the book handy to reference it, but I know that there's a pretty large section on how to develop fair contracts in Implementing Lean Software Development: From Concept to Cash. The book goes over the shortcomings in the traditional contract as it applies to software (or any uncertain system, really) and suggests some alternatives.