Pricing Risk
One of the questions I hear the most, when it comes to pricing, relates to projects where there's a lot of unknowns. The worry, of course, is that you'll underbid a project and end up hating your life.
That's where pricing risk comes in. But the strategy of pricing risk comes in the context of several steps. So let me start there.
If the project has relatively decent requirements, is for a client you've already helped before, and suddenly pushes you out of your comfort zone, I regularly suggest three things.
1. Give yourself two days to create a tiny working prototype of what you do understand. This often gives you a ton more questions that you didn't have before you started. And it can help in terms of giving you questions to ask (either your client, or a person you call for help).
2. Find someone who is an expert or credible in the stuff you don't know as well, and arrange to have at least a single conversation – offering to pay for their time.
They're experts, so don't waste their time – which is why step 1 is critical (because you won't show up without even knowing what questions you have).
As you spend time with them, getting their take, you may either get everything you needed answered or you may discover many of the nuances you never knew to ask your client. This alone is worth gold. Because knowing what to ask reduces tons of risk.
3. With all your new questions, circle back to your customer and ask them. But more importantly, demonstrate three things: a) that you're honest about your knowledge (what you know and don't know), b) that you were willing to learn on your own dime, not theirs and c) that you were able to get to the heart of the matter relatively quickly.
Above all things – be honest
If you've been honest about your lack of specific expertise, but continue to have integrity, and demonstrated a quick ability to assess issues and risks, there's a good chance the customer will keep you on and move forward with the project.
More important, they will understand the risks involved, because you've laid them out (often in the form of unanswered questions) – and that means you can price risk into your proposal.
So what does it mean to price risk?
I find this enterprise example helps.
Let's say that you asked me to build a system for organizing college students into their dorm rooms. Let's say that you further asked me to hold $2 million dollars in liability insurance (in case the project went off the rails). Imagine that you also asked to pay in chunks, where each chunk would only be delivered after I gave you a portion of the code – and that you'd hold 10% of the project until it was all complete.
There are a lot of dependencies in that request, right? I mean, a lot of risky places where I might not get my money. But they're meant to protect my client from unknown risks.
But that doesn't mean I need to eat the risk myself, does it? Not if I know how to price risk. One of the things I can do is take the cost of mitigating those risks and embed it into my proposal.
So if the $2MM in liability costs me $100,000, that's a cost. If 10% is held until the end, and the project is $2MM, then another cost is $200,000.
So I take the cost of dealing with all those risks and I “price the risk” into my proposal. I add $300,000 to a $2 million dollar project – which represents an increase of 15% to the total.
Essentially I am passing the risk back to the client, in the form of project costs. When they complain about a higher quote, I would highlight the costs I have because I have to comply with their requirements. And that's when we negotiate that they won't hold 10% back, or that they only need me to hold $1MM in liability insurance.
Suddenly the project costs go down. But we've been sharing risk. It's not all on me. It's not all on them. And it all happens because I know how to price risk.
This applies to projects of all sizes
The same is true for a $100,000 project and for a $10,000 project. Pricing risk ignores the total size of the project – instead it focuses on understanding the cost of a risk and embedding it into a quote.
The other day I was talking to a freelancer who was skeptical about a project. We talked thru each of the risks and assigned them actual prices. Then we created the quote.
This is what he took to his client – and felt comfortable explaining. The customer was able to determine if they really wanted the project at that price, or if they wanted to talk over the various risks.
In this specific case, it led to a very productive conversation about the risk points. They eventually created a mutually agreeable proposal to work together.
In another situation, a different freelancer and I worked thru their situation and presented their client with a quote (for a project that the developer didn't really want to do). Until the quote, the client had been dogged in their request, ignoring the freelancer's honest suggestions that it wasn't a good fit.
The result of the quote was that it was higher than they expected (because of the risks we priced in) and they finally “got it”.
The Result
In both cases, the freelancers were happy. But more importantly, in both cases, their clients were treated with integrity, honesty, and the process helped build trust rather than erode it.
I can't tell you the number of times I hear clients tell me they basically paid a developer to learn on their dime – and hated the result. Those situations are bad for everyone.
This approach is just one of several strategies to deal with risk, but it's a good one to start with.