A couple of days ago David Winch noticed me talking on Twitter about “Determining Value-Based Pricing for Software Projects”
Specifically I said:
While I generally agree that Value-Based Pricing is 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?
This apparently piqued David’s interest, so he posted a reply:
“Software development is one of the key areas to be adopting a Value-Based Pricing approach – as you indicate following the 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 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!”
This elicited further questions from me:
“Using the Value-Based approach, how does one deal with the “we’re a startup, we can’t afford that!” response to a proposal? Often I am asked to design/develop websites for clients, which in my opinion is pretty much commoditized at this point. While the value to the client could be extraordinary, the fact that there is limited price elasticity here is working against me. How do I value-price something that can be had at similar quality for a fraction of the cost?”
Once more David replied:
“I’d question ‘similar quality’! You are unique! Only you can deliver your project! I work with a web design colleague and we recently talked to a one-man-band about his first website. We didn’t ask his budget but I’d guess a few hundred pounds. After the full ‘Value Conversation’ based ‘Sales Conversation’ (which took us about 1½ hours) he agreed to a £4,000 fixed fee for an e-commerce site. Having seen what it would mean to him to have a website that sells, he found a way of getting the money to invest in the enormous return, and paid 50% up front a fortnight later!”
I responded with:
“How did you convince him to cough up the equivalent of US$8,000 when he could have easily gone with any number of hosted solutions for under $100/month? I suspect the value conversation took 15 minutes and the sales conversation took the rest?”
David’s response was to say:
“The Value Conversation is one of four ‘Conversations’ that make up the Sales Conversation, and mostly takes longest of the four. The skill is in helping the client understand for themselves the value of having the problem fixed. In this case we’ll help him achieve increased gross profits of over £100,000 per year with the new site . There will be additional (chargeable) work involved in driving sufficient traffic to the site, but even so he’s backing a winner at odds of better than 10 to 1!”