...figure out the price of what you're selling.

If you're going to set a fixed price for an item, the price should be set to... well... the cost of the item. Common sense, right?

If that's pretty straightforward, then the next obvious question is: how much should the item cost?

And that, of course, is the hard part. Certainly the cost of the item shouldn't be the cost of the item to you, because you need to make a profit. And the amount of profit you can make depends on what the market will pay, making the optimal price of an item the highest amount the market will bear coupled with the lowest cost-of-goods-sold (assuming you're optimizing for profit, which, for our purposes, we'll assume you are).

That's all fine and well in the physical goods space, and to a similar extent the digital goods space, where your production costs are relatively known quantities. But that all changes when you enter my world: the world of selling services.

Selling Services is Hard

At Bitmatica, we sell software design and development services, and the fundamental issue with keeping our company profitable is that our COGS scales with the needs of our clients. The requests of our clients are not fixed, and thus neither are our costs. In fact, as time approaches infinity, our COGS is almost 100% variable, with fixed costs (e.g. office space) accounting for fractionally nothing of what we incur.

Traditionally everyone in our space solves this problem by pricing per unit, e.g. $X per hour / day / week. That way our price and costs scale together, and profit remains stable. There's nothing fundamentally wrong with this model from a profitability perspective, and you can grow a very successful consultancy with it.

There's just one major issue, especially as you take on larger clients:

Companies hate paying for units of time.

Now, that's a very broad generalization, and is certainly not sweepingly true. But many large organizations can't mechanically manage a variable-cost model. Just because your costs scale per unit of time, doesn't mean that this business model is compatible with your customers.

Many, if not most large organizations need to know the total cost of a service, such that they can budget ahead of time, allocate the funds toward a purchase order, and disburse those funds to you. There is very little room for altering that after the fact, and especially when comparing multiple bids, it's impossible to compare Service Provider A's bid of $100,000 and Service Provider B's estimate of "well we charge $200 / hour and we'll probably spend at least 100 hours, but it could take up to 150, maybe more depending on additional requests."

"But this is crap!" I hear you saying, because anybody who's spent five minutes providing services for somebody knows that requirements change faster than you can write them down. When we used to talk about variable pricing, we used to quip to our clients: "Good news, if the requirements don't change, neither will the price!" And even if you do thoroughly scope everything ahead of time, you'll never be able to accommodate all foreseeable changes and requests -- or not without arguments that leave both of you feeling ripped off.

...or will you?

And now, your moment of zen...

The way to successfully price a fixed-bid contract is to imagine every possible scope modification possible, create an estimate for that, and double it.

You can use hours, weeks, or sprint poker points, but however you arrive at your final number, your goal is not to create a perfect estimate; your goal is to create a number that you feel so comfortable about, no foreseeable modification in scope is going to adversely affect your profitability.

By way of example:

Outcome #1: Your estimate was way too high, and now you've made a giant pile of money. Congratulations, you should celebrate.

Outcome #2: Your estimate more or less accurate, and you made an average amount of profit. Still not bad -- good thing you doubled that original estimate!

Outcome #3: The client requests are never-ending, and yet all seem plausibly within scope, making it hard for you to push back. You finish the project, but profitability suffers. Make the estimate even higher next time, and include more padding for unforeseen changes.

Outcome #4: Your estimate is generally on-point, but the client asks for something so obscenely out-of-scope, that you both agree the bid requires updating. Excellent -- this is the sign of good communication and a healthy relationship.

If you follow this idea, the most challenging issue you may run into is the sheer size of your estimate. It will seem so unreasonable, that you can't bring yourself to submit it. Do it anyway. If the bid is too high, that's not a project you want to take, unless you're willing to cut into your margins. For us, referrals are the largest source of our business, and you never want to ruin a relationship by making a promise you can't keep.

Think of it like creating a contingency plan for your client. You're allowing them to ask for basically anything they want, and have their wish granted! Now that's an amazing feeling, and that's how you build lasting relationships. Your colleagues and your clients will thank you.

In a future post, I'll discuss how we create worst-case fixed-bids that have the same safety nets for us as traditional fixed-bids, but potentially save the client money in the case of Outcome #1. It may seem counter-intuitive, but it helps win deals when budgets are smaller.

Feel free to reach out me @aclimatt or via Bitmatica if you want to chat more!