Show notes
The theme of this episode is centered around the lessons learned in charging for software development. Starting with a question from the Infinite Red Community, Todd, Ken, and Jamon touch on hourly vs. project pricing, the tension between time and value, how software estimating is a lot like weather forecasting, and the many experiments conducted over the years to find the right pricing model for Infinite Red. Episode Transcript JAMON HOLMGREN: We received a question from the community, community.infinite.red, it's a Slack community that we have. Trent asks, "Hey Jamon, I'm enjoying the podcast. Will you guys be covering hourly pricing versus project pricing? It's a question we're dealing with right now. Which do you guys prefer, and what are some lessons learned to bring you to that choice?" I think this is a really great question. Todd, do you wanna talk about what we're doing right now? And then we can go into maybe what we've done in the past, and what brought us to that choice? TODD WERTH: Sounds good. Yeah that's a great question, and it's actually a really tough one to deal with. So, what we do now, is we do weekly pricing. We charge per person-week, and we call it "person-week" as opposed to "a week of work" because it could actually be two people working maybe half a week each and that would be one "person-week." Because we're doing person-weeks, we have a point system. So, 100 points equals a person-week. We don't track time. We used to, and we can talk about that—we used to bill hourly. We don't track time, we don't actually know how long things take, it's just, we estimate our tasks in points, and if we've reached a hundred or more per person-week and we charge per person-week, then we're accomplishing our goal. JAMON: There's a bit of a tension between time and value, and this has been something that we've dealt with, I mean, I've dealt with, since I started my first consultancy. Of course, value-based pricing is kind of a holy grail of pricing for consultancies, and we've heard this for a long time, that you should charge for the value, not just the time that it takes. So an example, this would be fixed-bid pricing, where you're essentially betting on delivering the software in a reasonable amount of time, but you're getting paid on the value to the client. The problem is that our costs are not based on value. So, we're not necessarily paying our people based on the fixed-bid, a percentage of the fixed-bid, or something like that. There are industries that do that, but ours is not one of them. So we're paying people salaries, and our costs are over time, and so if something takes a very long time, then our profitability and the ability of the company to remain financially solvent is threatened. Conversely, you have, of course, hourly. We've done that in the past, and the nice thing about hourly is that it corresponds, obviously, very tightly with the amount of time that it takes to do. But the problem is that every hour is not equal. You have hours that are maybe really valuable, you've automated something and in a lot of cases you're actually delivering more value than the client is paying for, quite a bit more. And then there are others where the person's getting spun up, or they're hung up on a particular problem, whether it's their fault or not, and that turns into a bit of an issue, because then you're billing hundreds of dollars an hour for something where the client isn't really getting a lot of value. So I think that's why we ended up where we are, in a way. TODD: Yeah, both have issues. When you're doing hourly, it might seem to a client that's more fair, but it's not. It means every time there's a bug, or any time there's an issue, we basically are nickel-and-dimeing them, and they don't necessarily like that. We have to spin up someone, like Jamon said, where in our value system that we use now, they don't see any of that. We fix the bugs because it's part of the value of that particular feature. It does mean, though, sometimes, that we can produce a feature faster than the hourly would've been, and so they get charged, I guess, more for that. KEN MILLER: There's a couple of different ways that hourly works out sometimes, though. There's certainly the very literal, like, you sit there and you run a clock, like the way a lawyer would, you actually have a little timer that shows exactly what you're doing. When I worked for a large sort of corporate consulting company, Big Five-style, back in the '90s, I remember my first week I was filling out my time card, and I filled in the insane hours that I worked, because that's the kind of work that you do. And my project manager comes over to me and he's like, "No no no no no no no no, this is not what you do." And he took my time card and he filled in "eight, eight, eight, eight, eight." (laughter) TODD: That's ridiculous. But... KEN: Right. So that's how the Big Five work, often. TODD: So it's completely fake in that situation. KEN: It's completely fake. It's basically pretty close to what we do now, which is that weekly billing. Where an hour is just a way of measuring a week. To answer the question directly, you know, do we prefer hourly or project-based, we prefer hourly. JAMON: Yeah. KEN: Hourly leads to less problems in the long term because the trouble with fixed bid, although it seems like it's appealing—It's appealing from your point of view, if you think you can be really efficient, and it's appealing from their point of view if they think you can't. But that's exactly it right there, it creates this adversarial relationship. Todd? TODD: Yeah, clients all– not all, but many clients think they would love a fixed bid. And in truth, they will hate a fixed bid. Ken's right. Fixed bids create an adversarial situation. Even if both sides are extremely... They're at the table in good faith, and they're trying to do the right thing and do their part and stuff, it still means that the client is trying to get as many hours as possible out of you for the same price, and us would be trying to do as few hours as possible. Like I said, even if you're both being very nice and very ethical in the way you're billing, that always creeps in. It also means that you have to lawyer every change. You'll have companies that have change order systems that are pretty complex. Clients hate that. When I talked to especially start-ups, one of the things I say is if the project we're working on at the end ends up exactly as you envisioned at the beginning, that's a huge red flag. That means you didn't listen to your beta testers, that means you didn't think at all during the process even after you got in your hands what could be better, it means a bunch of different things. So, we have a pretty strong process, but it's designed to be flexible. We wanted it to be flexible. So when we get to the point when we do estimation after a research phase, it's fairly accurate. The likelihood that it will actually produce your project for this estimate is extremely low. Not because we're incompetent– I'm sometimes incompetent– not because we're incompetent, but because you're gonna make a bunch of changes, and we welcome that. We don't lawyer that. But that's a little bit difficult, there's a little bit of education involved in getting people to understand that fully. JAMON: One of the objections is that, well, there are other companies that do fixed-bid, and they seem to do just fine. They're able to sustain that and their customers are generally happy, and things like that. But I think there's a hidden cost in there that people don't take into account. Which we've sort of driven a stake into the ground, we've said, "Hey, we're not willing to go down this route." And that is that those companies put the burden of hitting those estimates onto their employees. They essentially say, "Okay, well, we estimated this amount, you're not done yet, so you're gonna stay late until it's done." And they push, and push, and push, and they really, really just drive the screws in on their employees. Maybe not overtly, maybe not directly, but there's a culture and an expectation of being able to hit those estimates that puts a lot of stress on the employees. KEN: Yeah, that doesn't necessarily look like a slave driver. It can look like a "Rah-rah, sleep when you're dead," "work hard, play hard." "Rah!" But like, that kind of corporate culture. There are firms out there that I respect that do fixed-bids, and they seem to make it work, and that's fine. But in our experience, someone is paying for that somewhere. JAMON: Exactly. TODD: There's another type of fixed-bid which isn't just slave-driving your employees into the dirt. It is, you think it's gonna cost $100,000 on this project, you bid $800,000. So no matter what, unless you're ridiculously off, you're fine. The problem comes in when clients want both the lowest possible price and a fixed-bid. That just... It's not really possible. JAMON: So, our system is different. And Todd, I'd like you to talk a little bit about why our... Because, we are giving an estimate with points, and we're trying to hit those points, so it may feel like a fixed-bid, but do you want to explain what we're doing differently, where it really does change over time as you do a project? TODD: Yeah, so we do spend a decent amount of time doing research, architecture, that kind of stuff, before we estimate the points. So we're not just doing a ballpark estimate. We do a ballpark estimate at the beginning, but that's a few hours of our time. But we spend a few weeks or whatever doing research, architecture, that kind of stuff. And at the end of that, we produce an estimate in points. So those are fairly accurate. Obviously, anyone out there who does software development... By the way, everything we're talking about here is for development. On the design side, we do fixed-bids, and that's a different discussion. The gentleman who asked us the question was more towards the development side, so that's what we're talking about. JAMON: Right. TODD: So, our estimates are based on a whole lot more information than a lot of people do. And we do have clients who want an accurate estimate earlier, and we just have to push back, because in that situation we have only two options: We either push back against them and try to educate them in the process and help them do a successful project, or we lie to them. (laughter) And unfortunately a lot of companies just lie. They just come up with a number, they act like they put some thought into it– they didn't. I worked for a consulting company in the late '90s where the way we estimated was we asked the sales person how much they could afford. That was our miracle estimate. Which to me, I hated as an engineer. I just loathed it. I'm digressing a little bit here, but I don't want to make it out that our estimates are super accurate or that estimating software at all is an accurate thing at all. We know it's not. KEN: One of our sort of colleague companies out there calls them "forecasts," which I really like. People understand, like, a weather forecast is not necessarily going to be accurate. It's like, "Based on what we can see right now, this is what we think is gonna happen." And everyone understands that. So I really like that as a bit of language. TODD: Yeah, we should call it "forecasts." KEN: I'm tempted to steal that, but... (laughter) TODD: The other cool thing about a forecast is it's known: the further out you are from the date, the less accurate the forecast is, and the closer you get, the more accurate, and that's very true in our situation as well. JAMON: That's a great point, Todd, because we will definitely adjust those estimates as we get into things, and as we learn more. And I try to, I do a lot of the sales calls now, and one of the things I try to do is set the expectation that over time, the estimates will get more and more accurate, as we know more. The same thing with the weather forecast. You look at the ten-day, and you look at day number ten, and as you get closer and closer, you're gonna see a better and better forecast. And it's not uncommon for that to change even quite drastically, because weather systems can get delayed a little bit or something, and that can impact which day they land. KEN: Unless you live in California, in which case our weather never changes. JAMON: Yeah. No, I live in the Pacific Northwest near the Columbia River Gorge, and nobody understands the weather here. TODD: Our weather's hot and sunny. Tomorrow? Hot and sunny. The next day? Hot and sunny. JAMON: What if it's- KEN: And then a terrifying thunderstorm. And then hot and sunny. TODD: Once a year, we have terrifying water from the sky. I live in Las Vegas, Nevada, which is in this very small patch– I'm totally digressing here– but it's a very small patch in the US with the most sunshine out of the whole US, and it's just basically Las Vegas and around the desert area here. I think it's something ridiculous like 300 and some days of pure sunshine. Which is nice, as I lived in San Francisco for 20 years, and it is the opposite of that. And I enjoyed that for a long time, but I enjoy this. Anyways. So one of the things I wanted to bring up is, and we should talk about estimates. Because estimates are a big part of how you charge. And it is a difficult problem, and we have all sorts of issues that, I think, would be very interesting for listeners to hear that they're not alone in, and that we're still struggling with. KEN: Nobody has a magic bullet. Nobody has a magic bullet on that. TODD: It's a soft problem, it's definitely a people problem, and it's something that I'm actually actively working on all the time. But to finish up what we were saying before, we do find that weekly billing has worked out very well. It does require education. Your clients may instinctively go, "Okay, well they're just doing this to make more money because they're gonna get it done way faster, and they're actually gonna charge me this extra money, and they're not gonna do anything." And that's a perfectly normal human reaction. But one of the ways that we added some sugar to that tea is we say, "A bug comes up, sometimes bugs take five minutes, sometimes bugs take a half a week to fix. That's all included in that estimate. You don't have to worry about that. No nickel-and-dimeing." When the estimate goes up, say we add person-weeks to the overall estimate, and then maybe we add some calendar-weeks... By the way, we have typically a minimum team of two, and most times people work on one project full-time, so if you have a two person team on a project, we're producing two person-weeks per week. From that, and the number of points we estimate, we can calculate the calendar time, as opposed to the person-week time. And the calendar time does get extended, and the person-weeks do get extended. But it's always– not always, but it's usually from changes, and we try to be very good about being very transparent in explaining, and the client should know what all those changes were. They hopefully have approved them…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
