Detailed Notes
Welcome back to the Develpreneur Podcast. This season, we focus on the developer's journey, helping you improve your craft and navigate the tech industry's challenges. This episode delves into customer success, mainly when working within budget constraints. Whether you’re building new systems or maintaining existing ones, delivering value to your customers without overspending is a crucial part of a developer’s journey. We'll explore strategies to manage project scope, communicate effectively, and ensure you and your clients succeed—even on a tight budget.
Read More... https://develpreneur.com/customer-success-delivering-value-on-a-budget
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources * How to write effective user stories in agile development? (https://develpreneur.com/how-to-write-effective-user-stories-in-agile-development/)
* The Importance of Properly Defining Requirements (https://develpreneur.com/the-importance-of-properly-defining-requirements/)
* Changing Requirements – Welcome Them For Competitive Advantage (https://develpreneur.com/changing-requirements-welcome-them-for-competitive-advantage/)
* Creating Your Product Requirements https://develpreneur.com/product-requirements/)
* Creating Use Cases and Gathering Requirements (https://develpreneur.com/creating-use-cases-and-gathering-requirements/)
Transcript Text
[Music] and we've hit record or something reasonably close to that uh this episode as we talked about last time I think we're going to dive right into imp part this because we're a little time constrained because of how our reality has been lately um and we'll go into this dos and don'ts for working with a customer you some of the things they like because they there's there's so many ways to try to like cut corners and do stuff and there are some things you really don't want to do and there are some things that look good and then they don't and it's how do you extract yourself from that and I have like recent pain points that I'm still bleeding from that are in these kinds of things and it's and it's also some ways to maybe like uh you know pitching your way back out of that once you found yourself you like dug a little bit of a hole or maybe a very big hole what are some things you can do to get out of that sounds good to you yeah and it also relates not just to our own consulting jobs but this also can apply to projects that you're on with companies so pay close attention to this because this applies to everyone so yeah spoiler you may be talking about that while I talk about the other one well hello and welcome back we are here continuing once again the developer Journey we are develop preneur building better developers podcast I am Rob Broadhead I am one of the founders of develop preneur also a founder of RB Consulting where we do we take your technology Nightmare and turn it into a sweet little dream is we use simplification Automation and integration to take all of those nasty systems and all those different websites and all those different logins and find ways to coales that into something that is a lean Sleek machine not necessarily a lean Sleek machine but maybe he is we'll find out on the other side is Michael and share with me what's like what's a good and a bad thing that's happened to you recently along with your general introduction hey everyone my name is Michael M I'm one of the founders of velur and co-founder of Envision QA where we help small to midsize businesses and clinicians analyze review their systems we do assessments and we help build custom software to make your business run more efficient good and bad so along this topic that we're going to be talking about today one of the good things that I ran into recently is I just got done doing a wonderful assessment with the customer we kind of laid out where we're going with our current project and right now now there are no blind spots and good communication back and forth and documentation bad side I had a recent project uh that went off the rails and we are still in the trenches trying to figure out what went wrong and dig ourselves out how about you ah let's see well I'm gonna go with a I'm gonna go good work related is uh you know sometimes you have these customers that have just they're they're ongoing customers and these guys we worked with them now for a couple years and they just came back with a cool little project they like hey we have this thing it's going to be a nice little like you know 20 30 Hour project maybe fun little stuff so those are always neat it's nice to just be able to jump into a nice little project well defined the requirements list is like you know a couple of bullet points and you're off and running bad thing actually happened coming back from a client visit yesterday uh go to like you know fill the car with gas and it rejected my car at like8 times turns out that because we are about to travel and there was a phone call made to try to say hey we're about to travel soon and my wife didn't have the right you know password or whatever they stru they like labeled it as a atrisk account and shut down everything so I had to actually it was basically I was going to have to call but by the time it's a gas station so by the time you call it's like no it's too much of a pain in the butt so you know swapped cards got that working but it was after like a 15minute call with the support guy trying to explain what was going on and say here's what we want to do and fine and they have to verify you 18 different ways and you have to like draw blood it's these things I I get security for you people that are in the risk world and things like that but just like everything else sometimes security is just too much of a headache speaking of headaches let's dive into this thing about customers and we're going to talk about customers and like when you really want to help a customer or sort of similar is like when they're trying to find ways to get something done on a budget or you at a lower cost now one of the things I'm going to talk I'm going to sort of go into a little bit of the don't and this is a it's going to sort of combine with some of the things that you can do now one of the things you can do is a lot of times particularly if it's a if it's work on an existing system or even honestly if it's creating news system is you can look at the requirements whatever they whatever case whatever state they are in and you can scope down you can be like hey we can you this is what we can do and so you know a good example is recently had one it's like hey there's this big picture of stuff we want to do cool we look at it and we get a little bit into it and find out that well some of those things were underestimated and we get a little further along and there's some adjustments and things were underestimated now you know you know the next thing you know you've gone from a little project to a very long project and now the scope's growing and the cost is growing and you know customers not happy because they were trying to get something small and what I want to talk a little bit about in that situation is a reset now there's two things one thing we've talked about a lot is that communica communicate communicate communicate is make sure that you are regularly providing feedback and say this is what we're working on this is what we're going to be working you know this is what we've done this week this is what we're doing next week or today and what we're going to do tomorrow things like that so they know where are you at where's your focus where's your head at that gives them an opportunity Time and Time and Time and Time Again to step in and say hey this seems to be this is taking longer than we wanted it to they can you know they can pull the plug on it they can say hey let's stop or let's hold off now sometimes what you need to do though is you're going to get into a point where you're like you are skipping ahead on some of this so maybe it's like hey initially this is what we were going to do and we didn't really need well-defined requirements for it and you may get to a certain point where you realize that oh now we've changed a little bit or a lot and we need to almost reset we need to go back to we need firm requirements and that's where that thing keeps going on sometimes it's like you know if you're in an agile project or something like that it's easy to get into something it's just like adjust adjust adjust adjust add you know and then next thing you you've just been like cranking through Sprint after Sprint after Sprint sometimes you need to stop back step back and say wait a minute we need a Finish Line we keep moving the Finish Line we have a moving Target so instead of let's keep you know and so and we like to do that we like to get that feedback we like to say oh I'll fix that I'll throw that in we'll change that we'll do this we blah blah blah and the next thing you know this thing is just keep keeps going instead reain it in and say okay what do we need what is done what does done look like what are the requirements that we really need let's refine those things let's make sure you know Define those be very precise with them and say okay this is what we are working toward and it's a little bit a change sometimes in going from an agile approach to more of a waterfall approach because so you know with agile you're sort of just you're working as you go with waterfall you really have said this is where we're at and when we're done this is where we're going to be and you're you're essentially eliminating the introduction of change into that now you can still do it you can have you know change requests and things like that but now you can do something that is very well defined and it gives them sometimes this is the comfort that not only the customer but you need in order to say okay I'm going to work two weeks on this or eight weeks on it or 18 years on it whatever your time frame is and this is what it's going to cost and this is where we're going to be and then along the way you make sure just like you did along the way here you're communicating here's where we are here's where we are here's where we are so you're you you should have Milestones within there and now you take this big thing that is amorphous and changing and you basically simplify it down and sometimes it is it's the idea of okay we're not going to take on the whole elephant we're going to take on a couple of bites and we're going to deal with that and those things although they can be I we call them those difficult conversations with a a customer because sometimes you're having to Rin stuff in or reset things and sometimes there's even a little maypa because you're saying well yeah we were able to do that but you know we assumed and it's you know we sort of thought that we could just do that because we were making adjustments and you were good with it okay you're not your budget is now getting constrained and you may be you may bring this to them or they may BRD bring it to you or there may be deadlines that they you know that have now become more apparent or more firm go in and address those things be honest and say okay what do we need to get to what what is our Runway at this point and you basically do like it you it's almost like a project reset you say all right what do we need to get done what are the requirements what can we get done how do we find a way to squeeze those in and if you can't squeeze all those requirements into the time frame they need then you got to pull require requirements out it's like okay how do we do that either we open the box up a little bit more so we can throw more requirements in or we take away some of those requirements or simplify some of those which is often a great approach to take where you say we're going to get you like a version one and it's going to be much more simple that'll get you across a Finish Line you've got something you can work with particularly if it's a company that's a startup or something so it's like hey this is your MVP you can take that you can move forward and then that allows them to bootstrap move mov forward now I know that's a lot and I'm sure Michael's got a hundred things to work on or he may go a completely different direction so I'm going to go Ahad and throw this to you apologies if I took all the oxygen out of the room yeah it's funny you say that so there are times when we talk about waterfall and agile but if you're starting a project for the first time there's got to be a little bit of waterfall at the beginning with the requirements Gathering because in unless it is a small project there either has to be some form of assessment at the beginning to understand what where they are currently at what environment are you walking into in order to build the requirements or even accept the requirements that they're giving you it's like hey I want this well okay what do you have and is what you're asking for really what you need so you kind of have that give and take at the beginning the story I'm going to kind of discuss here is one uh Rob came into later in our career where we worked at a place uh a long time ago the company had just come out of bankruptcy when I went to work for them and we weren't necessarily under the requirements constraint we were under a budget constraint we were a very slim team trying to do a lot of work very quickly to reduce costs with software over Manpower so we were essentially it was kind of a uh Pinsir attack of trying to eliminate uh workers but keep the same processes in place but with technology so fewer people could do the work the problem we had was no one really understood a lot of what was going on in different areas of the company because we had gone into bankruptcy there had been some uh turnover and we ran into a particular problem where we wanted this particular software built we're like sure let's throw something up quickly we did it was accepted well uh and we went from agile but we ran into a situation where the business's mind was we can go faster if we just copy and paste this project again and again and again foro the requirements we have this we can take this and we can just tweak it in an instance like that you might be trying to take a square peg and CR it into a round hole and you've introduced complexities that you don't need you've run into things where like Rob said you're trying to do more than what is really requested and in those situations you need as developer manager whatever to look at the situation you're in does it make sense to copy and paste a project or does it make more sense to look at the requirements you actually need for this new project and borrow things from the other project or you know do you need to just copy and paste sometimes that makes sense sometimes it makes more sense to just cherry-pick the things you need and build a new project that way the problem we ran into by the fourth iteration of this was we were now uh had common front-end pieces copied and pasted through all these applications and they wanted to do a sitewide change well the complexity went from here we just changed the CSS to now we have to touch recompile redeploy retest six different applications the cost just went through the roof so where we had made all those cost savings at the beginning we seriously got impacted at the end so there is some benefits to a little bit of requirements and scope at the beginning but as you go through the projects you need to reset you need even if you're doing doing waterfall especially if you're doing agile do those burnd Downs at the end of the Sprint are you on track are we moving the needle forward or are we stuck and if you're stuck start looking at what are the mus haves what do we need to do not the nice to haves start removing those nice to Hales push those out to Future Sprints and focus on getting a viable product out that is stable and that is functional interestingly enough if you go the test driven development approach and you start with requirements and you build out from that yes that's a little bit waterfall but if you do that in the previous Sprint if you have a good project manager that can go get that for you you start each Sprint with a fairly welldefined set of requirements and you can get the work done everyone knows what they need to do they know what they're agreeing to do and the customer also should know what they're getting at the end of the spring now one other thing I want to bring up is working with a customer that's budget constraint usually we are the the more expensive resource to use now I've had multiple situations where I've worked with customers particularly startup kind of situations but sometimes even larger organizations where and sometimes they're some of the best ones where it's like it's going to cost you you know $10,000 to get this thing done however if you go off and do some of the work work then it's going to cost you $2,000 yeah and these are I'm just making numbers up and I have a lot of times though I have I've walked into projects where I have worked with a customer and said okay and which goes to that whole assessment idea sometimes you can get into that even in an initial call and say hey I can do an assessment for you it's going to take you know whatever it is it's going to take 40 hours of my time or whatever your rate is and then I will come back and I will help you I will have for you a requirements document or you know maybe a project plan of milestones and things like that however if that's too much for them from a monetary point of view then you can push it back on them and say but you could do this if you walk through these things and you build the requirements document and you build the requirements out then we can I can take that that saves me from doing it which mean it save you from being build by me for doing that the the caution I would say with that is when you put something on a customer you have to it is very hard to hold their feet to the fire so if you say all right go ahead and do this and they come back and they have gaps it it really can become challenged because now you're in a situation where they saved quote saved that money by doing that but if there's gaps if they miss something something somewhere along the way now it's you know it's sort of your problem because you weren't able to build the solution they wanted but it does go back to improper requirements same kind of thing if you want to like sometimes and a lot of times we will have there's some level of testing that is expected for user acceptance testing you have to have an investment of time from a customer they can't just rubber stamp it and go you know this big thing that took you a year to build they can't spend 30 minutes and say yep it's all good looks great because it's going to end up they're going to miss something you know so you need to make sure sometimes that you handhold them through it sometimes that you even walk them through what is expected and then let them know if they are not capable of it for whatever reason whether it's like you they don't have the bandwidth or it's just not their skill set or whatever it is or they then say okay the alternative is more time and more money from you know your yourself whoever that contractor is so there is that give and take the caution to that is just making sure that when you start shifting that kind of stuff around that also shifts responsibilities and ownerships and things like that and that can cause you problems particularly now if it's directly with a customer and you're working with that customer it's great if you start getting a middle man in there I've even talked about I think back in I you know some of my season of mistakes when I talked about that there was one where I had the exactly that problem where I was I was working with the middleman the middleman was giving a different story to the customer and it ended up being a complete train wreck because everybody wasn't clear we weren't all on the same page that this is what's going on this is what the expectations are and so this is a I'll say it's like a bonus more advanced Consulting kind of move sometimes but sometimes you need to really you sort of push the customer and address them and send put requirements on them and ownership and such things to them and I've seen this with you know little sidehustle things up to Big organizations where the customer has they there are things maybe even in the you know the master Services agreement the statement of work it's expectations and they fail those and then you end up in trouble because now they have not followed through with what needed to be done usually that means it falls back on you because they're going to point to you and say well why isn't this working and it's really hard to say well because you didn't do your job because you didn't do what was expected of you and now you know you cut corners and now things didn't come out but this goes back to regular communication and making sure you're clear and requirements and who owns them and who's you know who does what those kinds of things can help you out quite a bit and don't be afraid to call your client out you know if you're doing when you're doing those regular Communications if you're not seeing progress from what they need a lot of time that's like data they need to give you or you know communic or uh contact information they need to give you or feedback on a on some sort of a form or something like that and just say hey I need this because your lack is slowing us down and I know that feels like it's a little harsh or whatever but it is something that as you get further into it that is part of even though they won't say it won't pay they won't necessarily they're not necessarily saying we're we're paying you to do this but some of it is is that what you're bringing to the table is helping them manage your projects better closing thoughts so one of the things that I've talked about this before is as you're working with the customer as you're working with the client or your boss if the tasks you're getting the requirements you're getting have a lot of wh ifs have a lot of assumptions a lot of if then but without then you need to go back and have a conversation before you start the work if there are gaps in the requirements to the point where you would have to make an assumption you need to have that hard talk with the customer with your boss because if you go into the work with assumptions and they're not clearly defined assumptions or defined risk then you're going to be in trouble down the road that is excellent little you know parting thought but you guys will not be in trouble down the road because you're listening to us because you're going to learn more and hopefully you will give us some feedback so we won't be in trouble down the road and we'll have some great topics for you you can shoot us an email at info@ develop nur. you can head out there develop nur. comom and we've got a contact us for you can go leave us feedback here whether you're watching us on YouTube or whether you are listening on the podcast wherever you gather your podcast feel free to leave us you know some sort of review back uh feedback and things like that because we will take a look at that we utilize that for future episodes and even future Seasons that being said we're going to wrap this one up and let you get back to it go out there and have yourself a great day a great week and we will talk to you next time bonus thought from me the sort of like you almost touch you sort of touched on this if you're going through a project whether it's you know where you're at work or side hustle or whatever is and things are not going right don't keep doing the same thing there's you know sometimes it's like okay I think we're almost there and this is actually the probably the hardest is when it's like we're almost there so we're going to stumble through this one more time and we're going to be and then we'll be fine and we'll fix it on the backside and is very difficult to do that particularly if you're being pushed to like you know we got to have this done we got you know we're on a deadline we're behind a deadline or whatever it is but even if it's small changes you need to be making changes along the way because if you keep doing the same thing don't expect that you're going to get different outcomes and now luckily this is where you can get some things where you can get very smart as a better developer then maybe if you're struggling and you're like I don't know how to get out of this thing say there's just things just don't seem to be working do one thing at a time keep the changes small and manageable so that you can look at it and say did that change move the needle in the right direction if it did awesome and then if you have to go through especially if you're doing something you're iterating a lot you know if you're like going through and you're doing something every day working on this project and there's a pain point there then every day tweak it a little bit and then if it works if it moves the needle in the right direction great incorporate that in if it doesn't then push that aside and try something else so that you can get a list of here's what we need to do to get out of this and sometimes you can do that while you're it feels it's a bad analogy but it's basically while you're going off the cliff you can be sitting there riding that you know riding the train off the cliff down to the valley below and be walking through some of these things so that you can say okay I'm working on this how about this how about this how about that so that hopefully you can maybe somewhere along the way just to keep some sort of analogy is find a parachute that will allow you to not totally you know Crash and Burn but in general you if you're sitting there and it's like you know you like okay we're going to do this and you come back too late two weeks later and it's like all right we're sort of in the same place that we were then you need to change if you moved but you haven't moved enough then it's time to take a look well what did we do where did we make those maybe those small changes so that we can incorporate those and then assess a couple things say all right let's make some more because if we've at least moved if we've at least made progress then we just want to make sure we're making better progress whatever our NE next cycle is whether it's a day a week a month however you do it that's my little bonus yours so interestingly enough ran into a situation like that recently and one other takeaway uh well I'll give you two things real quick so first if you think of your development cycle like a fishing attack if you get into the point where you're getting all these urgent emails and like hey do this quickly quickly that leads to mistakes that leads to problems that leads to information being given away that shouldn't be given away or essentially a project going off the rails in addition to that with you kind of going off that Cliff get the code or look at where you're at with the requirements can you get to a point where you can do a clean cut off and at least least get a release out so that you can keep start fresh like reset I know Rob mentioned you know getting to a point where you can kind of reset within but also you have to think releases in an agile world we want to keep that continuous integration continuous deployment if you get to the point where you've missed one release but oh we're almost there to that and then you miss the next release now get the code to a sable place where you can get the code out if it's a new feature disable the feature put the code out keep working on the feature but keep the code stable enough that you can keep fixing things while doing new work and the code can still go out the door it it can be difficult it can be trying but if you can keep that mindset you'll be mentally happier and your customer will be happier because they will still see incremental changes even if the big piece keeps moving a little bit they're still seeing work is getting done and that's really yeah just a follow that one up is it it is easy to get into that firefighting mode where it's just like we're going to like you know rush rush rush get it get it out get it out get it out get it out very you know all of a sudden your development Cycles turn you know shrink to nothing and it's just basically like right you're slinging code you know couple of tests and boom you're off and running but now what you end up doing is each of those iterations you are destabilizing stuff behind there because you're cranking this stuff out you're not doing a full Suite this is where would be although it's expensive it is nice to have it from the start regression test cicd and a lot of these pieces the challenge is if you've got a again if you've got a resource strapped customer some of those things are not able to do and there may come a point where you say look this has gotten to a level where we have to back up and we we were trying to avoid this but we have to it's sort of like you know we were trying to avoid rebuilding the engine to your car but we've done all this work and we can't we must rebuild it anything we do from here is just you know it's good money after bad basically and so sometimes that's the thing to do is just Halt and go okay we need to take a different approach and it could be painful it could be expensive because you've gone through this but it's also it's like hey we we worked with you you tried to cut the but you know we tried to cut cost with you we tried to work where can but there's part like it wasn't feasible it's like we you know we rolled the dice and it and Snake Eyes we didn't get it you know it's like sometimes that happens sometimes you roll the dice and it's okay sometimes you roll the dice and it does not work out well and that's where that's part of software if you you know just make sure that's where like as you're you know communicating along the way it's like okay we can do this but we're you know we're varying from what we would preferred to do and when you get to that point you need at least say it's not comfortable it's like hey sorry it didn't work out we we took the risk we took a couple shots at it didn't work now we need to back up we need to go the lowrisk approach straighten it out get it back on track that being said I guess I'll give you a parting shot before we wrap this one up is there anything else you want to throw out there in the bonus section here now I think we've kind of extended this one a little bit longer than normal but uh you know if you guys find yourself in these situations take a break take a step back review where you're at even if you're in figh or fighting mode take a few minutes and understand why you're in figh or fighting mode because even a mental snapshot of where you're at can help move the dial forward sometimes it's a few minutes sometimes it's going to be a little longer than that particularly if you get into the like you know consecutive late nights no sleep you know that kind of stuff sometimes you need to step away for it's going to take a couple days because you need to reset you need to get healthy and you need to be able to get out of it enough to be able to give it you know give it a good uh assessment as opposed to just being in the middle of it when you're you're not that much you know you're not that good to anybody so that being said hopefully you're not in this situation you're having a grand old time and you're like what the heck what are you guys talking about my software problems are non-existent all of my stuff gets done perfectly we never have bugs we always release on time I want to talk to you if you're that person because we got to figure out what you're doing that is allows you to do this thing that a lot of us don't think happens we see we're like all we see is all of the challenges we do not see Perfection anywhere around us as always you can shoot us an email info developer.com check stuff out here come here you get bonus like extra extra bonus stuff like this sometimes and we go a little bit long but that should help you out a little bit we're always happy with feedback you know questions comments or if you've got your own little bonus material stuff that you want to throw out on these we would love to hear it that being said go out there and have yourself a good one we will talk to you next time [Music]
Transcript Segments
[Music]
and we've hit record or something
reasonably close to
that uh this episode as we talked about
last time I think we're going to dive
right
into imp part this because we're a
little time constrained because of how
our reality has been lately um and we'll
go into this dos and don'ts for working
with a customer you some of the things
they like because they there's there's
so many ways to try to like cut corners
and do stuff and there are some things
you really don't want to do and there
are some things that look good and then
they don't and it's how do you extract
yourself from that and I have like
recent pain points that I'm still
bleeding from that are in these kinds of
things and it's and it's also some ways
to maybe like uh you know pitching your
way back out of that once you found
yourself you like dug a little bit of a
hole or maybe a very big hole what are
some things you can do to get out of
that sounds good to you yeah and it also
relates not just to our own consulting
jobs but this also can apply to projects
that you're on with companies so pay
close attention to this because this
applies to everyone so yeah spoiler you
may be talking about that while I talk
about the other one well hello and
welcome back we are here continuing once
again the developer Journey we are
develop preneur building better
developers podcast I am Rob Broadhead I
am one of the founders of develop
preneur also a founder of RB Consulting
where we
do we take your technology Nightmare and
turn it into a sweet little dream is we
use simplification Automation and
integration to take all of those nasty
systems and all those different websites
and all those different logins and find
ways to coales that into something that
is a lean Sleek
machine not necessarily a lean Sleek
machine but maybe he is we'll find out
on the other side is Michael and share
with me what's like what's a good and a
bad thing that's happened to you
recently along with your general
introduction hey everyone my name is
Michael M I'm one of the founders of
velur and co-founder of Envision QA
where we help small to midsize
businesses and clinicians analyze review
their systems we do assessments and we
help build custom software to make your
business run more efficient good and bad
so along this topic that we're going to
be talking about today one of the good
things that I ran into recently is I
just got done doing a wonderful
assessment with the customer we kind of
laid out where we're going with our
current project and right now now there
are no blind spots and good
communication back and forth and
documentation bad side I had a recent
project uh that went off the rails and
we are still in the trenches trying to
figure out what went wrong and dig
ourselves out how about you ah let's see
well I'm gonna go with a I'm gonna go
good work related is uh you know
sometimes you have these customers that
have just they're they're ongoing
customers and these guys we worked with
them now for a couple years and they
just came back with a cool little
project they like hey we have this thing
it's going to be a nice little like you
know 20 30 Hour project maybe fun little
stuff so those are always neat it's nice
to just be able to jump into a nice
little project well defined the
requirements list is like you know a
couple of bullet points and you're off
and running bad thing actually happened
coming back from a client visit
yesterday uh go to like you know fill
the car with gas and it rejected my car
at like8 times turns out that because we
are about to travel and there was a
phone call made to try to say hey we're
about to travel soon and my wife didn't
have the right you know password or
whatever they stru they like labeled it
as a atrisk account and shut down
everything so I had to actually it was
basically I was going to have to call
but by the time it's a gas station so by
the time you call it's like no it's too
much of a pain in the butt so you know
swapped cards got that working but it
was after like a 15minute call with the
support guy trying to explain what was
going on and say here's what we want to
do and fine and they have to verify you
18 different ways and you have to like
draw blood it's these things I I get
security for you people that are in the
risk world and things like that but just
like everything else sometimes security
is just too much of a
headache speaking of headaches let's
dive into this thing
about customers and we're going to talk
about customers and like when you really
want to help a customer or sort of
similar is like when they're trying to
find ways to get something done on a
budget or you at a lower cost now one of
the things I'm going to talk I'm going
to sort of go into a little bit of the
don't and this is a it's going to sort
of combine with some of the things that
you can do now one of the things you can
do is a lot of times particularly if
it's a if it's work on an existing
system or even honestly if it's creating
news system is you can look at the
requirements whatever they whatever case
whatever state they are in and you can
scope down you can be like hey we can
you this is what we can do and so you
know a good example is recently had one
it's like hey there's this big picture
of stuff we want to do cool we look at
it and we get a little bit into it and
find out that
well some of those things were
underestimated and we get a little
further along and there's some
adjustments and things were
underestimated now you know you know the
next thing you know you've gone from a
little project to a very long project
and now the scope's growing and the cost
is growing and you know customers not
happy because they were trying to get
something small and what I want to talk
a little bit about in that situation is
a reset now there's two things one thing
we've talked about a lot is that
communica communicate communicate
communicate is make sure that you are
regularly providing feedback and say
this is what we're working on this is
what we're going to be working you know
this is what we've done this week this
is what we're doing next week or today
and what we're going to do tomorrow
things like that so they know where are
you at where's your focus where's your
head at that gives them an opportunity
Time and Time and Time and Time Again to
step in and say hey this seems to be
this is taking longer than we wanted it
to they can you know they can pull the
plug on it they can say hey let's stop
or let's hold off now sometimes what you
need to do though is you're going to get
into a point where you're like you are
skipping ahead on some of this so maybe
it's like hey initially this is what we
were going to do and we didn't really
need well-defined requirements for it
and you may get to a certain point where
you realize that oh now we've changed a
little bit or a lot and we need to
almost reset we need to go back to we
need firm requirements and that's where
that thing keeps going on sometimes it's
like you know if you're in an agile
project or something like that it's easy
to get into something it's just like
adjust adjust adjust adjust add you know
and then next thing you you've just been
like cranking through Sprint after
Sprint after Sprint sometimes you need
to stop back step back and say wait a
minute we need a Finish Line we keep
moving the Finish Line we have a moving
Target so instead of let's keep you know
and so and we like to do that we like to
get that feedback we like to say oh I'll
fix that I'll throw that in we'll change
that we'll do this we blah blah blah and
the next thing you know this thing is
just keep keeps going instead reain it
in and say okay what do we need what is
done what does done look like what are
the requirements that we really need
let's refine those things let's make
sure you know Define those be very
precise with them and say okay this is
what we are working toward and it's a
little bit a change sometimes in going
from an agile approach to more of a
waterfall approach because so you know
with agile you're sort of just you're
working as you go with waterfall you
really have said this is where we're at
and when we're done this is where we're
going to be and you're you're
essentially eliminating the introduction
of change into that now you can still do
it you can have you know change requests
and things like that but now you can do
something that is very well defined and
it gives them sometimes this is the
comfort that not only the customer but
you need in order to say okay I'm going
to work two weeks on this or eight weeks
on it or 18 years on it whatever your
time frame is and this is what it's
going to cost and this is where we're
going to be and then along the way you
make sure just like you did along the
way here you're communicating here's
where we are here's where we are here's
where we are so you're you you should
have Milestones within there and now you
take this big thing that is amorphous
and changing and you basically simplify
it down and sometimes it is it's the
idea of okay we're not going to take on
the whole elephant we're going to take
on a couple of bites and we're going to
deal with
that and those things although they can
be I we call them those difficult
conversations with a a customer because
sometimes you're having to Rin stuff in
or reset things and sometimes there's
even a little maypa because you're
saying well yeah we were able to do that
but you know we assumed and it's you
know we sort of thought that we could
just do that because we were making
adjustments and you were good with it
okay you're not your budget is now
getting constrained and you may be you
may bring this to them or they may BRD
bring it to you or there may be
deadlines that they you know that have
now become more apparent or more
firm go in and address those things be
honest and say okay what do we need to
get to what what is our Runway at this
point and you basically do like it you
it's almost like a project reset you say
all right what do we need to get done
what are the requirements what can we
get done how do we find a way to squeeze
those in and if you can't squeeze all
those requirements into the time frame
they need then you got to pull require
requirements out it's like okay how do
we do that either we open the box up a
little bit more so we can throw more
requirements in or we take away some of
those requirements or simplify some of
those which is often a great approach to
take where you say we're going to get
you like a version one and it's going to
be much more simple that'll get you
across a Finish Line you've got
something you can work with particularly
if it's a company that's a startup or
something so it's like hey this is your
MVP you can take that you can move
forward and then that allows them to
bootstrap move mov forward now I know
that's a lot and I'm sure Michael's got
a hundred things to work on or he may go
a completely different direction so I'm
going to go Ahad and throw this to you
apologies if I took all the oxygen out
of the
room yeah it's funny you say that so
there are
times when we talk about waterfall and
agile but if you're starting a project
for the first time there's got to be a
little bit of waterfall at the beginning
with the requirements Gathering because
in unless it is a small project there
either has to be some form of assessment
at the beginning to understand what
where they are currently at what
environment are you walking
into in order to build the requirements
or even accept the requirements that
they're giving you it's like hey I want
this well okay what do you have and is
what you're asking for really what you
need so you kind of have that give and
take at the beginning
the story I'm going to kind of discuss
here is one uh Rob came into later in
our career where we worked at a place uh
a long time ago the company had just
come out of bankruptcy when I went to
work for them and we weren't necessarily
under the requirements constraint we
were under a budget constraint we were a
very slim team trying to do a lot of
work very quickly to reduce costs with
software over Manpower so we were
essentially it was kind of a uh Pinsir
attack of trying to eliminate uh workers
but keep the same processes in place but
with technology so fewer people could do
the work the problem we had was no one
really understood a lot of what was
going on in different areas of the
company because we had gone into
bankruptcy there had been some uh
turnover and we ran into a particular
problem where we wanted this particular
software built we're like sure let's
throw something up quickly we did it was
accepted well uh and we went from agile
but we ran into a situation where the
business's mind was we can go faster if
we just copy and paste this project
again and again and again foro the
requirements we have this we can take
this and we can just tweak
it in an instance like that you might be
trying to take a square peg and CR it
into a round hole and you've introduced
complexities that you don't need you've
run into things where like Rob said
you're trying to do more than what is
really requested and in those situations
you need as developer manager whatever
to look at the situation you're in does
it make sense to copy and paste a
project or does it make more sense to
look at the requirements you actually
need for this new project and borrow
things from the other project or you
know do you need to just copy and paste
sometimes that makes sense sometimes it
makes more sense to just cherry-pick the
things you need and build a new project
that way the problem we ran into by the
fourth iteration of this was we were now
uh had common front-end pieces copied
and pasted through all these
applications and they wanted to do a
sitewide change well the complexity went
from here we just changed the CSS to now
we have to touch recompile redeploy
retest six different applications the
cost just went through the roof so where
we had made all those cost savings at
the beginning we seriously got impacted
at the end so there is some benefits to
a little bit of requirements and scope
at the beginning but as you go through
the projects you need to reset you need
even if you're doing doing waterfall
especially if you're doing agile do
those burnd Downs at the end of the
Sprint are you on track are we moving
the needle forward or are we stuck and
if you're stuck start looking at what
are the mus haves what do we need to do
not the nice to haves start removing
those nice to Hales push those out to
Future Sprints and focus on getting a
viable product out that is stable and
that is functional interestingly enough
if you go the test driven development
approach and you start with requirements
and you build out from that yes that's a
little bit waterfall but if you do that
in the previous Sprint if you have a
good project manager that can go get
that for you you start each Sprint with
a fairly welldefined set of requirements
and you can get the work done everyone
knows what they need to do they know
what they're agreeing to do and the
customer also should know what they're
getting at the end of the
spring now one other thing I want to
bring up is working with a customer
that's budget
constraint usually we are the the more
expensive resource to use now I've had
multiple situations where I've worked
with customers particularly startup kind
of situations but sometimes even larger
organizations where and sometimes
they're some of the best ones where it's
like it's going to cost you you know
$10,000 to get this thing done however
if you go off and do some of the work
work then it's going to cost you $2,000
yeah and these are I'm just making
numbers up and I have a lot of times
though I have I've walked into projects
where I have worked with a customer and
said okay and which goes to that whole
assessment
idea sometimes you can get into that
even in an initial call and say hey I
can do an assessment for you it's going
to take you know whatever it is it's
going to take 40 hours of my time or
whatever your rate is and then I will
come back and I will help you I will
have for you a requirements document or
you know maybe a project plan of
milestones and things like that however
if that's too much for them from a
monetary point of view then you can push
it back on them and say but you could do
this if you walk through these things
and you build the requirements document
and you build the requirements out then
we can I can take that that saves me
from doing it which mean it save you
from being build by me for doing
that the the caution I would say with
that is when you put something on a
customer you have to it is very hard to
hold their feet to the fire so if you
say all right go ahead and do this and
they come back and they have
gaps it it really can become challenged
because now you're in a situation where
they saved quote saved that money by
doing that but if there's gaps if they
miss something
something somewhere along the way now
it's you know it's sort of your problem
because you weren't able to build the
solution they wanted but it does go back
to improper requirements same kind of
thing if you want to like sometimes and
a lot of times we will have there's some
level of testing that is expected for
user acceptance testing you have to have
an investment of time from a customer
they can't just rubber stamp it and go
you know this big thing that took you a
year to build they can't spend 30
minutes and say yep it's all good looks
great because it's going to end up
they're going to miss something you know
so you need to make sure sometimes that
you handhold them through it sometimes
that you even walk them through what is
expected and then let them know if they
are not capable of it for whatever
reason whether it's like you they don't
have the bandwidth or it's just not
their skill set or whatever it is or
they then say okay the alternative is
more time and more money from you know
your yourself whoever that contractor is
so there is that give and take the
caution to that is just making sure that
when you start shifting that kind of
stuff around that also shifts
responsibilities and ownerships and
things like that and that can cause you
problems particularly now if it's
directly with a customer and you're
working with that customer it's great if
you start getting a middle man in there
I've even talked about I think back in I
you know some of my season of mistakes
when I talked about that there was one
where I had the exactly that problem
where I was I was working with the
middleman the middleman was giving a
different story to the customer and it
ended up being a complete train wreck
because everybody wasn't clear we
weren't all on the same page that this
is what's going on this is what the
expectations are and so this is a I'll
say it's like a bonus more advanced
Consulting kind of move sometimes but
sometimes you need to really you sort of
push the customer and address them and
send put requirements on them and
ownership and such things to them and
I've seen this with you know little
sidehustle things up to Big
organizations where the customer has
they there are things maybe even in the
you know the master Services agreement
the statement of work it's expectations
and they fail those and then you end up
in trouble because now they have not
followed through with what needed to be
done usually that means it falls back on
you because they're going to point to
you and say well why isn't this working
and it's really hard to say well because
you didn't do your job because you
didn't do what was expected of you and
now you know you cut corners and now
things didn't come out but this goes
back to regular communication and making
sure you're clear and requirements and
who owns them and who's you know who
does what those kinds of things can help
you out quite a bit and don't be afraid
to call your client out you know if
you're doing when you're doing those
regular Communications if you're not
seeing progress from what they need a
lot of time that's like data they need
to give you or you know communic or uh
contact information they need to give
you or feedback on a on some sort of a
form or something like that and just say
hey I need this because your lack is
slowing us
down and I know that feels like it's a
little harsh or whatever but it is
something that as you get further into
it that is part of even though they
won't say it won't pay they won't
necessarily they're not necessarily
saying we're we're paying you to do this
but some of it is is that what you're
bringing to the table is helping them
manage your projects better closing
thoughts so one of the things that I've
talked about this before is as you're
working with the customer as you're
working with the client or your boss if
the tasks you're getting the
requirements you're getting have a lot
of wh ifs have a lot of assumptions a
lot of if then but without then you need
to go back and have a conversation
before you start the work if there are
gaps in the requirements to the point
where you would have to make an
assumption you need to have that hard
talk with the customer with your boss
because if you go into the work with
assumptions and they're not clearly
defined assumptions or defined risk then
you're going to be in trouble down the
road that is excellent little you know
parting thought but you guys will not be
in trouble down the road because you're
listening to us because you're going to
learn more and hopefully you will give
us some feedback so we won't be in
trouble down the road and we'll have
some great topics for you you can shoot
us an email at info@ develop nur. you
can head out there develop nur. comom
and we've got a contact us for you can
go leave us feedback here whether you're
watching us on YouTube or whether you
are listening on the podcast wherever
you gather your podcast feel free to
leave us you know some sort of review
back uh feedback and things like that
because we will take a look at that we
utilize that for future episodes and
even future Seasons that being said
we're going to wrap this one up and let
you get back to it go out there and have
yourself a great day a great week and we
will talk to you next
time bonus thought from me the sort of
like you almost touch you sort of
touched on
this if you're going through a project
whether it's you know where you're at
work or side hustle or whatever is and
things are not going
right don't keep doing the same thing
there's you know sometimes it's like
okay I think we're almost there and this
is actually the probably the hardest is
when it's like we're almost
there so we're going to stumble through
this one more time and we're going to be
and then we'll be fine and we'll fix it
on the backside and is very difficult to
do that particularly if you're being
pushed to like you know we got to have
this done we got you know we're on a
deadline we're behind a deadline or
whatever it is
but even if it's small changes you need
to be making changes along the way
because if you keep doing the same thing
don't expect that you're going to get
different outcomes and now luckily this
is where you can get some things where
you can get very smart as a better
developer then maybe if you're
struggling and you're like I don't know
how to get out of this thing say there's
just things just don't seem to be
working do one thing at a time keep the
changes small and manageable so that you
can look at it and say did that change
move the needle in the right direction
if it did awesome and then if you have
to go through especially if you're doing
something you're iterating a lot you
know if you're like going through and
you're doing something every day working
on this project and there's a pain point
there then every day tweak it a little
bit and then if it works if it moves the
needle in the right direction great
incorporate that in if it doesn't then
push that aside and try something else
so that you can get a list of here's
what we need to do to get out of this
and sometimes you can do that while
you're it feels it's a bad analogy but
it's basically while you're going off
the
cliff you can be sitting there riding
that you know riding the train off the
cliff down to the valley below and be
walking through some of these things so
that you can say okay I'm working on
this how about this how about this how
about that so that hopefully you can
maybe somewhere along the way just to
keep some sort of analogy is find a
parachute that will allow you to not
totally you know Crash and Burn
but in general you if you're sitting
there and it's like you know you like
okay we're going to do this and you come
back too late two weeks later and it's
like all right we're sort of in the same
place that we were then you need to
change if you moved but you haven't
moved enough then it's time to take a
look well what did we do where did we
make those maybe those small changes so
that we can incorporate those and then
assess a couple things say all right
let's make some more because if we've at
least moved if we've at least made
progress then we just want to make sure
we're making better progress whatever
our NE next cycle is whether it's a day
a week a month however you do it that's
my little bonus yours so interestingly
enough ran into a situation like that
recently and one other takeaway uh well
I'll give you two things real quick so
first if you think of your development
cycle like a fishing attack if you get
into the point where you're getting all
these urgent emails and like hey do this
quickly quickly that leads to mistakes
that leads to problems that leads to
information being given away that
shouldn't be given away or essentially a
project going off the
rails in addition to that with you kind
of going off that
Cliff get the code or look at where
you're at with the requirements can you
get to a point where you can do a clean
cut off and at least least get a release
out so that you can keep start fresh
like
reset I know Rob mentioned you know
getting to a point where you can kind of
reset within but also you have to think
releases in an agile world we want to
keep that continuous integration
continuous deployment if you get to the
point where you've missed one release
but oh we're almost there to that and
then you miss the next release now get
the code to a sable place where you can
get the code out if it's a new feature
disable the feature put the code out
keep working on the
feature but keep the code stable enough
that you can keep fixing things while
doing new work and the code can still go
out the door it it can be difficult it
can be trying but if you can keep that
mindset you'll be mentally happier and
your customer will be happier because
they will still see incremental changes
even if the big piece keeps moving a
little bit they're still seeing work is
getting done and that's really yeah just
a follow that one up is it it is easy to
get into that firefighting mode where
it's just like we're going to like you
know rush rush rush get it get it out
get it out get it out get it out very
you know all of a sudden your
development Cycles turn you know shrink
to nothing and it's just basically like
right you're slinging code you know
couple of tests and boom you're off and
running but now what you end up doing is
each of those iterations you
are destabilizing stuff behind there
because you're cranking this stuff out
you're not doing a full Suite this is
where would be although it's expensive
it is nice to have it from the start
regression test cicd and a lot of these
pieces the challenge is if you've got a
again if you've got a resource strapped
customer some of those things are not
able to do and there may come a point
where you say look this has gotten to a
level where we have to back up and we we
were trying to avoid this but we have to
it's sort of like you know we were
trying to avoid rebuilding the engine to
your car but we've done all this work
and we can't we must rebuild it anything
we do from here is just you know it's
good money after bad basically and so
sometimes that's the thing to do is just
Halt and go okay we need to take a
different approach and it could be
painful it could be expensive because
you've gone through this but it's also
it's like hey we we worked with you you
tried to cut the but you know we tried
to cut cost with you we tried to work
where can but there's part like it
wasn't feasible it's like we you know we
rolled the dice and it and Snake Eyes we
didn't get it you know it's like
sometimes that happens sometimes you
roll the dice and it's okay sometimes
you roll the dice and it does not work
out well and that's where that's part of
software if you you know just make sure
that's where like as you're you know
communicating along the way it's like
okay we can do this but we're you know
we're varying from what we would
preferred to do and when you get to that
point you need at least say it's not
comfortable it's like hey
sorry it didn't work out we we took the
risk we took a couple shots at it didn't
work now we need to back up we need to
go the lowrisk approach straighten it
out get it back on
track that being said I guess I'll give
you a parting shot before we wrap this
one up is there anything else you want
to throw out there in the bonus section
here now I think we've kind of extended
this one a little bit longer than normal
but uh you know if you guys find
yourself in these situations take a
break take a step back review where
you're at even if you're in figh or
fighting
mode take a few minutes and understand
why you're in figh or fighting mode
because even a mental snapshot of where
you're at can help move the dial
forward sometimes it's a few minutes
sometimes it's going to be a little
longer than that particularly if you get
into the like you know consecutive late
nights no sleep you know that kind of
stuff sometimes you need to step away
for it's going to take a couple days
because you need to reset you need to
get healthy and you need to be able to
get out of it enough to be able to give
it you know give it a good uh assessment
as opposed to just being in the middle
of it when you're you're not that much
you know you're not that good to anybody
so that being said hopefully you're not
in this situation you're having a grand
old time and you're like what the heck
what are you guys talking about my
software problems are non-existent all
of my stuff gets done perfectly we never
have bugs we always release on time I
want to talk to you if you're that
person because we got to figure out what
you're doing that is allows you to do
this thing that a lot of us don't think
happens we see we're like all we see is
all of the challenges we do not see
Perfection anywhere around us as always
you can shoot us an email info
developer.com check stuff out here come
here you get bonus like extra extra
bonus stuff like this sometimes and we
go a little bit long but that should
help you out a little bit we're always
happy with feedback you know questions
comments or if you've got your own
little bonus material stuff that you
want to throw out on these we would love
to hear it that being said go out there
and have yourself a good one we will
talk to you next time
[Music]