Customer Success - Delivering Value on a Budget

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are here continuing once again the developer journey. We are Developer Nord, Building Better Developers podcast. I am Rob Broadhead. I am one of the founders of Developer Nord, also a founder of RB Consulting, where we take your technology nightmare and turn it into a sweet little dream as 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 coalesce that into something that is a lean, sleek machine. Not necessarily a lean, sleek machine, but maybe it is. We will find out. On the other side is Michael, and share with me what is a good and a bad thing that has happened to you recently along with your general introduction. Hey everyone, my name is Michael Milosh. I am one of the founders of Developer Nord and co-founder of Envision QA, where we help small to mid-sized businesses and clinicians analyze and review their systems. We do assessments and we help build custom software to make your business run more efficient. Good and bad. On this topic that we are 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 are going with our current project, and right now there are no blind spots and good communication back and forth and documentation. Bad side, I had a recent project 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? Let's see, I am going to go with a good work related. Sometimes you have these customers that are ongoing customers. These guys, we have worked with them now for a couple of years and they just came back with a cool little project like, hey we have this thing, it is going to be a nice little 20, 30 hour project maybe, fun little stuff. Those are always neat. It is nice to just be able to jump into a nice little project, well defined. The requirements list is like a couple of bullet points and you are off and running. Bad thing actually happened coming back from a client visit yesterday. Go to fill the car with gas and it rejected my card like eight times. Turns out that because we are about to travel and there was a phone call made to try to say hey we are about to travel soon and my wife did not have the right password or whatever, and they labeled it as an at risk 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 is a gas station, so by the time you call it is like no, it is too much of a pain in the butt. So I swapped cards, got that working, but it was after like a 15 minute call with the support guy trying to explain what was going on and say here is what we want to do and fine and they have to verify you 18 different ways and you have to like draw blood. I get security for 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 are going to talk about customers and when you really want to help a customer or sort of similar to when they are trying to find ways to get something done on a budget or you are at a lower cost. Now one of the things I am going to talk about, I am going to sort of go into a little bit of the don'ts and this is 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 is work on an existing system or even honestly if it is creating a new system is you can look at the requirements whatever case, whatever state they are in and you can scope down. You can be like, hey, this is what we can do. A good example is where you say hey, there is 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 are some adjustments and things are underestimated. Now the next thing you know, you have gone from a little project to a very long project and now the scope is growing and the cost is growing and the customer is not happy because they were trying to get something small. What I want to talk a little bit about in that situation is a reset. Now there are two things. One thing we have talked about a lot is that communicate, communicate, communicate, communicate is make sure that you are regularly providing feedback and say this is what we are working on, this is what we are going to be working on, this is what we have done this week, this is what we are going to do next week or today and what we are going to do tomorrow, things like that. So, they know where you are at, where is your focus, where is 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 pull the plug on it, they can say hey let's stop or let's hold off. Sometimes what you need to do though is you are going to get into a point where you are skipping ahead on some of this stuff. So maybe it is 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 have 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 is where that thing keeps going on. Sometimes it is like if you are in an agile project or something like that it is easy to get into something that is just like adjust, adjust, adjust, adjust, add and the next thing you know you have just been like cranking through sprint after sprint after sprint. Sometimes you need to 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, and we like to do that, we like to get that feedback, we like to say oh I will fix that, I will throw that in, we will change that, we will do this, we will do blah, blah, blah, and the next thing you know this thing just keeps going. Instead rein 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 is a little bit a change sometimes in going from an agile approach to more of a waterfall approach because you know with agile you are sort of just you are working as you go. With waterfall you really have said this is where we are at and when we are done this is where we are going to be and you are essentially eliminating the introduction of change into that. Now you can still do it, you can have 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 am 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 is going to cost and this is where we are going to be and then along the way you make sure just like you did along the way here you are communicating here is where we are, here is where we are, here is where we are so 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 is the idea of okay we are not going to take on the whole elephant, we are going to take on a couple of bites and we are going to deal with that and those things although they can be, we will call them those difficult conversations with a customer because sometimes you are having to reign stuff in or reset things and sometimes there is even a little mea culpa because you are saying well yeah we were able to do that but we assumed and it is, we sort of thought that we could just do that because we were making adjustments and you were good with it okay you are not, your budget is now getting constrained and you may be, you may bring this to them or they may 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 is our runway at this point and you basically do like, it is almost like a project reset is 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 cannot squeeze all those requirements into the timeframe they need then you have got to pull requirements out and say 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 are going to get you like a version one and it is going to be much more simple, that will get you across the finish line, you have got something you can work with particularly if it is a company or a startup or something, so it is like hey this is your MVP, you can take that, you can move forward and then that allows them to bootstrap moving forward. Now I know that is a lot and I am sure Michael has got a hundred things to work on or he may go a completely different direction so I am going to go ahead and throw this to you, apologies if I took all the oxygen out of the room. It is funny you say that, so there are times when we talk about waterfall and agile but if you are starting a project for the first time there has got to be a little bit of waterfall at the beginning with the requirements gathering because unless it is a small project there either has to be some form of assessment at the beginning to understand where they are currently at, what environment are you walking into in order to build the requirements or even accept the requirements that they are giving you, it is like hey I want this, well okay what do you have and is what you are asking for really what you need, so you kind of have that give and take at the beginning. The story I am going to kind of discuss here is one Rob came into later in our career where we worked at a place a long time ago, the company had just come out of bankruptcy when I went to work for them and we were not 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 pincer attack of trying to eliminate 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 turnover and we ran into a particular problem where we wanted this particular software built, we were like sure let's throw something up quickly, we did, it was accepted well and we went from agile but we ran into a situation where the business' mind was we can go faster if we just copy and paste this project again and again and again, forgo 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 cram 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 a 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 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 had common front end pieces copied and pasted through all these applications and they wanted to do a site-wide 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 waterfall especially if you're doing agile do those burn downs at the end 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 must haves? What do we need to do? Not the nice to haves, start removing those nice to haves, 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 well defined 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 sprint. Now one other thing I want to bring up in working with a customer that's budget constrained usually we are 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 then it's going to cost you $2,000 yeah and I'm just making numbers up and I have a lot of times though I have walked into projects where I have worked with a customer and said okay 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'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 a 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 means it save you from being billed by me for doing that. 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 really can become challenging because now you're in a situation where they save quote save that money by doing that but if there's gaps if they miss 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 hand hold 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 know 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 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 middleman in there I've even talked about I think back and 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 know sort of push the customer and address them and send requirements on them and ownership and such things to them and I've seen this with you know little side hustle things up to big organizations where the customer has 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 community or 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 they 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 task you're getting the requirements you're getting have a lot of what-ifs have a lot of assumptions a lot of if then but without the 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 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 at developernerd.com you can head out there developernerd.com and we've got a contact us form 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 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 have yourself a great day a great week and we will talk to you next time thank you for listening to building better developers the developer podcast you can subscribe on apple podcast stitcher amazon anywhere that you can find podcasts we are there and remember just a little bit of effort every day ends up adding into great momentum and great success