Detailed Notes
Welcome back, fellow developers! Whether you’re tuning in from your favorite chair or your trusty work desk, we’re back to share insights and reflections on the intricate world of software development. In today’s episode, we’re diving deep into the realm of realistic expectations—how crucial they are when dealing with clients, navigating difficult conversations, and ensuring project clarity.
Setting the Stage for Realistic Expectations In today’s podcast, we’re revisiting a topic mentioned in previous episodes: realistic expectations. From the onset, we’re reminded that clear communication is key, especially when it comes to managing clients’ expectations, whether they’re individuals or even ourselves. So, at the core of managing expectations lies the concept of realism. For instance, it’s about acknowledging the minimum effort, time, and cost required for any endeavor. Sure, we may aim to be efficient, but reality often demands more than our initial estimates. However, we’re not talking about lowballing or overpromising; instead, we’re talking about being honest and transparent.
The Developer’s Dilemma As developers, we’re often tempted to underestimate the effort involved in a project. For example, we might think a task is simple and we can just breeze through it in record time, only to encounter unforeseen obstacles like typos, configuration issues, or external dependencies. So, it is wise to be mindful of these uncertainties, and learning how to handle them is crucial to avoid project overruns and disappointments.
The Tester’s Perspective Approaching projects from a tester’s viewpoint adds another layer of complexity. Because, Testers scrutinize requirements, seeking clarity and understanding from the end user’s standpoint. If we lack clear requirements, it can lead to scope creep and inflated budgets. That’s why investing time upfront in understanding requirements helps set clearer, more realistic expectations that pay dividends later.
Navigating Client Conversations Effective client communication is crucial. It’s a two-way street that requires clarity and honesty from both parties, not just being “nice” to the client. We must present realistic estimates that lay out the clear assumptions and potential risks involved. This empowers clients to make well-informed decisions about the project.
The Power of Proof of Concept A proof of concept or minimum viable product can often be a game-changer. Delivering something contained and well-defined upfront allows clients to truly visualize the project’s scope and complexity. Which leads to more accurate estimates and informed decisions about whether to proceed to subsequent phases. While it requires an initial investment, spending time on early assessments like this can save significant time, money, and headaches further down the road.
Avoiding Pitfalls When Setting Realistic Expectations We’ve all had our share of horror stories—projects that spiraled out of control due to miscommunication or unmet expectations. Whether it’s underestimating project scope or neglecting to clarify requirements, these experiences underscore the importance of upfront honesty and transparency.
As we wrap up this discussion, we invite you to share your experiences and insights. Whether you’ve triumphed over project challenges or faced unexpected hurdles, your stories enrich our collective learning journey. Remember, honesty, clarity, and proactive communication are the cornerstone of successful software development. Until next time, happy coding!
We’d love to hear from you! Email us at [email protected] or visit our website to share your thoughts and stories. Stay tuned for more enriching discussions in the episodes to come.
Additional Resources * Software Estimation: Improving Productivity, Quality, and Expectations - https://develpreneur.com/software-estimation-improving-productivity-quality-and-expectations/ * Proving Your Worth – Understand Expectations - https://develpreneur.com/proving-your-worth-understand-expectations/ * A Project Management and Pricing Guide for Success - https://develpreneur.com/a-project-management-and-pricing-guide-for-success/
Transcript Text
[Music] hello and welcome back from where ever you're coming back from uh you're probably sitting in the same chair you were before but now we're sitting in the same chair we were as well so I guess we never left as far as you you could be that we never left you don't know uh we do uh you there's lots of ways to do that that'll be a different thing we'll talk about like conspiracy theories or something sometimes and go down one of those rabbit holes this episode though I want to swing back around couple episodes back especially if you're here on the video uh if you're listening to podcast you may missed it because it was bonus material basically but one of the topics I had mentioned that we were going to cover was like realistic expectations was how do you deal with customers and making sure that there was Clarity and this customer could be uh it could even be yourself sometimes but definitely it could be your boss it could be an actual like a customer and how do you it's like sort of bad news difficult conversations kinds of things but it's it's things like hey it takes a certain amount of work and effort and time and cost to build something to do something to accomplish something and so it's how do you communicate that and it is as I referred to it it's sort of like that it is what it is is that there is a level of just there's a minimum that has to be done to do something and so somebody may try to argue you down but there's a point where it's like that's not valid I can't do that it's like can you do it in you know you say it's going to take 10 hours can you do it in nine all right maybe can you do it in eight I don't know can you do it in one no there's like there's stuff like that where you're like all right stop whittling it down and instead let's be realistic um so we're gonna dive into the podcast and we're gonna talk about that we're gonna talk about reality and Clarity and communication and it goes back to I had a conversation the other day with a customer and I think it just really brought that to to light as far as these are things that if you've got a good customer and this guy awesome um you know it's if you got a good customer then it makes the whole thing work better but it is a two-way street so it's not just them being a nice customer you've got to be clear and honest and pursue the things that you need to pursue so that you can let them know what the risks are and as best as you to your best of your ability is allow them to make decisions that are well informed that being said it's time for us to dive into the podcast hello and welcome back it is season 21 it is episode some number I can't even remember now like we're just chugging along in our episodes working our way through this season trust me it well don't trust me because we may go further but it's probably going to be another one of those like 30ish episode Seasons but we'll probably end up going into just like a follow-up season that's going to be the same kind of thing because we're we have a lot that we want to discuss we're we're getting into the mentor Mastermind kind of approach we're talking about like problems that we've seen on a given week and guess what we see new problems every day every week and these are the kinds of things because we are in the trenches just like you are we're seeing things that are going to help you out that you probably are seeing as well and just as part of I want to introduce myself because I don't always do that this is Rob Broadhead I am a Founder here at developer develop preneur also uh found at RB consulting which is my day job I guess this is my side hustle if that if it's if that's a thing uh in this case and so I do I am a software consultant by day I do specifically I do a lot of like it assessments some people call these things like fractional CTO CIO but also we do like full full service we will build your entire piece of software for you or we'll tell you how to build your software and show you like the best ways to approach that that's me on the other screen if you can see this just in the other ear hole I guess if this is what you're listening to is Michael Michael why don't you goad and introduce yourself hey everybody my name is Michael Mage I'm also a co-founder developer Nur I also am the founder of Envision QA where I focus on my company focuses on QA assessments where we help companies look at their software infrastructures and identify where they're lacking in QA and we also offer other testing services like unit testing uh you know selenium test AB testing and we also have the discussion with the customers to try and flip the QA model on its head you know don't wait till the end to do the QA start the QA process when you talk to the customer so that's me and welcome so I want to Dive Right into this this little topic because it is a it is one that I think a lot of us particularly if we come out of a developer type role technician type role it it's harder for us to do this because there is a level of sales and communication and those things usually are not attributed to us that are a part of this now the first thing is we have to have our ducks in a row I think we need to really be realistic and this is this is to just us that are developers is that we need to to like break as much as we can the mold the the like the hard and fast rule that if a developer tells you it's going to take x amount of hours multiply it by two at least and if you can even get it to multiply by 1.5 instead of two like just something that you can bring it down closer to reality that will help a lot because the problem I think part of the reason there is a I've got a little you know infographic somewhere about this but one of the things that's not discussed I think often enough the reason why software projects fail or over budget is because the developers yeah sometimes it's because they just they didn't understand their requirements they didn't really discuss it right that kind of stuff A lot of times though it's because we look at a problem we say I can get that done in an hour I can crank that sucker out I could like throw some code spew some code run it build it debug it test it boom done and it's like it's GNA take me an hour and then you find out that it actually takes you two hours or four hours or eight hours because we don't think about or we don't factor in things like I had a typo that was like it was a Capital C instead of a lowercase C and it cost me hour to find that in the code that I was generating or I had a configuration issue that blew stuff up or I chased down the rabbit hole because I thought my code was broken but it was actually the API provider was just they had broken their stuff there's just so many ways software can go wrong that we need to like buffer that in I know we want to be aggressive we want to say hey if and it's it is we look at we say hey I can get this done in two hours if if everything's good if everything's going my way spoiler alert nothing is going to go it's like that never happens in my entire life I think I've had like blocks of hours and maybe a day where it's just like boom boom boom everything fell into place everything was awesome and I do it and that wasn't just you know because I had been doing this for a long time it's just because like I was lucking out I needed to go buy a lottery ticket at the end of the day there's just stuff that happens so we need to be realistic and think about that when we are estimating things this like add some of that wiggle room in because the more like more often than not you're going to find out that wiggle room that you thought you were adding in gets just gobbled up very very quickly thoughts on that oh definitely so it's really interesting hearing this conversation because you know we live this all the time and we had a discussion on this recently where you know we were talking about doing a proposal for something and it's like well here's the idea or the pseudo requirements and being a tester I take everything at face value so I take the requirement and I immediately start picking it apart I have I no longer quickly throw out oh it's going to take XY hours because you're right we never really know the full situation the other thing is is the requirement even the requirement so there's been conversations I've had with people where it's like well I want this well okay what is the user story what are are what is the end result you're looking for and walk it back to that requirement and a lot of times they can't do that and the moment that happens you realize that okay so your initial requirement or your initial request for what you want I'm now going to tack on a week for something that might be eight hours simply because sure I'll write this but then you're going to turn around and say okay I want this and then you're going to turn around you want this and that's the scope cre because the requirements are defined clearly enough to actually estimate the job the other problem is in their mind they have one thing that they want and that's what they wrote down but once they see it that's not what they want so they're going to immediately start scope creeping and that's what you got to be careful of right I mean we don't want to be in the situation where we say yeah an hour but you've now scop creeped in 40 hours worth of work um it's not worth my time and that's where I think Clarity and communication comes in is that if you're going to be you know a hard ass about such stuff or if you're going to be very detail oriented then you need to be detail oriented and you need to not just say hey you know this is this could like and sometimes I'll do I'll start with like this could take anywhere between 10 hours and 10 years because what you've given me we don't have enough information but what you can do is as you're digging into that and you're asking the questions you're getting answers is that you can evolve that and and work it into ballparks and things like that where you can say Okay based on what you've said I think this is where we're going to go it's going to take x amount of or X range you know XY range of hours and these are the things that are concerns or these are the things that I don't think either I know we haven't really you explored or that I don't think we've explored enough so that you got at least a hey this thing is sort of known or maybe very well known and that's awesome and we'll put an estimate around that based on that we can make assumptions about these other things but those other things are to be determined and here's roughly what it's going to be because what's going to happen is you want to have a customer coming into this particularly when you're starting out when they're they're working on this project and deciding is it what's it going to cost them or what's the value of it and things like that is give them an idea of what that's going to take now if you've done things like this before and they're thinking this is going to be and it could be that's it's like really simple really small you know it's going to be a just picking a number like yeah this is going to be a $500 project potentially with what you've said it's like if it's that simple great but then warn them and say you know what I've done this 10 different times and nine times out of 10 that thing grew into a $50,000 project because I don't care who you are $500 is very different from $50,000 and those are the things that kill us and sometimes it it is it's like it's going to be double or triple or quadruple but you need to be able to go into those saying hey this is what we're looking at these are our assumptions and let them know sometimes like if if there are things that you don't know is don't be afraid to say hey this thing I haven't really looked at or here's the assumptions I'm making once those assumptions go out the window then the estimates are basically void because we built them based on assumptions and I I've gotten like every statement of work that I put out there has some level of either questions that are yet to be answered or assumptions that are made or a lot of times both because those are the things I'm going to point to if things are going one way or another and say this is where our assumption was and it was wrong or it got changed or it got added to and these are the questions we had and those answers cost us problems but we should also be able to say when they answer that question and you simply say oh that's going to blow this up don't try to hide it or obus skate or anything is just say hey we didn't get this answered until now now that you're telling me this this is what I see and like I had this like I said this sort of was prompted by a discussion I had with the customer where part of it was I said look we're on track right now I said what what I'm seeing for and we we' already adjusted some stuff and I'm like okay we're on track what I see however this section that is towards the back end of the track we haven't really started on and I think it's going to be okay based on what I'm learning because I think we've like we're getting over the humps but that could be a problem and so it's just a little bit of a like hey here's a warning that may be a bigger problem but I think I've got to it's reasonable to leave it there and then I and and I actually even told him I was like yeah we could I could buffer that out more but I basically told him like I'm gonna it's sort of like saying this is an aggressive estimate yeah we can probably do it but it's a you know we have a 10% chance or 20% chance or 50-50 chance of making it and then this is where we see at least here here's what some of the things we see that could be a bigger could cause more you know issue I had another Pro another customer that it basically it totally blew up his um his project and what his estimates were because he won this is where he came to me with the project he said it's basically done it's like 99% there I just need you to drag it across the finish line and he was basing that on what his developer told him his developer didn't know squat apparent about where it was at it was like that finishing piece was not 90% 99% of the way there it was there was a lot of work and it was stuff there was a lot of rework and so this thing that was going to be 10 20 hours blew into hundreds of hours and that's the kind of stuff that you know if we've been able to tell him that before he would have had to like decide okay am I going to do this but also we would have like the whole Arrangement would have been very different and ended up being not what we wanted we ended up pouring a lot of stuff into that because we're like just we like the guy we wanted to help them I've already talked about I'm too nice sometimes they're I'm a bad boy or whatever but we wanted to help them we love this project we wanted to do that but we ended up throwing a lot of stuff into that and then he still ended up a situation where he was going to have to spend because we weren't what they really needed we weren't going to we were going to be able to we could have like put more into that and made it happen but it was now going to cost us because we weren't going to charge them but it's sort of a blessing to us because now somebody else is going to come in they're going to charge them for that work and they're probably they're going to find s like more of that specialist so they can hopefully get that thing done in less time than we would have so it's like a a win-win but this where you've got to be honest about that stuff I think all of us are the same way if we go in and we need to get our car repaired and they give us an estimate of 500 bucks and we and we're like I ain't got 500 bucks but but okay I've got to pay that to get my car working if they come back and it's a $5,000 bill we're going to freak out we're going to say wait a minute I would have sold the car I like I would have like said that was it if IID known that was what it was going to cost and so those are the things that we need to consider when we're putting together these estimates and when we're communicating with our customers yeah so you've touched on quite a few points there the first so let me start with the end and kind of work my way back so being upfront with the cost is one of the biggest things but sometimes the requirements or what you hear from the customer uh wasn't clearly defined or it's too Loosely defined for example I had someone that has an idea for an application and they're like well it's basically uh vbo but for this industry well okay um can you give meet any more requirements on that no that's basically it and they're like well what you know what kind of ideas or costs or things are involved and so I spent 30 minutes and just kind of worked up very high level like you know here are just some things to think about and then you know I threw a price tag out there that was going to be obscene because you don't have the requirement so there's a lot of discovery that needs to be involved a lot of hidden thing I mean they really have no idea what goes into the software so I think I put it between 50 and $150,000 because I mean it was going to be a mobile app a desktop app there's going to be e-commerce I mean there's so many things I mean it that number could easily been doubled but I was like here's if you start here this is what you're looking at now if you refine that and say okay what do I need for a proof of concept and you narrow that down okay here you now Shrunk the requirements you've now Shrunk the cost cuz now we can clearly Define what it is so when you're talking about that one customer that came to you and said oh yeah this product's nearly done this is one of those times where I would have actually said okay let's block out 10 hours we'll bill you for 10 hours Let's Take or even a couple hours do a cons a paid consultation to walk through the application with them their current environment the current state of things get a true assessment of what's going on and then either take the job on at a clear a a more refined estimate of what you're walking into versus kind of going in unknown so one basically you're saying hey I'll do a paid assessment I'll do that software assessment for you figure out where you're at are you being told what it is is it really at a state you can get it to where you need to go and maybe even just give them peace of mind yes or no and here's where you're looking you know here's what you need to do and then and then the other one as you're going through these requirements or you actually Define all the requirements from a tester's perspective I look at every ticket as what is the statement of work what is the requirement based on the requirement what do I need to do to get this you know basically what is the acceptance criteria what is it that I need to do to say that this unit of work is complete what is testable what is not in scope of this requirement or what is within scope of this requirement and that also helps you kind of narrow down your budgetary hours you know we talked about one proposal we were looking at doing it you know I started out with about what 40 to 60 hours because you gave me a very high level like oh here's an idea or you know here's a statement of work for something like this and I'm going to start high because I have no idea what all the nitpicky pieces are but then as we started narrowing it down we got down what about three days maybe four days of work out of that so that's what you have to consider as you're going through this now where me and Rob differ a little bit is I come at these from a tester's perspective I come at from the user perspective not So Much from the developers uh perspective anymore and that's just from years of writing tests fighting with requirements reverse engineering requirements because there's no documentation for the software that you're working on and it's like well here make this work how is it supposed to work we don't know and then you're like oh wait a me okay so what you want me to do and you have no documentation uh yeah your budget just got blown because I now have to spend x amount of time essentially learning your application understanding what you have because you clearly don't and then you're expecting me to then build on top of that so th these are a lot of the things and problems you could run into that you have to think about and there's some forethought you can put into some of these before you even do there like we've talked about you know do like a 30 minute free call and talk through a simple RP not a detailed RP or even a software assessment or QA assessment you know these are just some ways to help shrink that uh the pricing that or your budget for a particular project if that makes sense yeah and I think you mentioned uh because this is one that's going to this is like again one of those is an ongoing discussion is it you mentioned a proof of concept and I think that's something that very often it is worth it to to push a proof of concept or a minimum viable product is to and a lot of companies I've seen a lot of customers that are starting to realize this and it's like let's get something that is definable that we can actually like put our arms around and let's get that done and figure out what that costs and what it takes and and dig into that and then we can figure out if we want to go beyond it now I do see like this is one of the things I've seen when I've put proposals out I don't know how many times I've had somebody say here's what we want here's a request we want this thing and I've had to send back I can't give you I can if it's an hourly rate I can give them like here's an hourly rate but they'll say I want to fix bid and this is what I want and I'll be like it's it's impossible and it's funny because I don't have that often that they come back back to me so I think a lot of them get burned and because somebody says I can do that for $1,000 and they're like cool my budget was 2,000 I win but what happens is they lose because it doesn't get done or it gets done for $10,000 or more than that and I will I will often go to them and say exactly this kind of approach and it's I've had a few that I have won a project because I was just straight up with them I said look this is I can't give you any kind of ballpark with what you've given you've given me something that is very minimal these are just some of the questions that need to be answered these are some of the things that you need to consider and then once we can like I can get answers to those then I can start putting together an estimate and then we can start thinking about what this is going to take but again that's a lot of times what I'll do is I'll say hey I'm gonna I will I'm instead of bidding you know $50,000 for what you think is a $50,000 project I'm going to bid $500 and I'm going to go spend a few hours and we're going to put together a plan we're going to put together some requirements or I'm going to spend whatever it is figure out what it's going to take and I use I will adjust that based on a lot of times is based on how big their project is if they say hey this is a million dooll project for $10,000 I will help you put together that plan if it's a $ th000 project then I may say it's going to be you know maybe it's only $100 or something like that but I'll say hey we need the plan first uh sometimes it is they're like I've only got a $1,000 budget I'm like well you know what just to put the plan together is going to cost you 500 of that and so there's no way we're going to hit your budget so you're G to have to like adjust that uh and those are the kinds of things where you you know get up don't be afraid to step into those and this is where again I've gotten burned a couple times where it's like hey this works this is there it's solid things like that and you turn around and you're like no it's not all these things you said are there they're not there you said there was documentation it's not there you said they have a bill no they don't or they build it but they can't build that anywhere but their machine there's those kinds of things that you it's worth checking that stuff out and this is where I'm going to pause because I know we're going a little long this time so I want to wrap this one up and just say you know what are some of your horror stories feel free to share those with us because we've got plenty and we will continue to talk about them but you know if you guys have anything shoot us an email at info developer.com uh check us out on the website you can leave us comments you can put comments uh down the show notes you can see stuff there all the different places you can connect with us but we will be back we're going to continue these discussions because as you can tell we have a lot to say about them and we have suffered through a lot of them and continue to do so so go out there and have yourself a great day a great week and we will talk to you next time and we'll wrap this one up as well um God this was like this is definitely like rabbit hole after rabbit like this is a total can worms there's so many things we can get into this uh which is why I wanted to start and I don't think I even got into like the reality and some of that stuff we touched on a little bit but I think this is going to be a recurring theme I I really think this is something that we we because both of us live it and get burned by it so often I think this is just one of those things that we're you know we're we're happy to preach on this well and it's funny too because what we just what you just saw us do going down this rabbit hole is very quickly what can happen when you get into a bidding war setting prices taking on contracts is once you get in there you can get into a rabbit hole of requirements a rabbit hole of changes that blow up a budget so these are just some things just a small section of things for you to consider as you get into this or as you grow your business yeah this is these are the things that can like make or break a business too it's say it's this is in itself another topic we'll probably cover along the way is that sometimes you get a a a customer that is big enough and want something enough that you're like cool I'll do that this is going to be great and then you get into it and you realize that no it's not great it's it's like the you didn't charge them enough you're not billing enough for the headache that it is or um you and sometimes they can they can handle that sometimes it is like somebody very deep podcast I've been in I was in a project one time that was supposed to be two months two years later they still hadn't gotten all their ducts they were almost there but they had tossed out three or four vendors they did all this kind of stuff they were doing they got sold a bill of goods to some extent but then you know they just they shot themselves in the foot several times as well I had another customer that was like they got sold by company that this is we can do this it's simple piece of cake all of it's going to work out it was not they we got six weeks into the project and they did not know how to solve the problem they said they were going to solve for like basically for free for this customer and so we had to say hey you're lying or whatever it is like you're you can't do this you just told me you can't do this I'm like well we'll convince the customer otherwise it's like well okay and then sure enough again two to three month PR Project A year later I think we finally had it sort of done because we had to go fix the other vendor problems these things are out there and you if you're just if you're working for yourself and you don't have the ability to like have a lot of if you don't have any wiggle room if you don't have any buffer that stuff can sink you because you're suddenly in a situation where you're locked into it with a customer um and I have horror stories I know of other people have been a situation where they're like in their customer is a multi-billion dollar International organization and that means they can sue the snot out of you they can own you and so you you want to be in a situation where you are covered or that you can just keep working you know like like I said wow we could spend multiple and we will spend multiple episodes talking about this but we've gone long so we're going to wrap this one up we will be back we're gonna continue just chirping away because that's what we do again I'm Rob he's Mike and we will talk to you next [Music] time
Transcript Segments
[Music]
hello and welcome back from where ever
you're coming back from uh you're
probably sitting in the same chair you
were before but now we're sitting in the
same chair we were as well so I guess we
never left as far as you you could be
that we never left you don't know uh we
do uh you there's lots of ways to do
that that'll be a different thing we'll
talk about like conspiracy theories or
something sometimes and go down one of
those rabbit holes this episode though I
want to swing back around couple
episodes back especially if you're here
on the video uh if you're listening to
podcast you may missed it because it was
bonus material basically but one of the
topics I had mentioned that we were
going to cover was like realistic
expectations was how do you deal with
customers and making sure that there was
Clarity and this customer could be uh it
could even be yourself sometimes but
definitely it could be your boss it
could be an actual like a customer and
how do you it's like sort of bad news
difficult conversations kinds of things
but it's it's things like hey it takes a
certain amount of work and effort and
time and cost to build something to do
something to accomplish something and so
it's how do you communicate that and it
is as I referred to it it's sort of like
that it is what it is is that there is a
level of just there's a minimum that has
to be done to do something and so
somebody may try to argue you down but
there's a point where it's like that's
not valid I can't do that it's like can
you do it in you know you say it's going
to take 10 hours can you do it in nine
all right maybe can you do it in eight I
don't know can you do it in one no
there's like there's stuff like that
where you're like all right stop
whittling it down and instead let's be
realistic um so we're gonna dive into
the podcast and we're gonna talk about
that we're gonna talk about reality and
Clarity and communication and it goes
back to I had a conversation the other
day with a customer and I think it just
really brought that to to light as far
as these are things that if you've got a
good customer and this guy
awesome um you know it's if you got a
good customer then it makes the whole
thing work better but it is a two-way
street so it's not just them being a
nice customer you've got to be clear and
honest and pursue the things that you
need to pursue so that you can let them
know what the risks are and as best as
you to your best of your ability is
allow them to make decisions that are
well informed that being said it's time
for us to dive into the podcast hello
and welcome back it is season 21 it is
episode some number I can't even
remember now like we're just chugging
along in our episodes working our way
through this season trust me it well
don't trust me because we may go further
but it's probably going to be another
one of those like 30ish episode Seasons
but we'll probably end up going into
just like a follow-up season that's
going to be the same kind of thing
because we're we have a lot that we want
to discuss we're we're getting into the
mentor Mastermind kind of approach we're
talking about like problems that we've
seen on a given week and guess what we
see new problems every day every week
and these are the kinds of things
because we are in the trenches just like
you are we're seeing things that are
going to help you out that you probably
are seeing as well and just as part of I
want to introduce myself because I don't
always do that this is Rob Broadhead I
am a Founder here at developer develop
preneur also uh found at RB consulting
which is my day job I guess this is my
side hustle if that if it's if that's a
thing uh in this case and so I do I am a
software consultant by day I do
specifically I do a lot of like it
assessments some people call these
things like fractional CTO CIO but also
we do like full full service we will
build your entire piece of software for
you or we'll tell you how to build your
software and show you like the best ways
to approach that that's me on the other
screen if you can see this just in the
other ear hole I guess if this is what
you're listening to is Michael Michael
why don't you goad and introduce
yourself hey everybody my name is
Michael Mage I'm also a co-founder
developer Nur I also am the founder of
Envision QA where I focus on my company
focuses on QA assessments where we help
companies look at their software
infrastructures and identify where
they're lacking in QA and we also offer
other testing services like unit testing
uh you know selenium test AB testing and
we also have the discussion with the
customers to try and flip the QA model
on its head you know don't wait till the
end to do the QA start the QA process
when you talk to the customer so that's
me and
welcome so I want to Dive Right into
this this little topic because it is a
it is one that I think a lot of us
particularly if we come out of a
developer type role technician type role
it it's harder for us to do this because
there is a level of sales and
communication and those things usually
are not attributed to us that are a part
of this now the first thing is we have
to have our ducks in a row I think we
need to really be realistic and this is
this is to just us that are developers
is that we need to to like break as much
as we can the mold the the like the hard
and fast rule that if a developer tells
you it's going to take x amount of hours
multiply it by two at least and if you
can even get it to multiply by 1.5
instead of two like just something that
you can bring it down closer to reality
that will help a lot because the problem
I think part of the reason there is a
I've got a little you know infographic
somewhere about this but one of the
things that's not discussed I think
often enough the reason why software
projects fail or over budget is because
the
developers yeah sometimes it's because
they just they didn't understand their
requirements they didn't really discuss
it right that kind of stuff A lot of
times though it's because we look at a
problem we say I can get that done in an
hour I can crank that sucker out I could
like throw some code spew some code run
it build it debug it test it boom done
and it's like it's GNA take me an hour
and then you find out that it actually
takes you two hours or four hours or
eight hours because we don't think about
or we don't factor in things like I had
a typo that was like it was a Capital C
instead of a lowercase C and it cost me
hour to find that in the code that I was
generating or I had a configuration
issue that blew stuff up or I chased
down the rabbit hole because I thought
my code was broken but it was actually
the API provider was just they had
broken their stuff there's just so many
ways software can go wrong that we need
to like buffer that in I know we want to
be aggressive we want to say hey if and
it's it is we look at we say hey I can
get this done in two hours
if if everything's good if everything's
going my way spoiler alert nothing is
going to go it's like that never happens
in my entire life I think I've had like
blocks of hours and maybe a day where
it's just like boom boom boom everything
fell into place everything was awesome
and I do it and that wasn't just you
know because I had been doing this for a
long time it's just because like I was
lucking out I needed to go buy a lottery
ticket at the end of the day there's
just stuff that happens so we need to be
realistic and think about that when we
are estimating things this like add some
of that wiggle room in because the more
like more often than not you're going to
find out that wiggle room that you
thought you were adding in gets just
gobbled up very very quickly thoughts on
that oh definitely so it's really
interesting hearing this conversation
because you know we live this all the
time and we had a discussion on this
recently
where you know we were talking about
doing a proposal for something and it's
like well here's the idea or the pseudo
requirements and being a tester I take
everything at face value so I take the
requirement and I immediately start
picking it apart I have I no longer
quickly throw out oh it's going to take
XY hours because you're right we never
really know the full situation the other
thing is is the requirement even the
requirement so there's been
conversations I've had with people where
it's like well I want this well okay
what is the user story what are are what
is the end result you're looking for and
walk it back to that requirement and a
lot of times they can't do that and the
moment that happens you realize that
okay so your initial requirement or your
initial request for what you want I'm
now going to tack on a week for
something that might be eight hours
simply because sure I'll write this but
then you're going to turn around and say
okay I want this and then you're going
to turn around you want this and that's
the scope cre because the requirements
are defined clearly enough to actually
estimate the job the other problem is in
their mind they have one thing that they
want and that's what they wrote down but
once they see it that's not what they
want so they're going to immediately
start scope creeping and that's what you
got to be careful of right I mean we
don't want to be in the situation where
we say yeah an hour but you've now scop
creeped in 40 hours worth of work um
it's not worth my
time and that's where I think Clarity
and communication comes in is that if
you're going to
be you know a hard ass about such stuff
or if you're going to be very detail
oriented then you need to be detail
oriented and you need to not just say
hey you know this is this could like and
sometimes I'll do I'll start with like
this could take anywhere between 10
hours and 10 years
because what you've given me we don't
have enough information but what you can
do is as you're digging into that and
you're asking the questions you're
getting answers is that you can evolve
that and and work it into ballparks and
things like that where you can say Okay
based on what you've said I think this
is where we're going to go it's going to
take x amount of or X range you know XY
range of hours and these are the things
that are concerns or these are the
things that I don't think either I know
we haven't
really you explored or that I don't
think we've explored enough so that you
got at least a hey this thing is sort of
known or maybe very well known and
that's awesome and we'll put an estimate
around that based on that we can make
assumptions about these other things but
those other things are to be determined
and here's roughly what it's going to be
because what's going to happen is you
want to have a customer coming into this
particularly when you're starting out
when they're they're working on this
project and deciding is it what's it
going to cost them or what's the value
of it and things like that is give them
an idea of what that's going to take now
if you've done things like this before
and they're thinking this is going to be
and it could be that's it's like really
simple really small you know it's going
to be a just picking a number like yeah
this is going to be a $500 project
potentially with what you've said it's
like if it's that simple great but then
warn them and say you know what I've
done this 10 different times and nine
times out of 10 that thing grew into a
$50,000 project because I don't care who
you are $500 is very different from
$50,000 and those are the things that
kill us and sometimes it it is it's like
it's going to be double or triple or
quadruple but you need to be able to go
into those saying
hey this is what we're looking at these
are our assumptions and let them know
sometimes like if if there are things
that you don't know is don't be afraid
to say hey this thing I haven't really
looked at or here's the assumptions I'm
making once those assumptions go out the
window then the estimates are basically
void because we built them based on
assumptions and I I've gotten like every
statement of work that I put out there
has some level of either questions that
are yet to be answered or assumptions
that are made or a lot of times both
because those are the things I'm going
to point to if things are going one way
or another and say this is where our
assumption was and it was wrong or it
got changed or it got added to and these
are the questions we had and those
answers cost us problems but we should
also be able to say when they answer
that question and you simply say oh
that's going to blow this up don't try
to hide it or obus skate or anything is
just say hey we didn't get this answered
until now now that you're telling me
this this is what I see and like I had
this like I said this sort of was
prompted by a discussion I had with the
customer where part of it was I said
look we're on track right now I said
what what I'm seeing for and we we'
already adjusted some stuff and I'm like
okay we're on track what I see however
this section that is towards the back
end of the track we haven't really
started on and I think it's going to be
okay based on what I'm learning because
I think we've like we're getting over
the humps but that could be a problem
and so it's just a little bit of a like
hey here's a warning that may be a
bigger problem but I think I've got to
it's reasonable to leave it there and
then I and and I actually even told him
I was like yeah we could I could buffer
that out more but I basically told him
like I'm gonna it's sort of like saying
this is an aggressive
estimate yeah we can probably do it but
it's a you know we have a 10% chance or
20% chance or 50-50 chance of making it
and then this is where we see at least
here here's what some of the things we
see that could be a bigger could cause
more you know issue I had another Pro
another customer that it basically it
totally blew up his um his project and
what his estimates were because he won
this is where he came to me with the
project he said it's basically done it's
like 99% there I just need you to drag
it across the finish line and he was
basing that on what his developer told
him his developer didn't know squat
apparent about where it was at it was
like that finishing piece was not 90%
99% of the way there it was there was a
lot of work and it was stuff there was a
lot of rework and so this thing that was
going to be 10 20 hours blew into
hundreds of hours and that's the kind of
stuff that you know if we've been able
to tell him that before he would have
had to like decide okay am I going to do
this but also we would have like the
whole Arrangement would have been very
different and ended up being not what we
wanted we ended up pouring a lot of
stuff into that
because we're like just we like the guy
we wanted to help them I've already
talked about I'm too nice sometimes
they're I'm a bad boy or whatever but we
wanted to help them we love this project
we wanted to do that but we ended up
throwing a lot of stuff into that and
then he still ended up a situation where
he was going to have to spend because we
weren't what they really needed we
weren't going to we were going to be
able to we could have like put more into
that and made it happen but it was now
going to cost us because we weren't
going to charge them but it's sort of a
blessing to us because now somebody else
is going to come in they're going to
charge them for that work and they're
probably they're going to find s like
more of that specialist so they can
hopefully get that thing done in less
time than we would have so it's like a a
win-win but this where you've got to be
honest about that stuff I think all of
us are the same way if we go in and we
need to get our car repaired and they
give us an estimate of 500 bucks and we
and we're like I ain't got 500 bucks but
but okay I've got to pay that to get my
car working if they come back and it's a
$5,000 bill we're going to freak out
we're going to say wait a minute I would
have sold the car I like I would have
like said that was it if IID known that
was what it was going to cost and so
those are the things that we need to
consider when we're putting together
these estimates and when we're
communicating with our
customers yeah so you've touched on
quite a few points there the first so
let me start with the end and kind of
work my way back so being upfront with
the cost is one of the biggest things
but sometimes the requirements or what
you hear from the
customer uh wasn't clearly defined or
it's too Loosely defined for example I
had someone that has an idea for an
application and they're like well it's
basically uh vbo but for this industry
well okay um can you give meet any more
requirements on that no that's basically
it and they're like well what you know
what kind of ideas or costs or things
are involved and so I spent 30 minutes
and just kind of worked up very high
level like you know here are just some
things to think about and then you know
I threw a price tag out there that was
going to be obscene because you don't
have the requirement so there's a lot of
discovery that needs to be involved a
lot of hidden thing I mean they really
have no idea what goes into the software
so I think I put it between 50 and
$150,000 because I mean it was going to
be a mobile app a desktop app there's
going to be e-commerce I mean there's so
many things I mean it that number could
easily been doubled but I was like
here's if you start here this is what
you're looking at now if you refine that
and say okay what do I need for a proof
of concept and you narrow that down okay
here you now Shrunk the requirements
you've now Shrunk the cost cuz now we
can clearly Define what it is so when
you're talking about that one customer
that came to you and said oh yeah this
product's nearly done this is one of
those times where I would have actually
said okay let's block out 10 hours we'll
bill you for 10 hours Let's Take or even
a couple hours do a cons a paid
consultation to walk through the
application with them their current
environment the current state of things
get a true assessment of what's going on
and then either take the job on at a
clear a a more refined estimate of what
you're walking into
versus kind of going in unknown so one
basically you're saying hey I'll do a
paid assessment I'll do that software
assessment for you figure out where
you're at are you being told what it is
is it really at a state you can get it
to where you need to go and maybe even
just give them peace of mind yes or no
and here's where you're looking you know
here's what you need to do and then and
then the other one as you're going
through these requirements or you
actually Define all the
requirements from a tester's perspective
I look at every ticket as what is the
statement of work what is the
requirement based on the requirement
what do I need to do to get this you
know basically what is the acceptance
criteria what is it that I need to do to
say that this unit of work is complete
what is testable what is not in scope of
this requirement or what is within scope
of this requirement and that also helps
you kind of narrow down your budgetary
hours you know we talked about one
proposal we were looking at doing it you
know I started out with about what 40 to
60 hours because you gave me a very high
level like oh here's an idea or you know
here's a statement of work for something
like this and I'm going to start high
because I have no idea what all the
nitpicky pieces are but then as we
started narrowing it down we got down
what about three days maybe four days of
work out of that so that's what you have
to consider as you're going through this
now where me and Rob differ a little bit
is I come at these from a tester's
perspective I come at from the user
perspective not So Much from the
developers uh perspective anymore and
that's just from years of writing tests
fighting with requirements reverse
engineering requirements because there's
no documentation for the software that
you're working on and it's like well
here make this
work how is it supposed to work we don't
know and then you're like oh wait a me
okay so what you want me to do and you
have no
documentation uh yeah your budget just
got blown because I now have to spend x
amount of time essentially learning your
application understanding what you have
because you clearly don't and then
you're expecting me to then build on top
of that so th these are a lot of the
things and problems you could run into
that you have to think about and there's
some forethought you can put into some
of these before you even do there like
we've talked about you know do like a 30
minute free call and talk through a
simple RP not a detailed RP or even a
software assessment or QA assessment you
know these are just some ways to help
shrink that uh the pricing that or your
budget for a particular project if that
makes sense yeah and I think you
mentioned uh because this is one that's
going to this is like again one of those
is an ongoing discussion is it you
mentioned a proof of concept and I think
that's
something that very often it is worth it
to to push a proof of concept or a
minimum viable product is to and a lot
of companies I've seen a lot of
customers that are starting to realize
this and it's like let's get something
that is definable that we can actually
like put our arms around and let's get
that done and figure out what that costs
and what it takes and and dig into that
and then we can figure out if we want to
go beyond it now I do see like this is
one of the things I've seen when I've
put proposals out I don't know how many
times I've had somebody say here's what
we want here's a request we want this
thing and I've had to send back I can't
give you I can if it's an hourly rate I
can give them like here's an hourly rate
but they'll say I want to fix bid and
this is what I want and I'll be like
it's it's impossible and it's funny
because I don't have that often that
they come back back to me so I think a
lot of them get burned and because
somebody says I can do that for $1,000
and they're like cool my budget was
2,000 I win but what happens is they
lose because it doesn't get done or it
gets done for $10,000 or more than that
and I will I will often go to them and
say exactly this kind of approach and
it's I've had a few that I have won a
project because I was just straight up
with them I said look this is I can't
give you any kind of ballpark with what
you've given you've given me something
that is very minimal these are just some
of the questions that need to be
answered these are some of the things
that you need to consider and then once
we can like I can get answers to those
then I can start putting together an
estimate and then we can start thinking
about what this is going to take but
again that's a lot of times what I'll do
is I'll say hey I'm gonna I will I'm
instead of bidding you know $50,000 for
what you think is a $50,000 project I'm
going to bid $500 and I'm going to go
spend a few hours and we're going to put
together a plan we're going to put
together some requirements or I'm going
to spend whatever it is figure out what
it's going to take and I use I will
adjust that based on a lot of times is
based on how big their project is if
they say hey this is a million dooll
project for
$10,000 I will help you put together
that plan if it's a $ th000 project then
I may say it's going to be you know
maybe it's only $100 or something like
that but I'll say hey we need the plan
first
uh sometimes it is they're like I've
only got a $1,000 budget I'm like well
you know what just to put the plan
together is going to cost you 500 of
that and so there's no way we're going
to hit your budget so you're G to have
to like adjust that uh and those are the
kinds of things where you you know get
up don't be afraid to step into those
and this is where again I've gotten
burned a couple times where it's like
hey this works this is there it's solid
things like that and you turn around and
you're like no it's not
all these things you said are there
they're not there you said there was
documentation it's not there you said
they have a bill no they don't or they
build it but they can't build that
anywhere but their machine there's those
kinds of things that you it's worth
checking that stuff out and this is
where I'm going to pause because I know
we're going a little long this time so I
want to wrap this one up and just say
you know what are some of your horror
stories feel free to share those with us
because we've got plenty and we will
continue to talk about them but you know
if you guys have anything shoot us an
email at info developer.com uh check us
out on the website you can leave us
comments you can put comments uh down
the show notes you can see stuff there
all the different places you can connect
with us but we will be back we're going
to continue these discussions because as
you can tell we have a lot to say about
them and we have suffered through a lot
of them and continue to do so so go out
there and have yourself a great day a
great week and we will talk to you next
time and we'll wrap this one up as well
um God this was like this is definitely
like rabbit hole after rabbit like this
is a total can worms there's so many
things we can get into this uh which is
why I wanted to start and I don't think
I even got into like the reality and
some of that stuff we touched on a
little bit but I think this is going to
be a recurring theme I I really think
this is something that we we because
both of us live it and get burned by it
so often I think this is just one of
those things that we're you know we're
we're happy to preach on
this well and it's funny too because
what we just what you just saw us do
going down this rabbit hole is very
quickly what can happen when you get
into a bidding war setting prices taking
on contracts is once you get in there
you can get into a rabbit hole of
requirements a rabbit hole of changes
that blow up a budget so these are just
some things just a small section of
things for you to consider as you get
into this or as you grow your
business yeah this is these are the
things that can like make or break a
business too it's say
it's this is in itself another topic
we'll probably cover along the way is
that sometimes you get a a a customer
that is big enough and want something
enough that you're like cool I'll do
that this is going to be great and then
you get into it and you realize that no
it's not great it's it's
like the you didn't charge them enough
you're not billing enough for the
headache that it is or um you and
sometimes they can they can handle that
sometimes it is like somebody very deep
podcast I've been in I was in a project
one time that was supposed to be two
months two years later they still hadn't
gotten all their ducts they were almost
there but they had tossed out three or
four vendors they did all this kind of
stuff they were doing they got sold a
bill of goods to some extent but then
you know they just they shot themselves
in the foot several times as well I had
another customer that was like they got
sold by company that this is we can do
this it's simple piece of cake all of
it's going to work out it was not they
we got six weeks into the project and
they did not know how to solve the
problem they said they were going to
solve for like basically for free for
this customer and so we had to say
hey you're lying or whatever it is like
you're you can't do this you just told
me you can't do this I'm like well we'll
convince the customer otherwise it's
like well okay and then sure enough
again two to three month PR Project A
year later I think we finally had it
sort of done because we had to go fix
the other vendor problems these things
are out there and you if you're just if
you're working for yourself and you
don't have the ability to like have a
lot of if you don't have any wiggle room
if you don't have any buffer that stuff
can sink you because you're suddenly in
a situation where you're locked into it
with a customer um and I have horror
stories I know of other people have been
a situation where they're like in their
customer is a multi-billion dollar
International organization and that
means they can sue the snot out of you
they can own you and so you you want to
be in a situation where you are covered
or that you can just keep working you
know like like I said wow we could spend
multiple and we will spend multiple
episodes talking about this but we've
gone long so we're going to wrap this
one up we will be back we're gonna
continue just chirping away because
that's what we do again I'm Rob he's
Mike and we will talk to you next
[Music]
time