Panel Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) Eric Davis (twitter github blog) Evan Light (twitter github blog) Jeff Schoolcraft (twitter github blog) Discussion Fixed bid Time and materials Give a budget to the client Scope creep Do you renegotiate the contract on scope creep? Short fixed bids can help manage costs and risk Customer management Fixed vs. Hourly is a discussion of risk Provide options for a fixed bid Multipliers for each unknown Risk is added for each new technology added to the stack Alan Weiss Start up with a courting period and then renegotiate after the courting period Shorten the scope of the project When you lower your bid, remove features (value) from the bid Charge more! Picks Find a Mastermind or Group of people who do what you do (Chuck) Heil PR-40 Microphone (Chuck) Other dynamic (Chuck) Behringer XENYX (Chuck) Roland R-05 (Chuck) Resounder (Chuck) Adobe Audition (Chuck) Million Dollar Consulting (Eric) The Consulting Bible (Eric) Peepcode Play by Play (Eric) Destroy All Software (Eric) (anti-pick) iMac Microphone (Evan) (anti-pick) Eric Davis' Internet Connection (Evan) Math Minute Additions (Jeff) Steel City Ruby Conf (Jeff) Mass Effect 3 (Jeff) Star Wars the Old Republic (Evan) Transcript CHUCK: Anyway I’ve got to hang up and get off so-- EVAN: Yeah, whatever. ERIC: Yeah you got what you need out of us. I see. CHUCK: Yeah exactly. EVAN:  At least you kiss us after you f--- us. JEFF: That has got to be the sound. CHUCK: Hey everybody! Welcome back to the Ruby Freelancer Show. On today’s panel we have Eric Davis. ERIC: Hello. CHUCK: We also have Evan Light. EVAN: Hi! CHUCK: And we also have Jeff Schoolcraft. JEFF: What's up? CHUCK: Now we’ve kind of been a quite bunch this morning, so we have to see how the show goes. So we were discussing what we want to talk about and one of the things that somebody brought up (and I’ve been asked a few times) is whether or not to take fixed bids. And I'm pretty sure I know what you guys are going to say, so if anyone wants to chime in and share their opinion on whether fixed bids or hourly, or either one or both are okay, go ahead. ERIC:   Well why don’t we start with actually defining what fixed bid is, because I see people say, don’t do fixed bids. But they actually don’t mean the same thing on someone else. CHUCK: Okay, so when I say fixed bids, what do you think? ERIC: For me, it’s basically a set cost, typically a set of features and then there will typically be like a set deadline which goes wishing by usually. CHUCK: Right, and then the other side of the spectrum is every hour I work, you pay me X amount of money right? ERIC: Yeah and some people consider that hourly. CHUCK: What else would you consider hourly? JEFF: Not government based, we will call fixed bid from fixed price and that's all the expenses everything, you are doing for whatever scope the project is, rolls up to some big number. And the other to way to do, is time and materials. So, you charge for every minute you work on that project and every pencil you buy or whatever you do to clear it up. But that is the other, I don’t know, vernacular terms I heard for those two billing concepts. CHUCK: Right. I want to see you code with a pencil, that would be fun. JEFF: Sometimes it will be faster. CHUCK: It's easier to debug. You just turn it over and use the eraser right? ERIC: Yeah I actually do it lot on index cards, when modelling or whatever, just kind of write stuff on index card. If it's not going to look like it's going to relay just throw the index card away. It’s a lot faster than removing code. CHUCK: That's true. That’s kind of an interesting planning phase or I guess modelling phase. And you can do agile, so that you are consistently updating your model as you code.

 
CHUCK:

Anyway I’ve got to hang up and get off so—

 

EVAN: Yeah, whatever. 

 

ERIC: Yeah you got what you need out of us. I see. 

 

CHUCK: Yeah exactly. 

 

EVAN: At least you kiss us after you f--- us. 

 

JEFF: That has got to be the sound.  

 

CHUCK: Hey everybody! Welcome back to the Ruby Freelancer Show. On today’s panel we have Eric Davis. 

 

ERIC: Hello. 

 

CHUCK: We also have Evan Light. 

 

EVAN: Hi!

 

    CHUCK: And we also have Jeff Schoolcraft. 

 

JEFF: What's up? 

 

CHUCK: Now we’ve kind of been a quite bunch this morning, so we have to see how the show goes. So we were discussing what we want to talk about and one of the things that somebody brought up (and I’ve been asked a few times) is whether or not to take fixed bids. And I'm pretty sure I know what you guys are going to say, so if anyone wants to chime in and share their opinion on whether fixed bids or hourly, or either one or both are okay, go ahead. 

 

ERIC: Well why don’t we start with actually defining what fixed bid is, because I see people say, don’t do fixed bids. But they actually don’t mean the same thing on someone else. 

 

CHUCK: Okay, so when I say fixed bids, what do you think? 

 

ERIC: For me, it’s basically a set cost, typically a set of features and then there will typically be like a set deadline which goes wishing by usually. 

 

CHUCK:Right, and then the other side of the spectrum is every hour I work, you pay me X amount of money right? 

 

ERIC: Yeah and some people consider that hourly. 

 

CHUCK: What else would you consider hourly? 

 

JEFF: Not government based, we will call fixed bid from fixed price and that's all the expenses everything, you are doing for whatever scope the project is, rolls up to some big number. And the other to way to do, is time and materials. So, you charge for every minute you work on that project and every pencil you buy or whatever you do to clear it up. But that is the other, I don’t know, vernacular terms I heard for those two billing concepts. 

 

CHUCK: Right. I want to see you code with a pencil, that would be fun. 

 

JEFF: Sometimes it will be faster. 

 

CHUCK: It's easier to debug. You just turn it over and use the eraser right? 

 

ERIC: Yeah I actually do it lot on index cards, when modelling or whatever, just kind of write stuff on index card. If it's not going to look like it's going to relay just throw the index card away. It’s a lot faster than removing code. 

 

CHUCK: That's true. That’s kind of an interesting planning phase or I guess modelling phase. And you can do agile, so that you are consistently updating your model as you code. So one other method or means of billing that I've heard of is where, they do kind of a fixed bid per feature. So, if the client adds more features, then they will be estimated to a cost and then, once you agree on the cost for that feature, then it goes on the pipeline. 

 

EVAN: Yeah, I only recently read about people doing that and personally, that would scare the hell out of me, because then now you are on the hook for a whole bunch of mini estimates. Granted, I suppose, perhaps, variants on a per feature based on estimate for a feature bases might not be perceived that badly by the client, because the dollar amount involved is smaller. But still, just having to do all those individual estimates, and I don’t know— I sort of, I say that at the same time, let me back up. The way I tend do project estimation, (so I guess this topic goes off into the weeds a little), is that I try to get something resembling, a spec from the customer. And if I don't get it, then pull deep until I something like it. And I go through and I assign point values, id use the Fibonacci system. I have some rough idea of when I assign points, roughly how many hours I tend to require per point. So that tells me that if I charge an hourly rate, because I don't feel comfortable charging fixed, so getting back to point, then that tells me approximately how much it’s going to cost. Usually I’m pretty good within, (I do know what the margin of error is) but maybe plus or minus 20% overall. 

 

ERIC: But see, I mean, like I do “agile” stuff, but this is something that I get a good sneak out whenever people talk about on a consulting. They are always saying I allocate this as points and then I make the points into hours. Well, correct agile, you're not supposed to do that.

Points are not supposed to be time-based. Every consultant I ever know does that and it's just a

funny little point there. 

 

JEFF: I think everybody— 

 

EVAN: Most of us don’t do agile; I guess most of us do what we call agile, when everyone does it a little differently. And of course it’s only the people who are masters who have it right. (It’s not supposed to be sarcastic.) 

 

CHUCK: Yeah, well one thing that I've noticed is that, a lot of times you have kind of stakeholder, or somebody that really actually, they want a number that they can do something with. And points is not something that they can keep track of. You know, so to them, it doesn't mean anything, because it's not how long it's going to take and it's not how much it is going to cost and it's not how many resources it's going to use up, it’s just a number. Sometimes you are kind of forced into that. And in a lot of cases, your client wants some kind of time or budget estimate and so I found that the points and then the rough conversion is a really good way of getting there. Because, I do basically the same thing if they wanna know how long it is going to take and therefore what the budget is going to be because I do bill hourly. That's what I do, I use points. Now I use an exponential scale instead of Fibonacci scale, but it's the same general principle. So then I just go in and I say, well three points is roughly one day’s worth of work and you know, it should take about this long and blah, blah, blah. Now, in some cases I found that the points actually do slide one way or the other. So technically if I'm working a 20-hour week, that should be about eight points or something on my scale. Anyway one thing that I've seen is that, sometimes I will get 6 points in a week working at 20-hour week. And in another projects, I'll get 10 points in a week. And so as far as sprints and estimations and stuff like that go, it does get more accurate as I go. Generally it’s a gut feel, but you know, if I have to translate it then I'll translate it, 2 points is half a day, 4 points is one day, 8 points is two full days of work. 

 

EVAN: We are saying the same thing. 

 

ERIC: But I mean, my thing is that, why do you do that translation? Why do you say 2 points is four hours? Why don't you just say 4 hours? Then you have a little bit of flexibility. So it’s going to be high, so it's going to be low, I mean that is estimating. I mean why you have that middle in there. It just doesn't make sense. 

 

EVAN: Because a need to take an arbitrary number and picking an arbitrary number is easier when I have a smaller set of values to choose from, than when I have the infinite range of point values or infinite range of integer value hours. 

 

CHUCK: Yeah, and I also want to point out, that the only time I ever do that conversion at all is when the client is saying “how long”. They want to know time and money. 

 

EVAN: Exactly and it's exactly why I do it too. So that way I can give them a rough hour amount so I can get them a nonbinding estimate. 

 

CHUCK: Yeah, and that's exactly it. It's like, look, these points really are, you know, for my method of keeping track of how efficient I am and to help me kind of track my coding and help me get better. But this is the best estimate I have on hand and so this is the best estimate I can give you as by a roughly translating this. So that's pretty much that. 

 

ERIC: I still don't get it but— 

 

EVAN: Do you want to pop the stack back to fixed bid or hourly? 

 

CHUCK: Right. So the one fella that I was talking to yesterday, he was talking like one of those people that is toying with the idea of going freelance, but one of those people that you never think will actually do it. (He listens to this show, so I'll probably get an e-mail from him.) Anyway, so he was talking to another guy and this guy is a flash game developer, and that guy was saying, look, you got to do fixed bid on everything because it’s the only way that you’d make good money. Then he came and talked to me and I said, don't ever do a fixed bid! Don't do it. Don't do it. So me and the guy who recommended fixed bids got into a little bit of a discussion. Basically in his arena, you have these boutique shops that pretty much everybody goes to, to get their flash games built and those boutique shops, he can actually go in and undercut them with a fixed bid, that still gets him like two or three times the rate that he would get if he billed hourly. So in those circumstances it makes sense. Now in our field, I just don't know, it seems like there are quite a few Ruby or Rails developers out there that charge about what we charge. And there are some people out there that just don't get it, that charge way less. So, in our situation, I just don't see the upside of taking the risk on it, because you're probably going to bid too low if you're going to get the bid. 

 

EVAN: So, another freelancer out there, who at least three or maybe four of us now, Mike, he says roughly what I tend to think too about fixed bid. And that said if someone is is going to ask me about fixed bid, I'm going to take my hourly rate and then I'm going to do an estimate based on my hourly rate in the fashion that you and I have described Chuck. And then I’d take that number and I multiply it by factor about three or four. That's how I—because to me, the problem with fixed bid is, it’s all about risk management. If I have to get a fixed bid, there is no way in hell I'm going to take my hourly rate estimate and just say, here is my fixed bid because I know there's going to be some margin of error maybe plus or minus 20 or something like that. I also knew that customers sometimes do feature creeps. So, are you going to take feature creep into account? Or are you just going to tell your customer, no we have to renegotiate the contract every time you want to change anything, which by the way, that's more like the government model, right Jeff? That was a lot of fun back then. You know every time you want to change the contract, well, here every time I change the products, lets renegotiate the statement of work and that's not so much fun. So you wanna take all that stuff into account, so that way, your ass is covered. (Oh, hopefully that wasn't too bad a word.) 

 

CHUCK: So it seems like Eric has an opinion. 

 

ERIC: Yes, plenty of them but I kind of think of time. So when I first started, I did hourly and fixed. Then I was like, of fixed is a great thing, then I went to, fixed is a bad thing, then I went back to fixed is a good thing and I'm actually coming back at fixed can be a good thing. And it's just like, kind of what you are saying Evan, it's a risk thing. 

 

EVAN: Well, to me almost everything about being a contractor is to make some form of risk management. 

 

CHUCK: Right. Well, my thinking and the way that I manage fixed bid, because I have bid a couple of projects fixed and I

didn't get them because I was way too high. But basically, what I do is, I give him, here's the best case. So, if everything goes exactly the plan and there no unforeseen things at all, whatsoever, then here's my best case estimate and then I go, here is my worst case estimate. The worst case estimate is usually at least double, the best case estimate. Just because it's like, look, if everything I can think off goes wrong on this, then this is what it's going to take. In some cases, the unknowns make the risk unbounded, but you can’t put that on there. So what you do is, you just say, okay well, this is the about as bad as I see this feature going and so then what you do, is I get that it’s at least double. Then usually, I pad that by about 100%, so that gets me a right around that 3 to 4 times that Mike was talking about. (You know, that Evans said Mike recommends.) And when I do that, usually I come back and go, holy cow that’s really high! 

 

EVAN: (Let’s do it hourly!) 

 

CHUCK: Yeah. Well, that’s exactly what I do, is then I send them, well, okay, here is the best case and here is my worst case. So, if we go hourly, we are probably going fall somewhere right in the middle of this and if you’re comfortable with that, then we can do that, we can put an upper limit on the cost. So that, when we get to 6 grand, or 8 grand or 10 grand or whatever your number is, then I just stop working. Then we can revaluate and say, okay, these couple of features absolutely have to go in and the rest of this stuff we are going to throw out. I also tell them, ruthlessly cut out anything you don't need, in that way we control cost because usually they are worried about budget at that point. But once I send them that, then they are usually looking at it and going, okay, well if you think you're going to fall within that range, then we can go with it. Usually, I'm much closer to the lower bid than the higher bid, you know, the best case and the worst case, because things usually don't go that wrong all the time. 

 

ERIC: That's kind of something I've seen a lot. A lot of people do the time and material or hourly rate, but they still give a budget to the client. So, (we’ll just use round numbers here) we’ll say $100 an hour and we’ll give you 40-hour budget. We don't know what we are going to get done; we are going to try to get these things done. I've talked to a lot of clients and whenever they hear that, they immediately translate that into a $4000 fixed bid. Now, they know there might be stuff that's out of scope, they know stuff might come in scope, this and that. But to the client’s eyes, a lot of the hourly rates, (especially if there is a budget of hours) it looks like a fixed bid. Like they have this time period, this amount of money they are paying, and they are going to get these features plus or minus on all of this. I mean, that's why I keep coming back to fixed bid. In my own stuff its like, wouldn’t it be easier to just have, here's what it's going to happen, the client doesn't have to worry about nit-picking on hours. Like, you charge me five minutes for that phone call, why do you charge me for that? And just kind of let them worry about their deadline, their cost and actually being a participant in the project. It's really murky with all of this, but just, I don't know, I’m actually leaning more towards doing less hourly and more fixed bid. What I actually started doing is, when I do fixed bid, I try to make them really short, so alike a one or two-week cycle per bid. That way there is less chance of everything going wrong and it's also easier for the client to stomach, because they might get a week here and maybe next one get a week, another week and maybe two weeks after that. 

 

CHUCK: Yeah, that makes sense. I mean, the thing that we are really talking about here is risk and you know, both you and Evan have brought it up, is risk. And so, I mean if you can keep your risk to a couple of weeks that makes a lot of sense. But there is always that off-chance that you're going to wind up instead, spending three or four weeks on what you’ve bid those two weeks to get done. 

 

EVAN: Or there is the off-chance that the client is going to drag you in the meetings on a nonstop basis, so then you'll be on the phone the whole time and you won't get too much of your work done, but you have to get the work done. So then, you're working really, really late and then you are going to spend all of your time working on this project. And you wouldn't have gotten the value out of the project that you were hoping to get. 

 

CHUCK: Right. 

 

JEFF: I think some of that is customer management. But I mean it’s a fairly polarizing topic I think. There are folks that say if you don’t charge hourly, then you are basically opt to screw your clients and the other side, if you don't charge per project and then even further by value, then you are screwing yourself or your more concerned with your prerogative is not to be as fast possible, because you're not going to be able to charge as many hours. 

 

EVAN: Right. My response is really not that polar. I lean toward hourly, but my response will still be, “it depends”. It's just that, when I say, it depends, most of the projects that I've approached hourly, is usually assumed going in by the client. If I was working with a different market, like I think Eric probably, maybe you Jeff touched more markets than I do, because I tend to end up working with start-ups an awful, awful lot. But if you're touching a market, where a lot of the providers are charging some kind of fixed bid, and you have some idea what they might charge, then if you offer a smaller dollar amount and got the job done in the same time in just as well or better, you give them more value. Then you might still make a lot of money than if you came in an hourly. And in I such a situation, I would be okay with that. I just don't find myself in that situation. 

 

CHUCK: Right. So the up side of fixed bids is that you could wind up making much more per hour. 

 

EVAN: And your customer could still come out of hand too. 

 

CHUCK: Right, because it cost them less and got done faster. 

 

EVAN: Right. 

 

ERIC: Yes. I guess that's kind of a distinction. One of my clients, I remember all of the rules they had. They had rules of how they bid. But the one that keeps in my mind is, if the project is about something that is vague and going to change, (so like a stereotypical start up idea) it has to be hourly because there's no way for a fixed amount of time. If it's kind of a stable, like, here is the spec and they know how it is going to work, then that's where fixed bid actually works better. And actually that works in my case. Most of the work I do is not cookie cutter but it’s pretty much the same thing. Like all my work is in *** project, and so I know where all the bugs, I know all stuff in it. And there are certain patterns that I come across every time. So, it gets easier to do fixed in that case than it does in hourly. 

 

CHUCK: All right. Yeah, that makes a lot sense and see, that’s the other thing I think with fixed bids and with scope in general, is that, if you know the problem domain and you it really well, then it's much, much easier to give an accurate fixed bid. 

 

EVAN: Right. The risk is reduced because you understand the domain that much better. The problem with being a developer in general is that, we are routinely asked to solve problems we haven’t solved before and therefore, (at least by degrees that, we haven’t solved before) and therefore there's always going to be degrees of risk associated, usually, fairly large degrees or risk associated. Because we are trying to estimate around things we don't necessarily know that well. 

 

CHUCK: Right. And that entails a certain amount of risk, because just don't know. 

 

EVAN: They are building the umpteenth millionth Facebook-like app, that's one thing, If they want to have them kind of unique feature, like recently I have write a recommendation. I've never done that before. So, is another case of, well, I took it, broke it down to a bunch of pieces and estimated it. And was pretty accurate, but there was more risk there as far as I was concerned, for example. 

 

CHUCK: Yeah, absolutely. So are there any circumstances under which you would take fixed bid? Evan? 

 

EVAN: I think you nailed one of them. If I really knew the problem domain that well, and if I knew, I guess it comes, right, it always comes down the rest of-- if I knew what the customer’s budget was, in advanced, if I knew the problem domain really well, if I have some idea what competitors were bidding at and if I saw an opportunity to bid lower and everyone wins and I actually have less risk going fixed than hourly, then sure. But to me, most of the time, I'm probably going to find (I tend to find) less risk in bidding hourly and telling the customer that there will be some degree of variance, giving them some estimation of what I believe that variance to be. 

 

CHUCK: Right. 

 

EVAN: So it depends, but I lean toward hourly, as I said earlier. 

 

JEFF: So the flip side of this, I guess, from the customer’s standpoint is, it’s the other polarizing reaction. I mean, you have fixed bid so I can allocate a budget and there's one of my clients, (this is the one that I'm going to fire) but the client that they work for, basically they wanted an estimate for all the junk that could possibly think of, putting into the system we work on, so they could come up with an annual budget for their IT. And this is what a multi-, multi-million dollar big Pharma drug company, but they need to budget. They need a line that says it’s going to be $500 million or $500K or whatever, for IT cost, for this thing or $100K for this or whatever. So, on one hand, they want to know what it is so they can budget for it on an annual basis or on some regular basis. And the flip side of that argument is, if we go hourly then, you fall on the situation, this never gets done. You're always at the 80%, we‘re almost done and if I keep throwing money out on whoever then, eventually I'll get it solved. But, so this is the other side of the argument. 

 

EVAN: Yeah. I found that there are, in the past I’ve dealt with some customers that have been burned by the other contractors and that causes them to wanna go fixed bid when talk. When I say “burned”, it's a situation that you describe Jeff, where something is almost done and it's almost done forever and yet nothing ever ships. And what I usually tell customers, there is, you know, lets have some kind of a project manager tool, usually I'm using Pivotal Tracker although there was one client that was using, oh my goodness, red line and then that's going to be the ldb episode lead in right there. So what I tell them is, let’s take one iteration, usually a couple of weeks, let's take a couple of weeks we’ll throw tasks in there and we’ll see how well I'll get them done. If I'm way off base and you don't feel comfortable with it, fire me. If you are feeling comfortable with what I'm doing, keep me around. And let’s do that on a regular basis. That's what I tell all the people that I am perfectly fine with that. Because I absolutely do not want to take advantage of my customers, because I have a personal issue of how the government work and it's one of the reasons why I escaped. Because I couldn't stand seeing back taxpayer money pissed away. 

 

CHUCK: Yeah now they just piss it away on somebody else. 

 

EVAN: Now they just piss it away on somebody else. But at least I can look at myself in the mirror every morning. Those people I guess they can't do, but they have lower standards, what can I say. Yeah, I’m just going to insult all the government contractors’ right there, boom. 

 

CHUCK: Nice. 

 

EVAN: Yeah. 

 

CHUCK: Alright, so one other question I have then is, let’s say you are going to put the other fixed bid. Evan, you mentioned, you talked about how you would estimate that, but I don't think we have heard from Eric, Eric how do you estimate stuff like that? 

 

ERIC: So, I think we talk it for, I basically go back and forth and try to get a list of all the features, build a kind of spec that people are doing. And then I just kind of go from there and start going off my past history, like how long that will take, like this or that. And then, whenever you do fixed bids, you have to pad it a little bit. There is project management, there’s “unknowns”, there’s a whole bunch of stuff that’s going to come up. Most of the stuff I estimate, I do know what it would be called, but I stole it from someone, but it’s basically, each big bug or each feature is either, one hour, two hours, four hours, six hours, eight hours and then it's like 16, 32, 64, you know, like it's dreamingly high numbers. 

 

CHUCK: Right. 

 

ERIC: And so, I basically do all that for myself and then kind of air on the side of, like, stuffs going wrong, stuff going to hit the fan and just break randomly. Get all that and then this is something I learned, like from Alan Weiss or whatever is what I heard from him, but, let’s say, I have a bid of $2000 for features ABC. What I would do is I will prepare a proposal, say okay, it's $2000 for A, B and C. Or if you want ABC and D, its $3000 or if you want a

A, B, C, D and E, it’s $4000. The whole point of that is, you’re giving them a fixed bid, but you’re not just giving them one thing that they have two say yes or no on, but you are giving them options. And so sometimes a client will say, well we are on a tight budget, were going to pick the low one now, maybe we can do this stuff later. If the client just wants the stuff and wants it to work, they might be, Wow! I can't consider E at all! E is going to be amazing! So, they will take the higher bid and then it actually translates to more work for you. Like more billable work or whatever. Basically, from now, then you just work it and I keep track of all my time, so, even though a bid it as a fixed, I consider an hourly and I work as fast as I can to get a good quality product out the door. Then at the end of it, I’ll come back and do retrospective and see actually where I was of my bidding, it I was high or low, or if there are certain areas I messed up and the fact that I back into the next bid. So, say some integration with Twitter, it happened a lot faster this time, then I know next time I can integrate with Twitter a lot easier than I normally think. 

 

CHUCK: Right. So it sounds like you more or less the estimate how many hours it's going to take. DO you just multiply by your hourly rate or with the buffer, obviously, but--- 

 

ERIC: Yeah I'm trying to remember the last one that I did. I think is, I did add like another 50% to account for like project management and then scripts. And then I

times that by my hourly rate. Say it’s like 3,875 or whatever; I'll round up 4000 just to make it easier to talk about. 

 

CHUCK: Right. So Jeff, we’ve kind of heard how we all estimate. Do you kind of do the same thing? 

 

JEFF: Yeah, about the same thing. I mean, and I chop all with all the fudge factor, I mean I was sitting, (I don’t know how many years ago) been myself for engineering course in college and like the end of my junior year, beginning of senior year, somewhere around that. Then they were talking about software estimation. This is the guy that did, our professor did some work with neighbour research labs and he would always be the same way. Then you do all the stuff and you come with the estimate and you multiply it by four and then you're still going to be wrong. And I've seen a bunch of that, I mean, I basically, I tried to come up with close and I count individual items, I have multipliers for stuff when I don't know new technology makes it more expensive, if I've never done something, then that makes it more expensive than I guess past relationships with the clients or how I think the client is, how they are going to be on a day-to-day basis. That also gets its factored in some multiple. 

 

EVAN:That’s a lot of factors. 

 

JEFF: It is. I was trying to dig up, I think it was in a Reddit discussion. There was a similar question like, how do you quote a project? And they were talking about, I mean they have multipliers for everything and I’ve never gone that crazy. (You can go back to risk,) but I mean, if it’s a new technology, the more technology you try to use in a single project— 

 

EVAN: (the more risk, sure.) 

 

JEFF: Right the bigger, the higher likelihood that you are screwed. 

 

EVAN:(Yes, same thing.)

 

JEFF: So the next project is going to be Redis and whatever and whatever and you’ve only done Active Record with Post or something. You're screwed. So that's one. And then if you spend all of your time doing social networking for your next Facebook app and somebody asks you to build some huge data class file and then sure it sounds like it should fairly simple or straightforward or whatever you think it is. But, if you've never done it, you have no idea. So you have no history, that's another risk. And the other thing we haven't talked about or maybe we did and I was searching for that question, but sort of a hybrid approach, there are two versions, but before I get to that, it was Alan Weiss that talked about Eric’s how to present that offer, some catchy title, like how to guarantee your bid will always be accepted or whatever. But if you always offer the low rates, you wouldn't do this if you respected yourself. The client won’t do that if is they respected their selves and their product. So it’s just the bare minimum cut rate features. And the middle is, your estimate, did you actually wanna get accepted and then you offer some over-the-top extreme, like if they just have some huge bank of money and they want to throw it at you, then don't take that one. But the hybrid is sort of a, (I guess Evan talked about it a little bit in his hire me for a week or two at a time, we’ll review it later) we see a lot of people, that are trying to do fixed bid weekly or you buy me at the day or a week. But instead of paying hourly, you pay for some chunk of time. So you either get me for a day or you give get me for a week and it’s going to be close to, whatever, 6 hours or close to 30 hours for the week and we’ll see what I get done. But you bought chunks of time or sprints worth of time and do some works toward it and then do review at the end. 

 

CHUCK: Right. 

 

ERIC: That's a lot like how I have done it in the past and where instead of a fixed bid for six month project, it's more of like a fixed bid for like two weeks, which is like version 1 or version beta or whatever. And then iterate on that, so you have this feedback post you can come back to and say, okay, well, me as a business internally went really, really over on the estimate or whatever, so I can adjust for the next one. Over time it kind of paths itself out and figures it out and kind of get pretty close to it would be for just a straight hourly without a lot of headaches. 

 

EVAN: I mean when you get right down to it, for me it's, for me, I guess it keeps coming back to risk. It’s trying to size up what a client’s tolerance for risk is, versus my tolerance for risk and try to find the common ground, if the risk on common ground, if there isn’t then negotiations fail. If the risk then—well, you off to have a contract. 

 

ERIC: Yeah, I mean, that's business in general and business transactions, it’s a risk management. 

 

EVAN: Sure. 

 

ERIC: I mean, there is a risk of it taking too long, there is a risk of budget stuff. Over budget for the client which is actually good for you, bad for them. I mean, if you look at almost anything in business, you could see risk behind the scenes on things. Or just you know ignorance, stupidity, and arrogance. But those are the fun ones to play with. 

 

EVAN: Yeah, ignorance is the fun one, because when you are mentioning that sometimes I run into problems where the client, they might know their budget, but they really don't understand their timeline. Or there are some constraints that they have, that they are just not all conscientious of and that causes problems later. 

 

CHUCK: Right. And that's always interesting to try and draw those out, you know, so figure out where their budget is. Because a lot of times, if you are negotiating the contract and they don't want to tell you what they are willing to pay. They want to see if they can get the best deal possible. But you are doing this little dance to try and tease this out. Where, in a lot of cases it will be a whole lot easier if you knew what they were willing to pay, so you can tell them how much work you can get done for that amount. 

 

EVAN: I don't often really try to tease it out as such. I usually just tell them, here is what my estimate is in terms of time, here is my hour weekly rate and if they are okay with it, (if they are okay with it, they are okay with it) if they take issues with it, well we don't really have much more to discuss. And then if they want to just negotiate a little, usually means they summing the ballpark, then we talk. I want to keep it simple. I just don't like the play a lot of games, at least as I see it. And not seeing you guys do, I’m just talking about how I see it. 

 

CHUCK: Well your approach is pretty much what I

do too. It's just, you know, sometimes I felt, if they would just tell me how much— 

 

EVAN: Right and so I literally just ask them. Do you know what your budget is and are you willing to share it? And sometimes they just do and that makes things easier and then sometimes they tell me, and then they find out later, oh wait, out budget isn’t what we thought it was and then things get more complicated. 

 

CHUCK: Yeah. So, anyway. 

 

JEFF: And the other thing to go back and Alan Weiss again, like value based pricing, which is different than fixed bid pricing. And so it's not so much, you do price to cover the cost of the project but you are pricing based on how much value you are actually bringing. So, here is some code monkey that’s just adding another Facebook sign-in to their website or whatever. Then I don't know how much value you are bringing. And Alan Weiss is more like, traditional consulting. Like if you are some giant conglomerate and I can make you 25% more efficient during X and that saves you, or that allows you to make $600 million or more a year, or $600 million more of the 10 years, you shouldn't whine about paying me $600,000 for this four weeks’ worth of work, because my value for our ways that cost for you to actually give that. Then he always talks about asking for budget, which is interesting just see, the budget is interesting in the beginning, just so, if they are asking you for the next Facebook on Craig's list and their budget this $200, then I mean bid on getting another Facebook on Craigslist ad, $200 you're not going to do anything for $200. And for even $10,000 you're not going to get a ton done. Depending on where their budget is and what they're asking for, you can give the estimate and not waste your time trying to chase a lead that doesn’t have a realistic budget. But the flipside is he always talks about trying to find value, (and I don’t know how to do NSL first base.) I think you have to know the problem domain a little more and the stuff I'm doing is not maybe in the start-up page, you can actually, you are helping somebody build a product that will make the money. A lot of the times I'm supporting products that allow businesses to run their business. So, there's a value question on how much, so how much money do you have for this project and how much is it going to be worth to you when it is done? Or what is it going to be worth to you when it is done? 

 

CHUCK: Yeah, so real quick, I don’t think I ever heard of Alan Weiss. Can somebody give like a 30 second explanation of whom he is and why we should read his books? 

 

JEFF: He is some PhD who wrote value based pricing: the millionaires consulting toolkit. His tweets, I forgot what his Twitter is, some Bentley and his dog. He is really fond of his dog. That is the only thing I remember about him Twitter, his white dog. He wrote Value Based Pricing and among others, he got two day consulting workshop. He talks about how to bid projects, how to charge by values. I guess his claim to fame was he was \one of the first or few like, million-dollar consultant or something. 

 

CHUCK: Alright, cool and I have a funny feeling we are going to get some picks related to him anyway. But alright, so we talked quite a bit about the fixed bids and about some of the negotiation and things that we do to get these bids out there. How far do you negotiate on these bids? Let’s say you get a fixed bid and they basically tell you you're too high, do you try and come down at all? Or do you let them know that you might be willing to negotiate? Or do you just tell them, well, that is what it's going to cost and you know deal with it? 

 

ERIC: Well, this kind of comes from the Alan Weiss, because I’ve read probably half a dozen of his books and there’s one that cost $40 in Amazon for the Kindle and it’s worth it. One thing he says, if you fix bid at a value and the client says it needs to be cheaper than that, his recommendation is, you can lower your price but by lowering your price, you need to remove value from the client. So it the cline says, I need you to cut this in half, then you should cut the features in half, so the products only worth half as much. 

 

EVAN: Otherwise you are reducing your own value. 

 

CHUCK: Right. 

 

ERIC: Yes. 

 

JEFF: For no arbitrary reason other than they asked you. 

 

ERIC: And I mean to be honest, I've had a couple of clients and leads who would ask me to lower my price. They would pay the full price but they are asking just to see what kind of deal they would like, if they had a coupon, they would use a coupon and stuff. So if you start cutting features, they are like, well, I can cut off half of this stuff. They might say, wait we need that, we're going to pay the full price, so we are sorry. 

 

EVAN: Now we are just talking fixed bid here though, right? 

 

CHUCK: Yeah. 

 

EVAN: Okay. 

 

CHUCK: Yeah, but either way, I mean, I’ve seen the same thing with my hourly estimates, where they are like, holy cow! Because I will give them the best and worst case and I just tell them, look, you know, probably not even going to come close to the worst case, but sometimes the worst case number kind of scares them. So they are like, well maybe we can figure something else out and yeah I’ll scope the work down. I’ll be like, well, if we cut this stuff out, then it will cost less. And in a lot of cases, what they will do is, they will actually go to their feature list and start acting axing stuff. 

 

EVAN: But I tend to the estimates when I give it to them. I think that's what you said earlier too. When I give them the best and worst case, I tend to tell them, I think are going to be within some merge and probably of that best case and the worst case is really kind of out there, but you felt obligated or I felt obligated to give it to them. 

 

CHUCK: Right. 

 

EVAN:What I was going to mention is, in terms of hourly, I mean, in consideration as a contractor, the consistency of the work that we get. How long, or I guess I should say, how long a piece of work sustains us. How much money we make on over a period of time on a piece of work? So if I

have a client who is willing to take me for a decent chunk of hours on the on-going basis, the longer that on-going basis, to some degree, the more I am willing to reduce my hourly rate because I get that consistent work for a longer period of time. 

 

CHUCK: Yes, that's definitely true too and I’ve actually had people try and negotiate that way too and just say, well you know, if we are going to give you six months of work, versus two months of work, then do we get a little bit better rate? And sometimes I am willing to do that and sometimes if I don't know a lot about a client and I am just not sure--- 

 

EVAN:If you're going to be there in six-months. 

 

CHUCK: Right exactly. Then in a lot of cases, I’ll just say no, I don't negotiate on rate. 

 

EVAN:Let me suggest a middle ground. Because this is what I was doing with one client and that's that we sort of have a courting period with the first contract, where this first term would be in a particular rate and then we decided, when we try to re-approach it after that first contract, we’ll see how he felt about each other. So that way, you are given some assurance that you’ll always have this X amount of work and that they are not just trying to buy you for a lower rate for that same period of time. 

 

CHUCK: I like that. 

 

ERIC: Here’s another way, because I've had that and it kind of backfired a little bit. I mean, make your project shorter, whether it's hourly or fixed. Like, if you're trying to bid on one month project, make it a one week. I mean, you could figure out how like, the court with someone in a week, it's not a lot of work and they don't have to put up a lot of cash and worst case for them, they lose a week’s worth of funding for the project. You know better that and then make it open ended on your contract, where they can renew it or that you can do another fixed bid right afterwards. 

 

EVAN:I don't know. You see I would hesitate on that, if only because it's very rare that I have a

good sense of a client in the project within the first week. I have some, but I've only had one client where, within a couple of weeks, I had a very firm opinion in and that was that and that was the client that I fired. 

 

ERIC: Maybe I got luckier. Maybe I do more of the pre-courting, going back and forth on e-mail for that then. 

 

EVAN: Possibly, yeah. 

 

CHUCK: All right, well we are about the point where we need to do the picks, so unless there are any final things you guys wanna ad? Go and do that. 

 

ERIC: Yeah there is one final thing. Whether you do fixed or hourly or anything else, charge more. That's it. 

 

EVAN: Yup. I agree with that, because Eric gave me on about charging more and he was right. 

 

CHUCK: Yeah and I had, it was funny when I first went freelance 

 

EVAN: You want to charge more. 

 

CHUCK: Yes. 

 

EVAN: After Eric gave all about charging more. 

 

CHUCK: Yeah, it was actually kind of funny, because when I was first thinking about going freelance, I think I was thinking of charging like $65 an hour or something. And you guys were all like, No! You are WAY, way too low! And then I was like, who is going to pay me more than that to do this work? And so I raise my rates a little just to see and I think I went to $80 and yeah, it was no problem finding work. And you guys are still egging me on so, now I am significantly higher than that and you know people are still finding the work. And the thing is, it's just you have to recognize that there is a lot of value to what you have to offer and probably more than you think. So my thing with most people now is, I'm like, what are you thinking about charging? And in most cases I look at them and tell them to at least double it. And a lot of that came out of what you guys told me, with a lot of this. And it's really been helpful too to kind of fall in with the group of freelancers pretty early in my freelancing career and to have a lot of great advice from guys like you. So that's another recommendation that I would make. In fact, I'm going to make that pick. So let's get into the picks. I’ll go first and the first one is, seriously find some kind of mastermind, or group that you can talk things over with. Even if they are not freelancers like you are, I mean, you can find other service providers or people in your area or you can get online see if you can find a group of people doing something similar to what to do. You know, some service-based business and just have a mind share. Because in a lot of cases, they have encountered stuff and they can save you a ton of trouble and time, doing things that you really shouldn't worry about. 

 

EVAN:And by the way, it's worth, just to mention, that where this whole podcast came from, because the four of us already basically did that. Working that as a group. 

 

CHUCK: Yup. But it’s made a huge difference for me and my business. Honestly I probably wouldn't have been able to start up some of the podcast that I have and things, if I didn't have the freedom that's offered by freelancing. I don't know if I would’ve lasted if I hadn’t talked to you guys and gotten some of the advice that I did. It really, really made a huge difference. 

 

EVAN: And you can send bonuses to all of us. Let's give you addresses for that. 

 

CHUCK: Yeah, I should send you guys something really, really nice. 

 

ERIC: No, I mean in all honesty though, like what you're doing now, is how your helping the next set of people who are freelancing. I mean, when I got started there is a group of freelancers that helped me, I helped some other people, some other group and then they go out and help other people. I mean it's more of a community paying it forward type thing and that’s really what makes it good. 

 

CHUCK: Yeah, I am not in to paying anything forward, so you know. Anyway, so that's one pick. One other thing that I want to go into really quickly is, I have a lot of people ask me about what I use for my podcasting, what equipment I have and stuff and so I am going to pick about five things that I use in my podcasting and I will link them up. So the first one is my microphone and it’s Heil PR-40 Microphone. It's regularly a $400 microphone; I've seen it on Amazon for about $280. If you want something a little bit cheaper, there are some out there and I'll link it up. I don't remember what it is right at the moment, but there's another microphone out there that I highly recommend if you're not going to spring on that, and it's about $100 microphone. If you just want something to plug into your computer, or for a lot of good things about the blue snowball or Blue Yeti microphone. Anyways, so I am using the PR-40 Microphone. You really want to get dynamic microphone if you can help it and I'm not going to go into what that means. But anyway, that's kind of what you want. Then I have a mixer, it’s a Behringer XENYX 802 mixer. Behringer makes some awesome stuff, so if you want to go check their stuff out. it's just a great little mixer, it's an 8-channel mixer, works terrific and that's what I'm pushing all of my stuff through. And then it's going in R-09 HR digital audio recorder and they don't make the R-09 anymore, it’s not the Roland R-05, but it's a terrific little thing, so that's an Edirol. You don’t need to remember Edirol anymore, Roland bought them out so it’s Roland R-05 and I'm putting it in the show notes as we speak so I can remember that I recommended it. One other thing, that I've used on my iPad when I was inserting the audio myself is (let me find it here) it's called Resounder and it's a little sound board for your, it works on the iPod and the iPad or on your iPhone, so that's a great way to go if you want some kind of little sound effects mixing board. And finally, the last thing that I would recommend to you is Adobe Audition. Adobe Audition is a little, (well, it's not a little) it’s a pretty big application that you can use to edit your podcast. If you don’t want to spring, I think its $100 or $200; I actually got a deal on it, because I bought the Adobe Master Collection and so it is rather expensive. If you're not going to go that way and you have a Mac, then Garage Band works pretty well. But there are some other ones out there that I’ve heard recommended. And you know, as long as it does the job, then that's what you wanna do. But you want something that will at least do basic compression, multi-band compression which makes your voice sound really good because it dampen some frequencies and raises others. But you know just some great stuff there. So Adobe Audition is what I use and it seems to work really well. And of course most of this is done by my VA anymore, so I only use it when he is not around. Those are my picks. 

 

JEFF: Audition is only recently available on Mac right? It used to be Windows only? 

 

CHUCK: Yes. It used to be Windows only. And I actually have a license for Windows and for Mac, because that way, if I get a new VA, and then I could just say, download the trial and then use my license key and it works pretty well. Anyway, Eric what are your picks? 

 

ERIC: Okay, so I have two. The first one, we were talking about Alan Weiss, he has a book called A Million Dollar Consulting but recently I think the last year, he did a rehash or redo of it called The Consulting Bible. I'm not going to get into it too much, but I was reading on my Kindle, and I think I got to, like, Chapter 2 before my Kindle told me that you can’t take any more notes and have anything else in this book. There is that much in there. I came into a couple of years and it’s like, there's new stuff, and I'm like, oh my God I have to try everything in this. So it’s a good introduction to the methodology on the way he thinks. It's on the Kindle it's also on paperback and it's called The Consulting Bible. 

 

EVAN:Where you can have unlimited notating in your paperback. 

 

ERIC: And then the second recommendation, So I freelance and I am pretty much solo all the time. I barely do any pair programming. Most of my social is interaction is through e-mail and all that stuff, so I have to learn on my own. But one thing that I have kind of learned a lot from is actually watching other developers’ code or solves problems. And for that, Peepcode has a couple of screencast called The Play by Play series. I've watched two or three of them and once again took like and notice some stuff to try. I mean, I am a die-hard Emacs user and I was watching a guy using Vim and I was still picking up a lot of ideas that I can incorporate in to my workflow. 

 

CHUCK: was that Gary Bernhardt? 

 

ERIC:Yeah. I cannot pronounce the name so I just skipped over the name. But yeah, so the Peepcode Play by Play, it’s great no matter what level of developer you are, because you can see the thought process someone goes through and you can also see what tools and stuff they use. It's interesting to watch and they are relatively cheap. 

 

CHUCK: Yeah if you want to get more of Gary Bernhardt, I just wanna throw this out there, you can find his stuff at destroyallsoftware.com. It is a membership site. I think it cost nine bucks a month. But yeah, mind blowing stuff. ERIC: Yeah I have Destroy All Software also; it’s well worth the money. It’s I think will a weekly screencast, 10 to 20 minutes each week and it's like beginner to advanced stuff, covers wide range topics so it’s definitely worth it. That is a minor pick for me I guess. 

 

CHUCK: Okay. Evan, what are your picks? 

 

EVAN: Well I guess I have two “anti-picks”. One of them is sort of serious; the other one is sort of humorous. First anti-pick is the iMac microphone, because that's how I’m talking to now and I'm really not hidden in any underground bunker, I am sitting in my office talking to my screen sitting about 1 1/2 feet away from it, but I have heard a couple of recordings of me on this podcast, and I sound like I'm coming at you from an underground bunker. So anti-pick, do not use an iMac for recording podcast or at least the iMac mic. I still have to buy a good mic and so I'm glad that Chuck share the software. The other anti-pick would be Eric Davis’ Internet connection this week. That's just gargle sound that we hear during the podcast. 

 

CHUCK: Yeah, well, sometimes it just a funky thing on the web. I know that Skype uses some peer-to-peer technology and stuff. So it's not always your Internet connection, sometimes there some other funky crap going on with the way they run stuff, so it could be Skype. 

 

ERIC: I believe the butterfly storm in Africa. 

 

EVAN: That was also perfectly tight. Finally, someone laughed. That is all I was looking for. CHUCK: All right Jeff what are your picks? 

 

JEFF:Alright, so I guess the first one, I shouldn’t be able to not, in the podcast, without saying that my app got approved for sale in the app store. It’s Math Minute Additions. Its 60 seconds simple arithmetic app targeted for small kids, like 5 to 7 years old, in that range. So go check it out, buy it. I’m not shamed or ashamed or whatever. I

have no shame. It took forever to get that out. So that it's pick one. Pick two, Steel Ruby Conf, Steel City Ruby Conf. I just saw this and Peter Cooper’s Ruby Weekly, it’s Pittsburgh Conference, which is cool for me, definitely closer than Boston or anything else from the GC area. But it's first idea of first Ruby Conference, so you if you haven't been to a conference, if you're thinking about freelancing, this might be a place to go, low stress, lower key than maybe Rails Conf or one of the crazy ones. Then the other one, if you don't want to do any billable work, Mass Affect 3 is coming out in March. I still haven't played Skyrim yet, because I know I need to go on like a six week vacation to play Skyrim. But Mass Effect is on my list too and that will be another several week vacation. I loved the Mass Effect series. 

 

EVAN: Oh, come back to me then, because I don’t think— 

 

CHUCK: Evan, what is your pick? 

 

EVAN: Star Wars the Old Republic! It has been my time sync through ever since December since I got over my Skyrim addiction. 

 

CHUCK: Yeah, I'm afraid that the one. I used to be on Star Wars Galaxies. 

 

EVAN: Yeah, it is even more, well yeah; it's more addictive than Star Wars Galaxies. If you're a diehard Star Wars fan, you actually have to play it and I'm a programmer because of George Lucas and Gene Roddenberry, so mandatory. 

 

CHUCK: Yeah, like I said I’m staying away from that right now. Anyway, so I think that's everything. There a couple of things I want to point out. The first thing is that we should have the date topic link on Ruby Freelancers today, and I thought I put that in there, (but I guess I hadn’t, I'm a slacker.) I did move the form over a paid account on UserVoice, which means that if you voted for any of that topics, all of your votes are back, because it re-entered them all as me, so that’s the other thing, I didn't suggest all of those topics on there, but you know, don't give me credit for the good ones, don't give me credit for the bad ones either. Anyway you should just be aware that you can go in and vote the ones up that you want. You can also click on that and it should bring up a little dialog where you can give us more ideas what want us to talk about. So anyway, that will get us some feedback, so that we know what you want to hear about and anyway we're also on iTunes so go in there, leave us review and things like that. My other podcast, JavaScript Jabber was actually new in New & Noteworthy in iTunes and that that works is, from new subscriptions and from people listening and giving us ratings so if you can give us ratings, it will move us up on the technology section of New & Noteworthy and help us out there. Finally, if you want to hire any of us, you should have our links in the show notes, to our companies and you can go and you get contact any of us that way. 

 

EVAN: You better give us suggestions for show topics or we are just going to have an episode about reviewing videogames we play. 

 

CHUCK: Yeah but time-sync episodes. Alright, so with that, we’ll wrap this up. We'll catch you next week!