Ditching Hourly

Hello, and welcome to Ditching Hourly. I'm Jonathan Stark. Today, I want to talk about what I refer to as the hourly trap. Now, in an ideal world, both the client and the developer will end up profiting from a software project engagement. So both the buyer and seller make money. They'll both be happier after the project is over. From a numbers standpoint, this would mean that the developer's cost was less than the price, so the developer makes money, and the price was less than the client's value or perceived value, so the client makes money, makes a profit. Unfortunately, many, many software projects do not work out this way. In my opinion, that's because they fall into this hourly trap. So what I'm going to do is walk through the ROI calculations that take place throughout the course of a software project that's built on an hourly basis, and I'll start at the project estimate stage, because that's where the buying decision takes place, and continue through to the end of a typical project. And as you'll see, the ROI calculations can change dramatically throughout the course of the engagement. All right, so I need you to imagine a chart with three bars on it. There's a small, a medium, and a large. The smallest one is the cost. Let's just say it's $10,000. The medium one, the middle one, is a price of $20,000, and the third one, the tallest one, is a value of $30,000. So this chart, a chart like this, would represent the predicted ROI imagined in a typical hourly estimate prior to the start of the project. So if everything goes perfectly and the estimate is accurate, both the developer and the client, the buyer and the seller, will make a $10,000 profit. Remember, the cost is $10,000, the price is $20,000, and the value is $30,000. Unfortunately, in an hourly situation, the price, the $20,000 number, is not really a price. It's an estimate of hours multiplied by an hourly rate. However, the client is going to treat it like a price because they have to make a buying decision based on it. So in this scenario, when the client is presented with a $20,000, air quotes, price, they choose to buy. They're not technically buying at this point because the payments are made over time, but at least they have authorized development and have consented to begin paying as described in the terms of the agreement, typically weekly in arrears. Now, as the project progresses and the costs turn out to be higher than estimated, the price rises with the cost because they're tied together. So when you say that costs are increasing on a software project, it means that it's taking more hours. Assuming it's built hourly, it means it's taking more hours. So the cost to the developer, because the developer is paying with their time, goes up. And in an hourly billing scenario, the price goes up with it. They're bound together. Now, if this rising price hits the value, which you remember is $30,000, the client is going to freak out because they realize they're going to lose money. They know the project's not done yet, and the amount of money that they have paid to date is getting up to the discomfort zone because if they had been told up front that the project was going to be more than $30,000, they probably would have not agreed to the project. So this puts them in a really uncomfortable position. If they believe that the ultimate price will be less than double the current actual, they'll probably stay the course because that's the more economical option. In any case, they've lost faith in the seller and attempt to take control of the project by micromanaging and questioning hours and really turning into that nightmare client that we've probably all experienced. But it's understandable that they do this because they're trying to minimize the damage. So let's say the client decides to continue with the project begrudgingly. When the project is finally over and they sign off on it, and it's clear that the actual price was greater than the value, the buyer's going to be unhappy. They're going to have buyer's remorse. If they had known in advance that, say, the price was $40,000, which is $10,000 more than what they thought it was worth at $30,000, of course they're going to be upset. Now, the degree of unhappiness that they're going to be experiencing will correlate to the magnitude of the loss and its impact on the buyer. So this could range from annoyance. If $40,000 is basically a drop in the bucket for the business, they'll just be mildly annoyed. But if this was a huge investment for the company and they really bet the farm on it, rage is more likely going to be their reaction.

Again, they wouldn't have purchased if they had known the actual real ultimate price. Now, it's important to keep in mind as the developer that it does not matter whose fault this is. It does not matter if they were the ones that made the scope creep all over the place. They're going to be unhappy regardless of who they believe is to blame. So they might not blame you, but they might be incredibly angry. So perhaps the CEO of the company fires the person who initiated the project. They might not be angry at you, but they're going to be angry at somebody. Often a buyer will request a discount or refund, which would commonly be negotiated, perhaps subconsciously, to roughly split the difference between the seller's profit and the buyer's loss. So if we imagine our graph again, if the final cost ended up being $30,000 and the price ended up being $40,000, and the value never changed, it was $30,000, then the developer made $10,000 and the buyer, the client, lost $10,000. So if the seller, the developer, you, agree to eat $5,000 worth of hours, then it feels like splitting the difference. You've probably been in this situation before where the client was like, hey, how about we split the difference? We're getting killed on this. And you might agree to that because you feel bad because you either estimated the job very poorly or you allowed the client to expand the scope. You allowed scope creep to happen. So if you return $5,000, then it's kind of like you lost $5,000 that you should have made, and it's kind of like the $10,000 that they should have lost is down to $5,000, so it feels like splitting the difference, so that can make people a little bit happier. In extreme cases, a buyer might refuse to make further payments but demand that the seller continue working. So the client is like, this is ridiculous. This is costing us a fortune. We've got nothing to show for it. You completely blew the estimate. We're not paying you another dime, but we expect you to finish the job. In this case, both parties lose money because now our bars, the biggest one is the cost, the medium one is the price, and the smallest one is the value. It's sort of a stairway going down to the right. This is horrible. A situation like this will often become intractable, which can result in huge refunds, people getting fired, or in extreme cases, even lawsuits, and I've seen all three of these things happen on hourly projects. Okay, so there are really two things that we can do to avoid this problem. The first one is to get much better at estimating. So if you're amazing at estimating your work, then this will never happen, even if you're billing hourly. So you just are really good at knowing how long it's going to take you to build something. You're really good at preventing scope creep and keeping the client on track. And then you'll end up in that sort of ideal world scenario where cost is the smallest bar, the price is the medium bar, and the value is the biggest bar. So everybody's making money. If that's not happening to you and you have some of these nightmare scenarios creeping in, then you need to get better at doing your estimates. And there's a really good way to get better at doing estimates, and that is to create a financial incentive for you to get better at doing your estimates. So what I recommend people do is give a fixed price for a project. If you've tried this in the past and been upset with the results because you felt like you lost money, instead of switching back to hourly billing, what you can do, or what you probably should have done, was just kept at it, but just try to get better at doing your estimates. I feel like the person who's delivering the estimate should be the one who's responsible for its accuracy. Call me crazy. But this can be difficult. I realize you could easily put yourself out of business if you're horrible at doing estimates and horrible at controlling scope creep. Giving fixed bids is a very scary thing to do. But if you base those fixed bids on value, it allows you to create a really large value bar on the right-hand side of the graph, which gives you a lot more wiggle room in the middle. So you don't have to worry about exact hours. You don't have to get it down to an exact number. If a client comes to you with a project that has a lot of value to them, you have an enormous amount of wiggle room to set a price that is much higher than you would have estimated at your hourly rate. This allows you to...

Get better at your estimates over time without putting yourself out of business because you can set your prices higher than you would have set, say, an hourly estimate. All right, that's probably enough for today. See you in the next episode. Hey, Jonathan again. Do you have questions about how to improve your business? Things like value pricing your work instead of billing for your time? Or positioning yourself as the go-to person in your space? Or maybe productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal? Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes you to get ready for work in the morning. Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call you don't feel like it was worth it, just say the word and I'll refund your purchase in full. To book your one-on-one coaching call, go to jonathanstark.com slash call, C-A-L-L. That URL again is jonathanstark.com slash call. Hope to see you there.