The Ruby Freelancers Show 057 – Fixed Bids
Panel Ashe Dryden (twitter github blog) Eric Davis (twitter github blog) Jeff Schoolcraft (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:39 - Experience working with fixed bids 04:08 - Risks Value 06:45 - Collecting Payment Working in phases and milestones 08:56 - Are fixed bid projects fair? 16:57 - Nailing down specifics 19:51 - Dealing with scope creep Contract clauses/additional contracts 26:15 - Getting clients to agree with your fixed bid or hourly preference 28:29 - Estimates Prioritizing Point estimation 37:11 - Transitioning from fixed bid to hourly work 38:42 - Figuring out what to bid Project management Value-Based Fees: How to Charge - and Get - What You're Worth by Alan Weiss Option pricing 44:41 - Ask clients why they prefer fixed bid pricing Picks Healthy Programmer by Joe Kutner (Ashe) DuoLingo (Ashe) #RubyThanks (Ashe) Becoming a Better Programmer Indie GoGo campaign (Ashe) Douglas Rushkoff: Wall Street Journal adaptation from Present Shock (Eric) Ruby Heroes (Chuck) Colloquy (Chuck) Value-Based Fees: How to Charge - and Get - What You're Worth by Alan Weiss (Jeff) Next Week How do you convince clients of the value of tests, refactoring, etc.? Transcript ERIC: Chuck, I'm cold. Keep me warm! [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 57 of the Ruby Freelancers Show! This week on our panel, we have Ashe Dryden. ASHE: Hello from Madison, Wisconsin! CHUCK: Eric Davis. ERIC: Hello! CHUCK: Jeff Schoolcraft. JEFF: What's up! CHUCK: I'm Charles Max Wood from devchat.tv. This week, we're going to be talking about "Fixed Bids". How much of you guys done with fixed bids? ASHE: I used to do them a lot more than I do them now; I actually tried to not do fixed bids. CHUCK: Is there a reason for that? ASHE: Yeah. It never really sticks really well with the fixed bid; I mostly do hourly now. I prefer hourly because it allows the client to kind of expand or contract their needs without feeling limited by the contract and it makes me feel less mean. CHUCK: Oh, it makes sense. ASHE: So I don't have to constantly say "Well, that wasn't really part of the original contract". I can give them what they need and what they want without having to have that difficult conversation. CHUCK: How about you guys, Eric and Jeff? JEFF: I've done a few very small fixed bid projects. But by large, I'm mostly hourly mostly for the same reason as Ashe has. And beyond that, it's really hard to get a scope timed on off and it makes it comfortable for me to try to bid on something. ERIC: For me...I don't know, maybe 20% if that -- I actually have a different reason. I don't mind fixed bids, but the project has to be very specific. There has to be a lot of trust between me and the client first off so that I can trust that they're going to understand what's cocube is; we don't have those problems or discussions. The other side of it is, the project has to be [inaudible] and that it's something I've done before or there's not a lot of technical risk on the project. If there is a lot of technical risk for a lot of unknowns, then I basically say "We're going to have to be hourly because I can't guess this upfront and commit to it". CHUCK: Yeah. I've done a couple of fixed bids myself, they were less than a thousand dollars effect; both of them were $500 a piece and it was an enough work that it wasn't that risky. One of them, I really actually didn't get paid on; and it was because I was setting up some software, some third-party software, for somebody on their server. He was unhappy with the result because there was a bug in the software that I set up, but I didn't actually write it. Anyway, it's kind of interesting I haven't done major fixed bid projects,
ERIC: Chuck, I'm cold. Keep me warm! [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 57 of the Ruby Freelancers Show! This week on our panel, we have Ashe Dryden. ASHE: Hello from Madison, Wisconsin! CHUCK: Eric Davis. ERIC: Hello! CHUCK: Jeff Schoolcraft. JEFF: What's up! CHUCK: I'm Charles Max Wood from devchat.tv. This week, we're going to be talking about "Fixed Bids". How much of you guys done with fixed bids? ASHE: I used to do them a lot more than I do them now; I actually tried to not do fixed bids. CHUCK: Is there a reason for that? ASHE: Yeah. It never really sticks really well with the fixed bid; I mostly do hourly now. I prefer hourly because it allows the client to kind of expand or contract their needs without feeling limited by the contract and it makes me feel less mean. CHUCK: Oh, it makes sense. ASHE: So I don't have to constantly say "Well, that wasn't really part of the original contract". I can give them what they need and what they want without having to have that difficult conversation. CHUCK: How about you guys, Eric and Jeff? JEFF: I've done a few very small fixed bid projects. But by large, I'm mostly hourly mostly for the same reason as Ashe has. And beyond that, it's really hard to get a scope timed on off and it makes it comfortable for me to try to bid on something. ERIC: For me...I don't know, maybe 20% if that -- I actually have a different reason. I don't mind fixed bids, but the project has to be very specific. There has to be a lot of trust between me and the client first off so that I can trust that they're going to understand what's cocube is; we don't have those problems or discussions. The other side of it is, the project has to be [inaudible] and that it's something I've done before or there's not a lot of technical risk on the project. If there is a lot of technical risk for a lot of unknowns, then I basically say "We're going to have to be hourly because I can't guess this upfront and commit to it". CHUCK: Yeah. I've done a couple of fixed bids myself, they were less than a thousand dollars effect; both of them were $500 a piece and it was an enough work that it wasn't that risky. One of them, I really actually didn't get paid on; and it was because I was setting up some software, some third-party software, for somebody on their server. He was unhappy with the result because there was a bug in the software that I set up, but I didn't actually write it. Anyway, it's kind of interesting I haven't done major fixed bid projects, though, I might pick one up here pretty soon. ERIC: I've done one -- it's more of a support contract but it was fixed amount, fixed cost on the client end, fixed timeframe, and semi-fixed deliverables - but deliverables, it could be kind of vary on how much work I'd have to do. There was a [inaudible] size of the project, but they didn't actually use that much of it so it ended up pretty successful one like they didn't go and do a lot of scope creep or go over on my own cost accounting for the hours. I've had a couple fixed bid projects that were pretty decent amounts, maybe a month of part time-ish work; those were clients I really trusted and we had a lot of good relationship before that. So they brought up stuff that actually was a kind of scope creep out of scope, so we actually shelved that until down on the later stage (don't ever felt it's fixed bid or not). But yeah, that's the only thing with fixed bid; you got to be careful dealing to get into a fixed bid for 6 months full-time development 6-7 figure contract because that just gives you a lot of opportunities to just kind of completely blow you bait out of the water. CHUCK: Right. So the risks on the fixed bids, Ashe brought up that "she wants to make sure they get good value on the money they're putting down", and so there's some risk there that you bid them $10,000 and they only get $5,000 worth of value and they are unhappy. And then there's the other risk where you bid it for $10,000 and you do $20,000 worth of work and you're locked into that because of the contract. ERIC: Right. And you also have to watch, though, like hourly had it on risk. I mean you as the consultant have a risk of bidding a project that's hourly and the client not using your hours. So then you have your contract, you're obligated to be available to do work for them but they're not using your hours, you now have idle time. So you would take on a risk of bidding supposedly, say, $10,000 project but only able to bill $1000 of that because they kind of idle the rest of the time. Fixed, they kind of reverses that, but you (like you said) have the risk of you might to get $20,000 of work, but you'll only going to get paid $10,000. Or, it could be that you do $1000 worth of work and you get paid $10,000. So, it's risk transferring. CHUCK: Yup. ASHE: That's a good point. I can definitely see why lot of clients prefer fixed bid. I've just never really had it go as well as I do with hourly; I feel like I'm generally not as happy there. I'm not as happy because I have to stay within a certain number of hours very strictly, and that might mean something that they really wanted that took more time than expected or it kind of bloomed into something a lot bigger they can't get. So I can understand a lot of clients wanting to be able to say "Okay, we budgeted X amount of dollars for this, and that's what we expected; we know what we're going to get on the other end", but I feel like the amount of time that that actually happens is rare. CHUCK: Yeah. I have a guy that I've been talking to and I keep coming back around to hourly and then he keeps coming back around to fixed bid, and I think that's exactly it. He wants to be able to just say "This is going to cost me X dollars and at the end of it, I'm going to have Y product". It's kind of interesting because I keep explaining to him that when I do a fixed bid, I'm basically bidding everything out, giving him my worst case estimate + a buffer. And if we go with hourly, then he's probably going to cost less; but at the same time, he's more comfortable with that because that's the way he's dealt with things in the past. ASHE: I'm curious, how do you take payment for that? Do you have them pay a down payment and then just have milestones and they pay on those? Or, is it all one lump sum? CHUCK: I've heard several ways of going and they all have their tradeoffs. One is that you collect half at the beginning, and half at the end. I was talking to a local design firm that had some dev work, they were looking at sending my way, that we are still negotiating on. But yeah, that was their deal "We'll pay you half at the beginning, half at the end". I've also heard it based on milestones; I've heard of people doing it based on -- basically breaking it down into multiple fixed bids so you have each milestone as worth a certain amount of money, and then you can change things as you go on the later milestones because you just negotiated a new bid on each set of things. ERIC: Another one I've heard is like 50% upfront and then 50% a month later. So, it's not 50% at the end, but it's like into the project a little bit; that's a bit better for the consultant because you're getting cash flow earlier. CHUCK: Yeah. I do really like the idea of breaking up into smaller bids because then, as they get more information, then they can still kind of change direction and not have to kill the project because you're locked into building something else that they now figured out they don't need. ERIC: Yeah, that's what I do a lot of. Like, I've gotten fixed bids that'd be the larger like 3 or 4 months of development, and I would say "Look, I'm happy to do this with you, but there's so many unknowns and we're going to locked or result into something that no one's going to like. What we'll do is, I'm going to break it a bit into phases of like 4 weeks or something. We'll do a fixed bid for that and then around week 3, we can re-evaluate what we've already done, stuff we've learned, and I'll do a fixed bid for phase 2", and basically keep that approach. So, it's kind of [inaudible] in a way, but still fixed bid and that they can seer it at big major milestones and they don't have to worry about dumping all these money and time into something that they really don't need. CHUCK: Yeah. One other thing that I really want to point out with fixed bids is that, in a lot of cases, you'll wind up making 2, 3, 4, 5 times your regular hourly rate, and your client will be totally happy with the work you did, in which case, it seems like it's a win-win - they got the value that they wanted and you got paid way more than you were gotten paid hourly. Do you guys feel that's fair? Mostly fair? Not really fair? ERIC: I think it's completely fair. If the client got the value they wanted for the fixed price that they are willing to pay, that's fair. You can start into getting to like really extreme examples where, say, you're getting $1000 an hour that it might not be fair, but it really comes down to "Is the client still happy that you delivered the value they wanted?" I mean you can look at the government contract -- Evan's not here, so we can't speak about it -- but, people there are paying millions of dollars for toilets and stuff. So, is that fair? Well, probably not. But, you got to look at it from the perspective of the person who is getting the value. And as long as you're being honest and not like scamming them and putting a fake facade over the software that actually doesn't work behind the scenes, I think you're fine. ASHE: Yeah. And I think from our perspective, the fairness kind of evened out because I think that they were also be fixed bid projects that you'll be making less than your regular hourly. So from our perspective, it might even out. But...I don't know, I have different feelings about how on the client's side. I would prefer to, if there's a way, to deliver as much value as they paid for it. If they feel like they got $1000 an hour worth of value out of something that I'm doing, then I definitely feel okay about that. But if they feel like they got less, then...I don't know! I prefer the things in "an ideal world" feel fair to everyone. ERIC: [inaudible] two things of that. One, when we're looking at value as a consultant, we're also, in a way, putting our own judgement on it of "I, Eric, paid $2000 for the software that took me an hour to write", I wouldn't, but someone else who doesn't know software might because it might be completely out of their realm; it might be too complex. So, that's something you have to think about as you're looking at it through your own biases. And so that could be a factor in trying to determine "Is this fair?" JEFF: Even beyond the "Would you do it because you know how to do it", would a client pay you a $1000 an hour for a week to write some piece of software that saved 15 other sales people of 20 hours a week or 40 hours a month or whatever time being and save them $100,000 a year or $250,000 a year, when you start looking at it at a bigger picture not on hourly basis, but how the value impacting their bottom line for some period in their future, I think it works out far -- hopefully it works out far in the client's favor. Alan Weiss is probably more outspoken about that than anybody; he's one of those things that "you have to be able to love yourself and not laugh when you say that you worth $1000 an hour, or $500, or $300", or whatever that bid's out of you. ERIC: Yeah. I think he was the one who had that phrase like "If you don't have the coffin, just look at yourself in the mirror and say with a straight face that 'This project will cost $50,000'. He said like you need to start working on your own on motivation or confidence building, and all that stuff. CHUCK: Yeah. I think the trap that I keep following into with some of this is that I value my time at a certain price -- and you guys are talking about this here -- but since I tend to value my time at a certain price (that's my hourly rate or however I decide that it comes out), when I wind up getting more than that, that's when I start thinking "Okay, did I really give them that kind of value?" and I don't recognize that, yeah I may have save them hundreds of thousands of dollars, and they only paid me tens of thousands of dollars or $5000 or whatever it cost for the project. ERIC: Yeah. That's a good thing to do as a person to kind of evaluate and kind of question it, but it's also the cost under the equation; like what Jeff was saying, it doesn't matter on the cost side, it's the revenue side. CHUCK: Yeah. ERIC: For the most part, a house is wood, plastic, and a bit of metal, but the value of a house is a lot more. Some of them are worth millions of dollars even though they're made of very basic components that are very inexpensive and very commoditized. But the value of having a house and having a dwelling, the benefits you get from that, that far outweighs the cost of the materials and even the cost of the waiver that's put into it. CHUCK: Yeah. JEFF: I think the hardest bid of a psychology and to get out, for me, I think a lot of people are just that -- there's just natural opinion that when someone's going to bill you hourly that they're going to take as long as it possibly can to get it done to make as much money as they can. I mean the fixed bid type thing, if a client can get a scope and you can get a scope, that make it all feeling not that risky. I mean they have a single line item they can put in their budget, and they have an end to it and it was software, especially the clients that have worked with contractors before -- I'm sure a bunch of them have a bad taste in their mouth, and maybe I'm just only pessimistic; but software never gets done and it can just go on and on forever especially if you've been on trying to reign the client end and make sure they know exactly what is going to cost them to do what they're trying to do. CHUCK: I actually worked with a client that there were two contractors that were working with them and then there was a firm that they were working with, that was a foreign firm. The guy in-charged of the project basically said that about the foreign firm was that, "Since we're paying them hourly, it's going to take as long as it can and still be reasonable". And so, yeah, I can definitely see that. ERIC: What I was going to say...the second point earlier is, if used -- which is a really good example -- if I charge a million dollars and basically did the work for that in 10 hours and the client was happy with it, that's at extreme example. But if I feel like that's not fair, if I feel like I didn't deliver million dollars of value, whether or not I did or not, that's different, but if I feel that way, what I've done on projects is I've went back to the client and said "Hey, I actually have a little bit of extra wiggle realm in the budget or in the time, is there another feature, too, that I can take a crack-eye and see if I can implement with this remainder and therefore I can give you an additional amount of value without you paying any cost?" I've done that at least two times, and each time, the client is like "Yeah, here's the couple of other things we're thinking about for phase 2". And I know one case specifically like I was actually able to implement like one or two bigger features, and I still kept my cost and my amount fine on my fixed bid, but they got an even additional amount of value above and beyond what they paid. JEFF: It's the little things and [inaudible] to suggest is, if you could do that in a normal circumstance and say "Hey, I've got a little bit of extra time", because no client expects you to tell them you've got extra time or extra budget. I mean it's a huge win from the client's perspective of you if you come back and say "Hi, I can give you this a little bit more". I know we've talked about that once before, but it's always worth remembering. ASHE: Yeah! And I like, too, that (I think) that increases loyalty and trust and they're more likely to -- because the vast majority of my clients are referral-based -- they're a lot more likely to refer other people to you because they feel like they have that trust and they know that if they refer someone else to you, especially if that's a personal relationship that they have our business relationship that they have, that they want to graph that. CHUCK: Yup. So, I want to talk a little bit about some of these fixed bids. We were talking a little bit ago about kind of breaking things up into smaller chunks that get bid on their own. One of the reasons I like that is because it's easier to nail down all of the specifics that have to be done for that smaller chunk as opposed to a larger chunk. How do you know when you have the specification or the statement of work nailed down to the point where you're not going to get killed by scope creep? ERIC: When the planets align. [laughter] JEFF: Just about never. ERIC: Yeah. You're going to have that risk no matter what like it's what's called "unk-unks", the unknown unknowns. Mine's I got a feeling like "Okay, I might got...feels like this is close enough", and I have enough buffer built in, but you're never -- you can't get comfortable with it because you're never going to get it nailed down or perfect. It's going to change and you're going to -- features are getting thrown away, features will get added -- you just have to make sure that you're ready for it and prepared. JEFF: I'm viewing on breakdown fixed bid a couple different ways. I know you were talking about smaller pieces, but there are a lot of people that talking about doing by the day, blend by the week, and...I don't know what you would call it, maybe "services of product" -- I know Eric does something somewhat like to that -- but I mean there are ways to get closer to fixed bid without going all the way to fixed bid and sort of. There are few firms; I think SoftBot does it and a couple of other people that bill on a weekly basis and...I don't know if they track time, I can't remember the details. But, I think there are a couple of ways to get closer to fixed bid without going all the way to fixed bid. ERIC: Yeah. And that's where you kind of expand the time you're using like most people, let's say I bill hourly, well technically they're billing a variable amount of time that just happens to be an hour as their unit. I've seen people that have day rates and weekly rates, that gives you a larger unit of calendar time that you're billing in for something. I know a guy, he has a weekly rate, and so his weekly rate is X and that's what it is. If you need him for 1-day, 2-day, 3-day, or five-day supposed over time, his rate stays the same. So he can technically go to a project and say "This is a 4-week project" and give them a fixed bid, but it's still in his accounting; it's still kind of variable because it's "I have 4 units of time at X dollars". CHUCK: That's interesting. That's an interesting way to go. ERIC: If you really think about it, if you have a fixed bid contract that, say, 6 months and you're bidding $60,000, you're actually just saying "That's still a variable rate". The unit of time is 6 months and the cost per unit of time is $60,000. All of these really is just trying to figure out the time and then the amount of the cost and getting that so that the risk of the consultant and the risk of the client is in a way where basically people can agree to it. CHUCK: So the next question is, what happens when you do are in the scope creep? Let's say you've estimated a reasonably large project, you're halfway through the scope, and then they say "Wait a minute! Wait a minute! We don't need half of the rest of the stuff, we actually need other stuff". JEFF: When the stickler is in the hard asses, probably the successful business people would say then "You re-negotiate" or...probably that you re-negotiate, I imagine; also you can explain to them a tradeoffs. But even then, if you're going to change something that dramatically, or...I don't know what that dramatically scale works out to be, but I think at some point, you have to decide for yourself how much you're going to let somebody change the scope, whether in cutting something out or adding something in before you just re-negotiate the contract. ERIC: Another thing really to be careful if you do allow scope creep, if you're contract says you're delivering A, B, and C but C is deleted and you add D, you are now kind of in violation of contract. And so I, at the very least, send them addendum or whatever saying "We have changed this contract; cost is the same, C is removed, D is added, just so you have a paper trail". CHUCK: Yeah, I absolutely agree there. Even if it's something small, then they can't come back to you and say "Well, you said you would deliver C and it's still in the contract and...blah, blah". And so it's like "Look, this is so that we cover each other; I don't have expectation to get paid for C and D, and you don't have an expectation that I will complete C and D", and you can kind of move ahead that way. And if you make the addenda pretty painless, then it shouldn't be a big deal. It's just what we need, the signature before we can move ahead with D. ASHE: I actually have a clause in my contract that specifies that. Like this contract only covers what's stated in this contract, and if you want to work above and beyond this, another contract is needed. Because I've had clients in the past that will get 80% done and they'll do one of the two things: either "I don't really want the last 20%, can we do this instead, or they'll want to continue the relationship and basically add more features or whatever, I've been burned so many times by this thing he had us on a big deal, it's a small thing, and it's not in writing and it's not formalized that just bad things had happened. So, it's just a lot easier for me to have very specific contracts for very specific things; and it takes 3 seconds to sign a different contract, it's basically where I'm coming from [laughs]. CHUCK: Yeah. And that's opposed to hourly where usually you're statement of work is "programming against X project and you'll pay me every so often for how many hours I worked". ASHE: Yup! ERIC: But as far as you're saying about like knowing if you're going to allow a scope creep, I'm not that a stickler on it, but basically it's something like 10% of the project and they're removing something that I estimated to be the same as what they're adding, I'll allow it like I'll do the legal stuff to make that it's all legit. But, 10% I'm like "Okay, that's fine. I can handle that", when they start pushing 20 or 30 or maybe even half the project, that's when I really start saying "Okay, we need to kind of stop, re-think what we're doing, maybe re-negotiate". That's why I just overall favor really short fixed bids like a week, 2 weeks of development because in those cases, it's easy to have a few deliverables, "you do those", and then "you do that re-eval", and then you do any new negotiations for the next fixed bid versus doing a 4-week contract that you have to stop halfway through and re-evaluate it. CHUCK: Yeah. And I have to say, I've had -- with the paper work -- I've actually had a client or two say "Well, don't you trust me?" My answer is always the same; it's always "Yes, but I've trusted other people before and it hasn't worked". [laughs] ERIC: The best answer is "Yes, I trust you, you do trust me. What's your bank account pin number? That way I can just take the money right out your account when you need to instead of even send you this paper work and this invoice". CHUCK: I think they would think I was being a little bit smart alec with them. ERIC: Oh, yeah! That's the point. But it's the kind of idea like "Do you trust me?" "Well yeah, but not everyone has complete trust in everyone else, and if you kind of acknowledge that, that's a different problem." CHUCK:"Well, I've gotten good rapport with people and then been burned by them. So the only guarantee I have is you give me a legal recourse [laughs]. I'm really sorry, but I have to get paid. And I've been burned by people I thought I could trust. I'm pretty sure I can trust you, I hope that it works out, but yeah, we got to do the paper work". ASHE: I like to phrase it in that "Contracts aren't about trust. It's making sure that we both understand what we agreed to and it's in writing and it protects both of us from each other and from ourselves." So I try to do it in a way that makes it seem like non-confrontational and that it's a benefit to them because I've had the same people say things about signing contracts in general, and I just won't work without a contract. And that's a stipulation for me because I want to make sure that in signing a contract, you agree that you've read all these things and you understand what I expect at our relationship and you understand the kinds of things that you should expect from me. CHUCK: Yeah. ERIC: Yeah, I mean like in the legal sense of contract, it's actually just the written form of an agreement. There's the verbal contract; if two people agree on something, that is a contract. It's just that it becomes his word against his word, and so you can't really kind of force setting court as good as having the legal, written-down using English language that everyone understands, the lawyers understand at the very least. If someone says "I don't want to sign your contract, I agree" but they have a different understanding of the agreement, that's going to bite you. Most of the kick back I've ever got on contracts was because the client didn't understand what they wanted or what the contract was saying, and so they were just trying to go off of "I agree with you 80%, the 20% I'm not going to talk about right now", and that 20% come at the end of the project and it cause a whole bunch of headache. CHUCK: So it sounds like Jeff and Ashe tend to prefer more the hourly bids; I tend to as well, but that's more because I'm more comfortable with them. How do you guys tend to push people toward hourly bids if that's your preference versus fixed bids? And when do you push them the other way? JEFF: I very rarely had clients that actually try to convince me to do fixed bids. Most of them just accept the fact that I propose hourly and that's how they pay me. ASHE: A lot of times, when people are coming to me asking about fixed bids is because that they have a budget of a certain amount. So, we'll kind of work there together; we'll take a look at what their budget is and then take a look at the features that they want and kind of assign estimated hourlies to each one of those and then just only do the features that fit into that budget. So I haven't really had that much push back because they're still kind of getting what they want, they're still sticking within their budget, and they understand that only these features will be provided but the dollar amount is +/- 10% or whatever it is within their budget. CHUCK: Yeah, I'm kind of the same, just what you said, Ashe. I do tend to push some people toward fixed bids, but it's usually on really small projects that is just something that I don't really want to track time on and I can just crank it out in a few hours or a day. And so I'll say "Hey, just give me $500 or $1000 and I'll pop whatever it is handed over"; you just put that in the contract. But yeah, for the most part, I tend to push them toward hourly and it's for the same reason. ERIC: Actually I'm thinking, I've done a lot more fixed bids than I thought. I used to have a setup project where it's set up on Redmine or ChiliProject and so on or fresh server, and I just fixed bid that just because it wasn't worth the time, the administrative time, to have the client see the estimate, approve the estimate, and then we start on. I just knew that it will take this amount of time; and basically in my hourly rate, I could just "They sign and they pay me, I go do the work and be done". JEFF: That's what I'm talking about - the, I guess, services of product. I don't know if there's a better way to describe that. ERIC: Productized Service is what I've heard a lot of. CHUCK: Right. ERIC: And it's still just the same; we're just moved around. But, yeah. CHUCK: One other thing I want to touch on really quickly is that, I have actually, in the past -- and I still do this with a lot of clients -- is also down with their list of things that they want, and I'll estimate them out in the number of hours it's going to take. I usually give them a best case and worst case, and then just explain to them that it's going to come in somewhere in the middle. Usually, 1/2-2/3 of the way toward the worst case is about where it comes in; it's pretty consistent. And then we talk over things and sometimes, my clients take that to be sort of a fixed bid. Sometimes, it take the best case to be sort of a fixed bid. So then, I actually talk them around that. Do you guys have any advice for that sort of thing? Should I just push them toward to fixed bid at that point? Just give them the worst case? Or, what? [crosstalk] ASHE: Go ahead... JEFF: I was just going to say, I guess it depends on how worst case your worst case is. If there are so many -- I don't have the discovery process that Ashe and apparently Evan do. It would seem that, that would lead to a much smoother fixed bid process if that's where you're going to go. But, if you're at a point where you're doing the whole 4X plus another 4X just because its [inaudible] is crazy weird and there's a whole bunch of gaping holes, there's probably no way I would ever do a fixed bid. But if there are one or two things, then it might be tricky because you haven't seen them before and they don't sound that crazy, but you've not done it, then maybe. I guess it'll all depends on how far out your worst case is. ASHE: Out of curiosity and kind of related, do you guys always provide an estimate upfront? Is there any language? Like I try to do discovery upfront for all of my projects and provide what I think will be a very reasonable amount of time for each item and breaking it down; most of the time, we've kind of besided on most important to least important so just in case we ran outside of their budget, the less important things will be dropped off. Do you have a line on your estimates that basically says "This is an estimate; it's +/- 10%", or "If we start going a little bit further than what we're expecting, we'll notify you"? ERIC: I don't have that in my contract because I put the discovery kind of as part of the project itself. So, I don't have estimates. I just have like "I'm going to work on this for a certain amount of time at a rate". When I'm actually working on it, I'm estimating like a feature. A lot of times I'll say like "This is a 2-4 hour estimate", depending on whatever its variables. And I -- most project management systems alignment should track one estimate value, which is stupid; it's the worst thing they can do -- I put the high value in there just so the client can see that's kind of the upper bound. And then I have an understanding with the client that as I get close to that, if I see like "Oh, we're going to blow this estimate", I tried to stop and notify them and say "Hey, this is going to go over. I can keep working on it, or we can stop, or we can change it, or we can up the estimate". And so I kind of do that very flexibly in the project, but it's not on my contract about it. CHUCK: My deal is this, generally upfront, I try and estimate out how many hours the different features will take, and yeah, I prioritize them according to what the client says as the most important. And also, I talk through them and make sure that I understand more or less what needs to go in there; preferably more, but sometimes they don't really know either, which obviously pushes my worst case assessment up. And I'll put a note on that; sometimes it says "I don't understand this feature. From what I do understand, it looks like this. But it may involve these other things...and so because of that, it's higher". But yeah, I don't have any language on there that says "This is an estimate only. These estimates may vary one way or the other", I don't have anything on there. I should put that on there, but I don't. Sometimes explaining "Look, this is only an estimate. This is not an actual promise that I'm going to get it done in this amount of time". ERIC: One of the better project management processes I've seen with someone else was, they had the estimate and then they give a range like, say, 2-4, but they also would give a confidence so they could still like "I'm 95% confident, it's going to be in this range", or "I'm only 10% confident, which would show that this could be really simple or could be really hard". That's interesting because that shows the client what the risk of going over budget on that is, so they can pick the lower risk budgetary items if you're working in hourly or fixed bid. It's interesting. It's a lot more work with estimating -- and because estimates really, they're just guesses, it's kind of hard to make a guess and then have the confidence of the guess -- but, that might be a little bit of extra day that you can try. CHUCK: Yeah, that's interesting. The other I usually put on there is a "Point Estimate". It doesn't necessarily mean anything to them, but then I explain that "Once we get going, typically, we're going to be watching the points as opposed to the hours", and that the points tend to give me a better idea of how long it's going to take to get things done - how many more weeks. They usually don't get that until we're couple of weeks in and then I'm going "Okay, we averaged out the last couple of weeks. Looks like we'll these get things done." ASHE: Do you then on those that you'd give them the points? Do you bill by point? Or, you do bill by the hour? CHUCK: I bill by the hour. ASHE: Okay. CHUCK: But, the points are just a tool to give them velocity. ASHE: Right. CHUCK: And so I've used Pivotal Tracker to track some of that. I'm starting to play with Redmine and ChiliProject a little bit more and see if or how I can do some of that stuff with those systems. But yeah, since it gives them a velocity, then they can look at it and say "Okay well, given this deadline, then I can move things up and down", and then I encourage them to reorder things in the project management system so that they get down on time. That works well for both fixed bid and hourly projects. But yeah, I'll bill by the hour or, unless it's a fixed bid, obviously. ERIC: That looks like [inaudible] because you could touch, we have a fixed bid or you bill by the point, like each point is $100 and then -- because they're semi-associate with hours, but they're not, so you could say like "This project is 1000 points, therefore, it costs $10,000" or whatever. I would have do it, but I also don't like points. CHUCK: Yeah. The interesting thing about the points is, for me, the points represent how complicated or difficult the story is. So it is kind of an interesting way to think about it simply because the harder or more complicated a story is, you're going to cost them more. I don't know. Hourly or hours per hour or per project are things that people can easily wrap their head around because it's a unit of measure that they're familiar with. ERIC: Yeah, that's exactly why I don't do points, because as a consultant, I bill most of the time by the hour. I want to show them in hours, and so they can directly translate to dollars. Having points is an obstruction that's added on that makes it harder for them to see the actual cost of a feature. CHUCK: Yeah. ASHE: I think it also provides them a context for valuing your time, too, so that they know that something is not a quick and easy change. They can start, especially if it's somebody that hasn't worked with a consultant before, it kind of gives them that context for understanding that some things are more complicated; there's no easy way to assume how long things are going to take. CHUCK: Yeah. ERIC: Yeah. The other thing they'll think about is also its time in cost, like this much per hour, but also calendar time. If you've given estimate that is 40 hours, if you kind of think about it, that's about a week of calendar time, like they cannot expect delivery of feature tomorrow. But points, it's kind of a bit hard because of that obstruction. CHUCK: Yeah, you usually need a little bit of lead time before you can really make the points mean anything. "We're pretty consistently around 10 points a week, so you got 30 points before you get to this feature that you say you need next week. So, you have to realize that if we're going in order of what you got here, then it's going to be 3 weeks out, not 1 week out. So you got to re-arrange your priorities so that we can get to it." Anyway, I think that's a conversation for another day. Are there any other aspects of fixed bids that we want to talk about or bang on? ERIC: One that I frequently use is, I'll do a fixed bid for a prototype like they have an idea that's kind of bit rough, it's not going to go on to production. Do a fixed bid and it's mostly an expiration, and that's when a client kind of keep that expiration cost really -- they know what it's going to be. And then, sometimes it might be a fixed bid for the first phases of the project because most of the time the first phase is a bit of set up and you're building new stuff. So it's actually, you goes pretty quick, everyone enjoys that phase. And then after that, I tend to transition it to the hourly because at that point, it's in production; t's more maintenance type stuff and you're going to run into a lot of the legacy code or the legacy problems. So I kind of have a transition to start something as a fixed and then slowly turn it into an hourly for the regular maintenance type of work. CHUCK: When you do that, do you timebox the prototype or the set up to a certain amount of time? Or, do you just as long as it takes it takes? Or, what? ERIC: Yeah, I would internally, like I would base on how I work in Rails and how the stuff goes for me. I would know you on takes as much times 2 a credit section and this prototype needs 3 credit sections plus this kind of technical bait, which is why they're prototype and so I would do my own internal estimates and then use that for the fixed bid. If it was an actual hourly contract, like say, they wind up, the prototype, as hourly, we would timebox that we would say "You have 10 hours to prototype this, get as far as you can, leave an [inaudible] to kind of summarize your results, and present it to everyone. CHUCK: One thing I don't know if we talked about with fixed bids is, how do you come up with what you bid? Do you estimate the number of hours you're going to take and then pad it? Or, do you go with however much you think the customer is willing to pay even if it's a whole lot more than what you're hourly estimate would be? Or, is it somewhere in the middle? ERIC: I get a 20 sets of days, roll it 3 times, multiply each one, and then add 3 zeros to the end. That's pretty close! It works good for me! CHUCK: Set the number of hit points you get - in D&D? ERIC: Yeah, but I don't think...Anyways, what I do I estimate how long it's going to take and then I kind of say confidence like "Okay, simple Crowd system, not very many fields, not going to take that long. More complex Crowd system, lots of associations, lot of nested..." stuff like that, like that's going to take longer. Basically, I get all that, I total it up, and that's kind of my best-case-first-run-gut estimate, and then I'll pad it depending on how much the project is. If it's going to be a week, it's going to get padded a little. If it's going to be 4 weeks, there's more time; there's going to need to get padded more to count for more areas that unknowns us going to come in. Just kind of play with that and try to figure out like "Okay, this is the final number, you got to check this out. Feel about right based on my previous experience". CHUCK: Jeff, Ashe, do you do anything different? ASHE: Like I said, I rarely do fixed bids, but I think that, that makes sense. I think that there are a couple of factors like "Have you worked on the set of project before?", "Have you worked with this client before?" Because I find that some clients that I haven't worked with before, the part of the project that ends up being a little bit bigger than I expected, tends to be project management like client management, and kind of walking them through how things work or walking them through processes if they're not familiar with them. So yeah, I think it makes the most sense to kind of give your highest estimates for each item and then going from there. ERIC: Oh, yeah! If you got the project management, that's a big part. I add that as like its own little line item of 30, 40, 50% or a chunk of hours, and then I add padding on top of that. I forgot of that part. CHUCK: That's an easy one to forget, too, because you're focused on what it is going to take to solve this problem, and you forget about what it is going to take to solve this problem, and interface with the customer, and you have to get it right. ASHE: Yeah, especially if you're talking about then teaching a team to use whatever it is afterwards. It's really hard to judge what people's skill level is or level of understanding is before you actually do it. With new clients, I always add extra time into the estimates for project management above what I would expect. CHUCK: Yup! What about you, Jeff? Anything to add? JEFF: No, I don't think so. I think I fall in line pretty much with what Ashe is saying. And any estimates I have had to provide for an hourly basis or more just to give the client an idea of what maybe the scope of the work might be. But, I've never been held to an estimate that I can think of in [inaudible]. No, I have tried once. There's, again, Alan Weiss "When you're going to bid, sort of fixed bid products or projects (he talks about the 3 levels, and it's like the bare bones) you have to be an idiot to take the lowest price, and then the middle was what you actually want people to do, and then the high end is like all the dozen results plus everything else" type thing. I know that doesn't answer the scope question where the risk question -- ERIC: Oh, the option pricing -- JEFF: Yes, the option. So if you're going to bid something -- so you've done the discovery, and you have everything estimated out, and you have the priorities high to low -- you could say "Well, it draw some line (here's what we said) it's good enough (and that's the middle price). Everything is the top option and we've cut some corners here and there, here's the (sort of) the low option", you're shooting for them to pick the middle. Occasionally, you get some people that'll always go high and will pick the highest thing. CHUCK: Yup! ASHE: Yeah, I like that. The only thing that worries me about option pricing is it becoming 'a la carte' where they're kind of trying to pick in shoes, what things you kind of like hit the prices right like perfect price. And sometimes, the product end up suffering on the other end because there are things that, because they're focusing specifically on price and not on value, that something gets missed. I would rathen them pay more and be 10x happier than pay a little bit less and be 10x less happy. ERIC: Yeah. Whenever I do option pricing, it's always you have A, which is bare bones, A+B, which is bare bones + maybe some automation stuff that you're wanting, and then A+B+C, which is even more. I've tried a la carte and it's never -- I've always would have to pad each item individually a lot to count for just the internal dependencies, like you might need A and B in order for C to work, but if they don't pick B, you have to build half of the B anyways. So it's like, you just want to bang your head on the table trying to figure how to make that work. So I do, I give the options and most of the time actually, the client comes back and say "I want A and I want C, do you have an option for that? Can you give me a new quote with that?" And that I can actually go back and redo the option pricing to kind of make A+C be the second item. So yeah, that's something good; I use that on my hourly ones, too. CHUCK: Okay, as far as estimates go, I'm kind of in the same camp as you guys - how long will it take, how confident am I, how much padding do I have to add. Are there any other aspects of fixed bids that we need to hit before we go to the picks? ERIC: We've mentioned it before, if a client's asking for a fixed bid, don't be afraid to dig in to 'Why'. Most of the time, they want a fixed bid because they want to fix their budget on it. And you can do the same thing off an hourly by putting a cap. So instead of a fixed bid of $10,000, you can say "I'm going to do...(I can't do math today) 100 hours at $100 an hour". And they get the same, like you're only going to spend this much money, and then you get to keep the scope kind of variable. If that's the only concern they have, is the budget, I would say that's actually a better thing to do than to do a fixed bid where you have scope fixed and you could, as a consultant, take on a lot of the risk. CHUCK: Yeah. And then as you move along through the project, you just make sure you're communicating "We're approaching our cap. It looks like we're only going to be able to fit in a couple more features, which ones are the critical ones?" and then they can decide well, if they need them all, then they can extend the contract or sign a new contract with more hours or something. ERIC: Yeah. And actually on every invoice on those type of projects, I say like "You're at 35 out of 100; you're at 65th out of 100". So, in addition to my normal weekly emails or whatever we end up doing, they have it whenever they're sort of paying stuff like "Okay, we're running out of this, our budget's running out" and they can figure out if they need to renew it or do whatever. CHUCK: Alright, sounds terrific! Well, let's get into the picks. Ashe, what are your picks? ASHE: Sure! So I've kind of been on a self-improvement and community-improvement bent for the past few months, and I don't know (if) I haven't picked this thing before, but my first pick is a talk that Joe Kutner just did like last week at Big Ruby called "Healthy Programmer". It's up on Confreaks, and he's also writing a book that is about basically how we tune our bodies and our lifestyles to be healthier. So the talk is, I'll say like 45 minutes long, it's a really great talk; I really enjoyed it. And I picked up his book so I'm hoping to read that one soon. CHUCK: Which conference is that at? ASHE: Big Ruby. CHUCK: Big Ruby. Okay. ASHE: The second one is a app called "DuoLingo", which is game of 5 language learning. So right now, I'm re-learning all of the Spanish that I learned in high school but have partially forgotten. They have a really great site and a really awesome iPhone app, and it's the best thing I've seen so far to be able to teach you in like short snippets how to learn a language. It provides a bunch of different ways to learn a language, which is neat. So I'm learning Spanish now and thinking about doing German next, which is kind of neat. My third one is, last week I was at Ruby Midwest and I gave a talk; I'm basically like being better people in the community. We started hashtag called "#RubyThanks". So it's just going out of your way to thank somebody that helped you in some way, either project that they released or somebody who mentored you or somebody who's basically just made the community better. The idea is just publicly thank them in a way that's visible to everybody so it makes them feel good. And it kind of goes back into this like "We're a big family, in which we treat each other like a family, and we don't thank each other enough." So it's just RubyThanks, #RubyThanks. And then my last one is an Indiegogo campaign for a woman that lives in Nairobi, Kenya. She got accepted into Hacker School, and she's working on raising funds to come to United States, and to buy a new computer, and to be able to basically afford coming here and doing all the things that she like to do while she's here. It's called "Becoming a Better Programmer", and she has a neat little story up there. CHUCK: Awesome! That sounds really cool. Eric, what are your picks? ERIC: I got one, it's a blog post article titled "Wall Street Journal adaptation from Present Shock". I guess Present Shock is a book that's coming out or it's already out, I can't tell. But, the post talks a lot about how we're kind of looking at time right now -- you should read it, it's really good. But the summary is kind of 'Right now we look at our time and how computer looks at time, and that every second, every minute is basically the same as the previous one. And so we're trying to cram in as much work into that while in reality, biologically, physiologically, it's not; you're time at night is different in your time in the morning. And instead of thinking everything as the same, you need to account for that fact'. I think as a freelancer, it's a big deal because I've had times where I need to do dev early in the morning because that's when I'm most productive, and late at night I really can't do dev just because my brain shuts down. And I know that by myself. So [inaudible] article talks about, I guess there's some studies that have come out about that sort of topic, too, and they're linked in there. So, that's my pick for the week. CHUCK: Awesome! Alright, my first pick this week is going to be "Ruby Heroes", you can go to rubyheroes.com. If you have somebody who is in the Ruby community that you really admire or really want to say thanks to, you can go and nominate them there. I'm kind of having a hard time picking stuff because [laughs] I really don't know where to go. One other one I do want to pick though is a program that I've been using for a long time for IRC Chats, and it's called "Colloquy". Some of the folks in the Ruby Rogues community actually started the channel for Ruby Rogues on the freenode IRC servers, so it's been kind of fun to go and see what they're talking about there. So anyway, those are my picks; I'll put links to the show notes. And then, Jeff also had a pick; he had to take off. His pick is "Value-Based Fees Charge and Get What You're Worth", and we'll put a link to that in the show notes as well. Also, within the next few weeks, I just want to let you know, we're going to be changing the name of the show from the 'Ruby Freelancers Show' to just 'The Freelancers Show'. So if you're interested, we're just changing it to kind of better emphasize the focus of the show, which is Freelancing and not really Ruby. Anyway, you'll see a new logo, you'll see a little bit change on the web page, but it's still the same show and we still got a bunch of stuff going on here. That's all I've got. So, we'll wrap the show up, we'll catch you all next week!