One of the biggest obstacles I’ve found switching to value pricing is offering a fixed fee for work that has so many unknowns.

As developers, we learn pretty quickly that no two projects are the same, each bringing its own challenges and nuances. (I’m sure this applies to other knowledge/service businesses as well).

It’s perfectly reasonable for a prospective client to ask “how much will this cost?”, but this can be a very difficult question to answer, especially in the early stages of a project where so much is unknown.

Nobody likes surprise invoices, or not knowing how much they will end up spending on a project. Whilst I always preferred to give a fixed fee — and did so in the early days — I soon switched to time-and-materials approach.

At some point, it seemed this was the only way to deal with increasingly complicated projects, unknown requirements, and scope creep (or, far more often the case, scope seep).

Hidden Time and Materials

I thought I had found a good compromise to a simple ‘hourly rate’ by using daily, weekly or “per-sprint” rates as a way to package up the time into small, fixed-fee units of work.

However, it soon became clear that this was just re-framing the problem, and would lead to the same questions from customers. “How many hours?” just became “How many days, weeks, or sprints?”

The underlying problem was that the fixed fees I was giving were still based on an estimate of time.

By pricing in this way, I was still stuck on the cost-plus model. The price a customer paid bore no relation to the value being delivered, and brought with it all the same problems as time-and-materials billing normally would.

It certainly did nothing to mitigate expanding scope and managing the unknown — but that’s the subject for another post.

Moving Back to Fixed Fees

There is no question in my mind that offering a fixed fee for work is better for everyone involved, but a fixed fee based on time is not.

So how can you offer a fixed fee, and still protect yourself from the dangers of run-on projects, scope creep and the unknown? It’s taken me perhaps a year to come to terms with the fact that you simply can’t. There will always be a risk in this type of work — it is the nature of our business.

Offering a fixed price means you are taking on that risk, but by doing so, you are adding value for your customer.

So if you are value pricing, you can and should charge a premium for offering a fixed price and removing that risk for the customer.

A Minimum Price

Even knowing this, though, there’s little doubt that determining a value-derived price is difficult — especially so in these early days.

Despite a conscious effort to avoid it, it’s all too easy to fall back into thinking hours and rates.

To help overcome this, I plan to use time-based estimates to give myself a baseline price. This will simply show the minimum level that my value-derived price must match for the work to be viable.

Aside: I am part-way through Ron Baker’s excellent book, Implementing Value Pricing. Ron introduces the idea of a reservation price, which takes this concept much further.

If the value to the customer cannot exceed the time-based estimate, then the work won’t be taken on.

For the work we do take on, the customer gets a value-based, fixed price (based on output), and I can still monitor the costs (based on input) to the business.

• Pricing based on estimated time is just cost-plus based pricing. A price should instead be based on the agreed value to the customer.
• A fixed fee loads the risk onto the consultant, but this in turn represents added value to the customer.
• Value pricing should ignore time, but in these early days it’s difficult to escape the mindset of hourly rates. For now, I’ll use my time estimates as the minimum value that must be met to take on piece of work.

Have you made the switch to value pricing? How has it affected your own business and the way you operate? Are you worried about making the switch away from time billing? Let me know by getting in touch.