Estimation Essentials - How to Nail Pricing for Development Projects

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season of the Developer Journey. This is Developer Nerd. This is Building Better Developers. I am Rob Broadhead, one of the founders of Developer Nerd and a founder of RV Consulting, where we take all of the nastiness of technology and turn it into a nice, pretty little, fuzzy little thing with a bow on top through integration, simplification, automation, all those shuns that you need so you don't have to shun your technology. I just came up with that on the fly, so I apologize if that was too cringy. That's one of the things that we do is that we basically find a way to help yourself with the technology you have, whether that is building something custom or using tools that are out there such as the kinds of tools that we do talk about very often here on Developer Nerd. In a good thing, bad thing world, let's see, what is a good and a bad thing that has happened today? So, bad thing. This is one of those things that sticks in my craw. I got a statement from an account and it's one of these things that's like a loan credit card kinds of things and it's one of these where you're paying and if you pay extra, if you pay at the wrong time, they essentially add it on to, instead of working with whatever your monthly amount is that you're supposed to pay, say you're supposed to pay $10 a month. So you send $10 in, but they don't put it on the right date, so they just say, oh, well, you just paid extra on the prior month and then they end up whacking you the next month with the late fee. It's like, well, wait a minute, that's not how it went. So the bad news is I get one of those. It's like, oh, come on, it hit on that day. I'm looking at all this stuff. Why doesn't it add up? With that, I'll give the good news just so I can keep that concise is that they're like, you know what, you're right. This shouldn't have happened this way. We'll waive your fees. We'll take care of it and all that kind of stuff. And I was just like, okay, cool. On the other side of the internet is Michael, let you go ahead and introduce yourself. And how's your day gone in the last couple of days gone in the good and the bad sense? Hey, everyone. My name is Michael Moulache. I'm one of the founders of DevelopNUR, Building Better Developers. I'm also the founder of Invition QA, where we help mid to small businesses, clinicians help you kind of walk through your current software stack, make sure it's working for you. And if it's not, we help you build or find the systems you need to make your business run smoother and improve your daily processes. Good and bad. Good. Getting real close to the end of a current project with a vendor. And I'm really excited for the next phase. And things are going well. On the bad side, similar to you, except slightly different. I was reconciling my ledgers and found out I had a couple weird charges on a debit card. Well, come to find out banks don't like to reconcile and reimburse you when your debit cards get hacked. What's annoying is the freaking debit card has been sitting in my office this whole time. Not sure how they got this one, but some other thing happened. A week after I opened the account, immediately I started getting unauthorized charges on the account. Didn't buy anything. So finally got that reconciled, got new cards again, everything's happy again. But that's just a pain in the butt because if you get hacked, you have to go find, oh, what are all my auto pays and get all that reconciled again. The bank's response, get a credit card. And my response to that is, are you paying for my fees? So this episode, what we want to get into is sort of along those same lines is pricing and estimating. There's two things that we get into as we get further into it. When we get to a certain point as developers, we have to, we look at project level stuff. We're not estimating just like what we're doing in the next week or two. It's something that's a little bit more complicated because we end up in a situation where we're trying to estimate for our employer or for our customer, not only our work, but the work of others and what is the system or the environment that's going to be needed. And then maybe even along with all this, like what is the, what's the overall team structure kind of look like and all of this that without maybe necessarily having all of the requirements that we need, particularly now when we go into, you know, go into like an agile kind of world where you're starting out, you've got requirements. If you don't back up, go get requirements. You need to have some level of requirements before you start or else you just, it's a recipe for disaster. You've got to know where you are to some extent and have at least an idea of where you're going. Otherwise, you're spinning your wheels. So if you've got some level, but you may not have all of them. And the whole idea of agile is that, yes, we may end up changing course somewhere along the way. And so if we do so, then what the heck is that going to mean to dates and costs and estimates and the time that's involved, the people that are involved, all of that kind of good stuff. So with all of these unknowns, where do you go with this? And the way to do this is I found, and this is just my approach. There are a lot of different approaches to it. I found that you sort of do it in a turn it into like groupings or buckets or things like that. And so I can take if I'm looking at a project, I can take pieces of it and I can give a rough estimate because I don't think anybody's going to hold you to. Hopefully, they're not going to hold you to a specific estimate on something when you don't have all the details. Now, depending on how much time you've spent gathering requirements and things like that, you do need to like you need to get better than some huge ballpark. You can't say this project is going to cost between one and four billion dollars when you've spent some time gathering requirements. You're going to have to like narrow that sucker down. Now, one of the ways that I found that is probably the easiest way to do it because it simplifies the math and gets you away from getting too deep in the details is start with what is the scope of what you're building? It's from the software side. What's the scope of what you're building? Roughly, what kind of a team are you thinking you're going to need to get that done in the time frame required? So if you've got a project that's going to take you don't have to, you know, you can probably guesstimate even like this project is going to take 5000 man hours. OK, 5000 man hours and you may be looking at it. Well, it's going to be a thousand as a junior developer and a thousand as a tester and a thousand as an architect and a thousand as a database administrator. Or however you do that. Because then when you've got that now, it's like, OK, here's the 5000 hours of the project. Now I've actually put some of these into buckets because I sort of know because I've looked at what I've got to do. I can say, well, this is roughly how much effort is going to be here, roughly how much effort is going to be there. The challenge with this is figuring out what that effort is when it's not you. And so what I tend to do here is either if it depending on how you're going to bill it and things like that, how you're pricing it. What I may do is I may use myself as the the one as like the at the level. So something if somebody is going to be able to do it faster than me, then I'll give them a greater. You know, they'll basically be able to do that then in less hours for my rate. If it's somebody that's lower, that's not as effective. Then maybe it's going to be something where I'm going to say, OK, it's going to take them more hours. But I'm going to be able to assume that they're going to be able to get those hours sort of fall within my rate. So if I'm just giving a nice numbers like, let's say I've got a ten dollar an hour rate. Well, if there's somebody that I'm looking at, it's like they're probably going to take four or five times as long. Then I'll just be like, OK, I'm going to take the hundred hours that I would have taken. And I'm going to say it's going to take them five hundred, but now I'm going to back it off to the rate. So guess what? It's in the if they end up five times as much, but they've got a fifth of my rate, then it's just it equals zero. So what you can do is you can figure it out based on what it will take you to do it. Now, if you're really, really good or really, really bad, this is going to be very difficult. But if you're wherever you're at, you should have a feel for where other people are going to be roughly with regard to you and getting some of these things done. Now, if it's an area that you have no idea, like let's say you're a developer and you just really don't get hours involved in a DevOps piece of a project, go talk to somebody that does that. It's it's not cheating to go out there and get information from people that are out in the world to get some feedback and say, here, this is roughly what we're doing. What would be your estimate on your time to get something like this done? And if you even need to know, it's like, what kind of rate would this be? Or if they're a really high or really low rate, then figure out the rate that's in yours and say, well, if somebody was at this rate level, what do you think it would take them? Because those kinds of ballpark things, those numbers are going to be very helpful to your customer, because now what you've done is, let's say you've taken that 5000 hour project, you've now broken it down. You've sort of assigned a value to some level, like if it's a thousand broken it into five ways, then you have a value for each of those fifths of it. So if one's at 10 and that's ten thousand dollars total, another's at a hundred dollars an hour, so it's a hundred thousand dollars total. You can add all that stuff up. And what you've got now is a ballpark. Now, what you want to do a caveat or a caution to this. Is that you want to make sure that you do not underbid it. That you don't go into this unless you have complete control over it. Don't go in there and be like, all right, I'm going to undersell this thing because it's a side hustle and I'm doing this project for somebody and I want to make sure that it's really successful and I want to make sure that they accept the project. I want to win this project. The problem is that may work fine if it's a one week project. If it's a nine month project and you're not getting paid enough during that time and you didn't get enough money so everybody else is getting paid enough, you're going to be in trouble. You're going to hate yourself. Everybody's going to hate you. Haters everywhere. Not good. So make sure that you're looking at what is typical market rates because it's always going to be easier, particularly if you estimate high to find ways to like, you know, win with the customer and say, well, we said it was going to come out. It only cost $10,000 and it only cost $9,000. And even if you initially, you know, if you initially estimated five, but you told them 10 and you got it done in nine, they think, all right, that was less than what I was expecting to pay because that's what all of us want to do. If we're told this is what you're expected, you know, what you should expect and it comes in lower, we're always happy because we've already set our expectations there. If it's higher, the higher it is, the more likely we are to complain. Do that with the hours as well. Be generous with those hours. Sometimes a developer, there's a rule that I've found actually probably is still underestimating is to take any developer estimate and double it. And I've even heard triple it. Doubling it, I have seen many, many times where that still is not even close to what it actually takes. So be aware of your blind spots in estimating stuff and take others estimates with a grain of salt. Before I toss it to Mike, I do want to real quickly take the same thing from a hardware point of view. It is very easy to get into something that says we're going to build out this solution. Here's what it's going to be. These servers or these services and all of these pieces. And you can sit down with if it's a cloud solution, almost all of them have tools. You can walk through it and say, I'm going to have eight different servers and this is the size of blah, blah, blah. And it'll spit out. This is what your monthly cost is going to be. All of that stuff is great. But if you haven't even started with your project, if you don't have constraints around your project, those numbers are junk. The things you need to understand in order to get to some sort of an idea of what is it going to be, what is it going to take to support this is you're going to have to ask a lot of questions. You have to understand how many people are we talking about on this system? How many people concurrently are we talking about on this system? How diverse are the people? Is it all over the globe? Is it local? Is it a cloud server? Is it something that's a local server to somewhere? Are there networking considerations as far as how fast does this data need to go? Space considerations like are we downloading? Are we storing videos for every single user that could very quickly add up to a lot of space? Or is this like a very simple contact management app where we could have a billion people in there and it's still not be that much data because we're only keeping track of an address, an email address, and first last name or something like that. Those are just the start of it. You need to get from the requirements. You need to have at least getting into an idea of how big is this? How big is the user base? What are their expectations? And what is the usage of it? And by expectations and usage, it's things like is this a web application where, for example, they're expecting less than two seconds response time for every page, which is sort of industry standard? Is this some sort of a batch kind of thing or a fire it off and then you'll get an email later reporting kind of thing where time isn't as big an issue? Is it something where people are only going to run this once a year? And so if it takes an extra 10 minutes, who cares? Or is it something they're going to run a thousand times a day? And if it takes an extra 10 minutes and it is unusable to them, those are all factors that you're going to have to put together before you decide on what the solution is. And it is, unfortunately, one of those things that may be a little bit of a chicken and an egg problem as well sometimes because you need to actually start looking at the structure of the solution. What kind of an architecture are we talking about? What kind of an overall design are we talking about? Because we need to have some of those pieces before we can put some of these estimates together. My last thought as I pass it over will be don't be afraid to keep stuff in a range. Like I said, it needs to be better than between one and four billion dollars and two days and infinity, but bring it down. But don't be afraid to provide ranges where sometimes that high end make it very high because with the idea that you're thinking that as you get forward into it, you're going to be able to bring that down. You're really going to be underneath whatever that top end is. And be honest with this stuff. Or it's like, hey, this is what we know. Here's like some of the cautionary stuff. And particularly, even though I don't know how many times I've had people just gloss over it, make sure you have your bullet points or something that here's what our assumptions are. And here are some of the things that we see that could cause a big change in this. I've thrown quite a lot out of there. I'm going to take a deep breath and a glass of water and I'm going to let you sort of throw your two cents and then some up to four billion dollars worth into this conversation. Go for it, Mike. Thanks, Rob. You really gave us a lot to start with, and I'd like to build onto that. So one of the things initially, I'll start with a personal story is starting out, you know, being a developer, spending years working for companies, branching out and kind of building my own business, you start out, you can always have that in between period where you start doing those side hustles, you start picking up small projects for people. And like Rob said, sometimes they're like a one week project. So it's real easy to kind of like guesstimate what it's going to cost to do the work. However, as these projects grow and you start going from the mindset of, oh, this isn't such a side hustle anymore. This is a business. Those numbers need to change. And I'm still bad at this and I still get blown up from time to time because you always want to, I run into the habit of, I always want to help the customer. I always want to help solve a problem. And it's kind of those philosophical things where it's like you more want to help than kind of take. But you do need to get paid for what you do and your time is, has a value. You know, you're not doing other things. You're not playing video games, spending time with family. You're working for something. So you need to get compensated for that. And that's kind of where this comes in. You have to really think about what's at work to you. Now, the whole point of Mike started this where to circle back around is, is this is a side hustle. Then you're going to be a little bit less. You know, you may be more than what you're currently making, but you're not really going to be thinking about all the underlying costs. It's like, Hey, it's a paycheck. I want to make some money. It's a task. You can put some time to that. If you're looking to make this a business, you now need to think about all the things you don't think about. So if you're an employee, your employer pays your social security. It pays your Medicare. It pays your insurance. Yes, you pay into it, but they pay more into it. There are other hidden costs that you don't see in your paycheck. So you may make 40, 50,000 a year, but the business is actually probably paying higher for you to be employed with that business. And those hidden costs are what you now need to figure out. Tack into your rate. And that is what you need to charge as part of your package. If you want this to be a full-time gig. So if you're making $40 an hour, you don't want to build $40 an hour. If you're a full-time employee, you're probably going to be charging more like double that, maybe even triple that depending upon what it is that you're doing. So that's just one small little business thing I want to throw in there because it's one of those things we don't think about. And a conversation you and I had just recently was the other things we don't think about when we're developing software. And that is the time that you spend working in your business, not necessarily working on the business. As you're working on these projects and building this software, especially if you have software teams, there's that underlying cost of doing the work. If you're doing agile, you have all those team meetings you have, you have your retrospectives, you have your refinements, your daily scrums. These things take time and you need to account for those times in your costs. If you work solo all the time and then you start moving to a team structure, you start hiring people on, you're not necessarily immediately going to think about that. And you're going to undercut your time, which will impact the costs and your budgets that and your estimates that you give the customer. So you have to be very careful about that when you start to grow your business or when you start to branch out from a side hustle to a business. So these are some things to keep in the forefront because they will bite you and you don't want to be stressing when you finally have that old moment and you're like crap. And then you're like, ah, can I do this? And you don't want the haters. You want to make sure that you're well prepared for what's coming. Now, I want to throw it back to you, Rob, because there's some things I kind of want your point of view on. If we're starting out with the project, we have some requirements, but necessarily we don't know the full requirements. When we get down to deploying, you mentioned hardware, that's fine. But what about things like testers, load testing, user acceptance, all that other stuff that is overlooked as well that you didn't touch on? How do you kind of think about those if you don't do those typically in a regular side hustle business or just typical projects? I think there is definitely a lot of places you can go to find a rule of thumb kinds of estimates of how a development project should go, how much time should be in development, how much time should be in testing, in deployment and things like that. And it's generally, I think it's like 20% in design, 60% in implementation, 20% in testing or something like that. I forget all the... Those will give you at least something to go on. Now, for yourself, as you're getting into these things, this is where I actually find agile works really well in the sprint world of it. Because if you're running sprints, then for example, let's say you run a one-week sprint. You will know that in a given week, there's the development time, but there's also going to be the backlog refinement time. There's going to be the sprint review. There's going to be the retrospective. There's going to be the daily stand-ups. Those things are all time that is going to come out of every week. That is stuff that whatever you're doing in development, there is this additional piece of project management types of tasks or testing tasks or testing tasks or these other things. And you can use a rough brush on these where you could say, for example, let's go back to our 5,000 development hours. I have found... I've worked with a lot of different companies and I've found a lot of times they'll say that like 5% or 10% will be project management and meeting costs. I think that's actually too low. Because when you look at it, it's very easy to have a meeting with your entire team. And if it goes an hour, all of those hours go right into that project management bucket. So think about what a... As you're going into this project, it's not just what you're developing, but what does the team dynamic look like? Are we going to do daily stand-ups? Are we going to do a monthly... Or let's say a weekly team meeting. Are we going to do... Depending on what our sprints are, what is it... At the end of the sprint, are we going to do reviews? Are we going to do retrospectives? Are we going to go spend some time doing some sort of backlog pruning and things like that? What sort of design kind of time are we going to have? Are we going to have design resources that somebody is going to work on user experience? Do we need to deal with those? Do we need to have specific testers? Or are we going to have people testing that? Because all of that, we want to have those things in mind. And if we... The first time or two you do it, it's going to be rough because it's going to be I think it's roughly this. It may work like this. It may be that. But make sure you're keeping track of that stuff so that as you move forward, you will from project to project to project, you will get better with such things. There's going to be able to sit there and say, hey, this thing was 10% of my hours last time. And I only guessed it. I estimated it at five, maybe 5%. So I'm going to bump that up. Or this thing, I put testing in at 10% and I got to the end and realized I really needed more time and testing. So typically what I'm going to do there is you get your bucket of development and then you start tacking on. Years ago, it's probably out somewhere on developing newer sites somewhere. If not, I'll find a way to get it out there. As I put together a little spreadsheet and it was built, it was for me to just do quick estimates. And it was basically, I knew roughly how long I was going to... I had sort of estimates like if I'm going to build a page for an app, what's it typically take me to build just a page? And then there's like the guts behind the page. And if I have to design a database, I'd had all this stuff that would help me figure out hours and just sort of like a rough estimate of hours for development. And then I had all these other things that might get used user documentation. What kind of testing am I going to do? Are there going to be weekly meetings? Are there going to be demos? And those things would tack on some sort of a percentage or something like that. So I'd get, here's my hours. And then here's all the other things, which literally is going to be a lot of times an extra 20 to 25% of your hours are going to be into those other areas. It's going to be all of these other things. Now that's to give you the quick answer. I do want to actually step back one thing. When you do your own business, if you are taking that step to, from side hustle to super hustle, full hustle, or whatever it is, Kung Fu hustle, whatever it is that you've got to take into account things like professional development, business development, holidays, vacation days, and things like that. So if you're sitting there and you go, okay, I need to earn, you know, I earn $50,000 a year on a salary. Well, to get that $50,000 from a business point of view, you're probably going to have to bill something to bring in. You're going to have to bring in probably $65,000 or $70,000 for just that salary. Typically markets, you know, the typical market costs, including up, you know, over their like margins and stuff like that, because they include things like sales and marketing and all that stuff is typically going to be for a consulting type gig, 40 or 50% above whatever the salary is. So if it's, which would be like, just keep it nice, simple numbers. If you're making $50,000 a year, it's probably going to be $75,000 a year that you're going to have to bring in, which means if you build through the year, you know, roughly, you know, almost $40 an hour. Now remember that, you know, if you're going to like calculate all this out, it is not 52 weeks times 40 hours, because you're probably going to have, you're going to have sick time. You're going to have holidays. Even if you don't want holidays, if you're like, I never get sick, I never take a vacation, there will be holidays. And so you're going to have those that are going to be taken off. There's going to be stuff that you're not going to work the full year. And this is just US. If you go outside of the US, you get in these other countries where they've got all of these, they've got more holidays, or they've got, you know, vacation times and stuff like that, that are effectively mandatory, or if they go to a four day work week, there's a lot of factors that go in there that you want to make sure you're thinking realistically about what is it that I have to replace if I'm going to now be my own employer. And it does step into things like, it is the payroll stuff, but then it's all the other stuff around that. It's things like, are there software subscriptions that I need to have? What does it cost to replace my computer? If I've got to have a computer, if I have to have high speed internet, if I have to have a cell phone, and now I have to pay up my company's, those things all add up, and you need to take a look at it. And that does not mean that your first customer needs to pay all of that crap for you, because it should be able to be something that you can now like, you know, spread over that year or whatever it is. But those are things to take care of. I will give you sort of a closing thought. Hopefully, that answered your question a little bit. It did. And just a couple of additional things to add on to that, you know, don't forget, like clothing, your car, you know, there, look at everything that you use every day that you might need in your business. That's a cost. Make sure you account for that. In addition, make sure you account for your time. In the bonus section, I'll throw out some additional things, but make sure you track your time, find some way to keep track of everything that you do, because time does have a cost. And if you're not spending time with loved ones or doing the things that you love to do, you know, your business might be, but you still need to pay the bills and put a roof over it. So make sure you account for that and take care of yourself, you know. Yes, it is business. Yes, this is something we do, but we need to keep track and take care of ourselves. And you can help us take care of ourselves by sending an email to info at developer.com or jumping out to developer.com and sending us anything you want, like all kinds of feedback we're happy to have through the contact us form on the developer site. You can leave us comments here, whether you're watching this on YouTube or whether it's whatever your favorite podcast app is. Leave us a review, leave us a like us, don't like us, whatever. We really want more. A five-star review would be great, but more probably better. More important to us would be some feedback of we like this, we don't like that, or even better yet, hey, here's a topic we would love to hear you guys talk about or talk more about, because that helps us help you. And that's what we want. You can't figure out requirements without talking to your customer. And guess what? This time you guys are the customer. So help us help you. That being said, we are not done with this season. We are going to continue just chugging right along. But for now, we're going to wrap this one up. You guys go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the developer podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.