Why Setting Deadlines Is the Key to Successful Projects

Welcome to Building Better Developers, the Developer Noir Podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are the Building Better Developers Podcast. We are Building Better Developers. We are also Developer Noir. I happen to be Rob Broadhead, one of the founders of Developer Noir, Building Better Developers. This season, we're building better businesses. This episode is going to be, I'm just going to be like upfront. This is not caffeinated. We're on the other side of the day, so this may be a little different. I apologize if this goes off the rails. I am going to give you a little bit of a spoiler alert. We're going to talk about setting deadlines. So this is going to be something that I don't think we've actually touched on too often. We've talked about project plans and stuff like that, but this is like the deadline. It's like this is the finish line and defining that and sticking to it a little bit as well. So a little spoiler alert. That's where we're going to go. First, I want to also mention, because I'm me, I am also the founder of RV Consulting, where we are all about, honestly, we're all about you, whatever your company is. Our approach is we're going to sit down. We're going to talk to you. We're going to understand what your business is. We're going to figure out what is the recipe for success for you. This is not like some recipe you get off of Rachel Ray's 30 minute kind of stuff. This is specific for your business because we have found that each business has its own secret sauce or special sauce. However you want to look at it. There are unique things that draw your customers to you. There are unique things that you do for your customers. Technology happens to be a huge investment for any business. And so what we do is we figure out your business. We talk to you. We understand. We learn. And then we take our experience with technology in the world that's out there and we help you through integration, simplification, automation, innovation, whether it is buying something off the shelf, whether it's building a team, whether it's building custom software. We help you get there so that we can provide you a technology roadmap and plan that is good for today. Six months from now, six years from now, we help you take that technology sprawl that everybody has to deal with and simplify it down into something we can put a nice little pretty bow on and hand over to you so that you can get the best ROI on what is other than your employees, probably your biggest single investment. Good things, bad things. This is actually funny because in the green room before we stepped into the show, Michael and I had a long conversation and it really is the ultimate of good thing, bad thing. This is actually also what's going to be in the newsletter, which I have not finished yet, but it will be out probably by the time this thing comes out. It is a busy season right now. We are blessed and cursed by having way more work and things than we have hours in a day. So the good news is for me in particular, I have got a lot of work. It is meaningful. These are projects that are not just like throwaways and stuff like that. I've got some things that really matter to my customers. I'm very happy about that and I've got a lot of them. The bad thing is that I have probably too many of them and so I am getting up early and staying up late to make these things work. Now I guess as a side note to that, bad news, I am too old to keep doing this stuff. So I am going to adjust. The good news is that I am going to be able to separate myself from some of these projects to downsize myself essentially and be able to stay sane while still providing the kind of quality that my customers honestly they expect but more honestly they deserve and what I strive to give to them. And so this is one of the things that I think it is something that we will probably at some point talk a little bit more about this in one of our episodes is the balance between and we have talked about a little bit like when you grow too much and you need to bring other people on but there are some other factors that are involved there. It is like it has to do more with quality which Michael loves to talk about. So I am going to use that as a segue to toss it over to him and allow him to introduce himself. Michael, introduce yourself to the crowd. Thanks, Vero. Hey everyone. My name is Michael Molloch. I am also one of the co-founders of developer building better developers. I am also the founder of a company called Envision QA where over the years I have spent many, many hours working on different projects either be it in the trenches writing code, working on testing and I have learned that if we build software or come at projects from a tester's point of view, we can build better, more refined software for our customers. So my company's focus is to work with small to mid-sized businesses to help you understand what the technology is that you are struggling with with your business. If you need additional software or if we need to throw that out or build something custom, we help you figure out how to make your software work for you and make your product a better solution for your customer. Good thing, bad thing. Bad thing, I will start with bad thing. Bad thing is I am, it's good and bad, but more bad at the moment. I have so much work to do to meet all the demands on me that I have not been able to spend as much time as I would like living life. And we've talked about this in other podcasts and other episodes and stress and anxiety are a burden when it comes to being overworked or over extended in what you're trying to do. And I'm in that right now. With that being said, the good side of things, it warmed up today. We're kind of in that warm side of spring again, although this morning we were freaking 36 degrees again by midday, we were back in the seventies. I hate Tennessee weather some days. Throw a rock. It can be one season every hour. Who knows? But the good thing is I took a break this afternoon, walked the property. I was worried because we kind of did have a weird winter that we lost a whole lot of trees. We've had a lot of bad weather lately. I just decided, let me just take a walk, walked around. It was sunny, it was warm, it was quiet. Well, sort of the birds were going wild. We have lots of birds, very happy birds. We were down to two guineas from four. It happens on large properties. Long story short, by the end of the walk, I sat down on our dock over a pond. I just sat there for about 10 minutes, just reset. It was such a nice day. I kept thinking to myself, okay, I need to go dig a line, run Wi-Fi out. Of course I go back to work while I'm sitting there. It was a great kind of reset to realize there is a purpose to what I'm doing. It's not all about work. For those of you watching this, remember that there is a light at the end of the tunnel. It's not always a train. We are doing this for a reason. Our lives matter. What we're doing matters. And that's the good to the bad. Okay, Michael is going to go back to work now. I will say that was actually another good thing is that I was testing today. I don't know if you were, I think you were on the call because I was working from my, I was using Zoom on my phone and I was like, I'm going to go sit out in the sun for a little bit and test whether I can use my iPad and my phone to do some basic work. Now I will promote even though we get nothing out of this. If you have one of the, and I don't know how far back this goes, if you have one of the more like the recent generations of iPad, there is a keyboard and protector combo with it that has a glide pad on it. It actually is a full keyboard plus glide pad and it works pretty darn good. As they say around here in the South, I highly recommend it. I think it's, I don't think it's cheap. I can't remember how much I paid because I like got several of these things at once. I was going to say it's like 120 to 200 bucks depending on what you get, but it's actually from a tactile point of view, it is actually a really good keyboard. Not my favorite keyboard I've had for an iPad. The one that I wrote the book on was much more like a tap tap. I like a harder, like a more resistant plastic kind of keyboard. This is a little more rubbery, but it actually is really good. The case in general is awesome. This will be one of those. Email at info at developerneur.com if you want more information on it, I would be glad to share that with you because it's just really cool. I think it is, I think we are literally approaching a point where technology is good enough that we really can go work like out on the dock at our pond and stuff like that. And these are some of the things that we need to do. But right now we need to get back to the topic because I don't want to like, you know, squirrel. What's the topic? What's the topic again? I want to talk about deadlines. And this is, this is an interesting psychological kind of topic in a sense. And I'm going to start it by why I said it's psychological is I'm going to go back to a little story about a person in my past that was habitually late and happened to live in the same house that I did. And so what we did over time is I would sneak in and I would set all of the clocks 30 minutes ahead of schedule because this person happened to be 30 minutes late. Now, the problem is at one point this person figured that out. And so I moved the clocks further ahead. And the next thing you know, people would visit our house and go, why are your clocks an hour and a half ahead of time? What is wrong with my watch? It is like, no, this is on purpose. And I would have to say, and it's probably giving away. She would also say, yes, it's because we wait till the last minute. Sometimes there's a family to get stuff done and to get on the road and to get like, get to wherever we need to be. Now I say this because there is obviously with a deadline, when we set a deadline, there is the, we need to do this by this point factor of the deadline. It could be things like we have to get this done by this date so that the follow-up people that are going to, you know, we have to get this product done by this date so that all of the people that build all the marketing stuff can get it done so that it can ship in time for Christmas or whatever it is, you know, things like that. There are also deadlines like we need to get this done because we need to beat a change in some sort of like government requirement or something like that. It may be something we need to get this done by a certain date, because then that is the time that we've told everybody that we're going to get it done. There's a lot of reasons and they may be very hard reasons or very soft reasons. And then there's also the psychological stuff of we need to set a deadline of Friday because we know that if we set it for Friday, we're not going to be able to get to it till Monday. And Monday is actually our deadline or something like that. We're always, you know, X days late. Or if we don't set this deadline urgently enough, everybody's going to dilly-dally and then we're going to, you know, we're not going to, we're going to wait and everybody's going to study the night before the exam to get it done. Now, some of that actually is built into the agile approach. Very much some of that is the agile manifesto. If you look at some of it and the idea of delivering sooner rather than later, they don't say it, but it really, it does sort of imply it and addresses the whole, I'm going to wait till the night before my project is due to actually get started on my project. And this back when it was done, most projects were 12, 18, 24, 36 month projects. I mean, these were not small. These days, those are practically unheard of, at least when they start. I've been a part of a lot of projects. They're like, we're going to get this done in two months. 24 months later, we're still working on it because people just didn't estimate. So deadlines. I want to talk about, I really do want to talk about more the psychological part of it. I want to go to what is, how do you set a deadline based on, we'll call it the real deadline, because these are some things that honestly, every team is a little different. Every group is a little different. Every personnel is a little different. So for me, there are deadlines I can set for myself because I know who I am. I know what my propensities are and things like that. I know what I'm going to likely do. And so I know I need to get this done because if I don't, then this thing's going to come up and life's going to interfere and all of these other things. And I want to just like give a couple of factors for setting a deadline. Now, one is, this is, this, the first one is probably the hardest is look at the actual deadline. And then it's called a contingency planning and backward scheduling. So if you have to have this done by January 1st, what are the tasks that are required in order for that to be done by January 1st? Now, usually when we're building software and we're providing a service or things like that, we have a, we're not done. When we get done, when something is code complete, there are other things that go on. It may be this thing some people have heard of. It's really rare. It's called testing, but there's also packaging. There's also deployments. There is training. There is user acceptance testing. There are a lot of factors that can go on. If it's a, this may age me a little bit, but, or date me a little bit, but there was a day when people would build products and they would have boxes and manuals and things like that. But even now, if you're going to have a manual, even if it is not physical, but a digital manual, you have to provide time for that to be created, for that to be vetted, tested, validated, and things like that. Not oblivion. Oblivion was like, wow, that was almost 15 years ago, 11, 11, I will never forget that that was when it came out. Right. Or was that Skyrim? Skyrim was 11, 11, 11. For those of you listening, I did show a copy of oblivion. Sorry. So oblivion was actually before that. Wow. Oblivion was like, oh, three or something. That is literally like 20 years old. That is probably an antique that you just showed us that you have the box for that regardless of what a system. Okay. Slight side trip. Okay. Back to deadlines. What you need to do, and this is actually the most important exercise of setting a deadline, of setting your deadline versus the real deadline is to go through the exercise of what is required to happen. Once I get, we'll put in an air quotes for you as a YouTube, you see it, the rest of you, it's air quotes. What is done, what is code complete is usually the more complete, the like accurate term. When I go from code complete, what are the tasks that have to occur to go to this is done, complete, shipped or something like that? Because I have found too often those steps are not taken into account. And what you end up doing, I'm going to give you from a visual point of view is like, if this is your deadline, so if you have it, go check us out on YouTube. This is your deadline. It's your fake deadline. This is your like assumed deadline. What happens is usually you're up here, but this space here is what is needed in order for you to actually get to complete. There are so many things, and this is why testing is tossed aside way too often is because people get to the end of a very complex project that somebody, and I'm going to be like judgmental right now. Some moron said it's going to take us one month to test this 18 months of coding, this million line of code product. They're going to be able to test it in a week. Not going to happen. Only if you have the requirements you need. That's a whole nother road. We're going to go way off script. We're getting a little off. Um, that's a problem. And I think that's the challenge. And that's really my focus in this. If there's nothing else, and this is a little bit of a hint, a spoiler to the challenge is it's not as much about the deadline. It's as much about defining not only the requirements, but actually like fully defining requirements. What are not only the requirements to build the product, but actually to ship the product, to deploy the product, to train the users, to actually get it in production. And now I'm going to let you like mull over that a little bit while I have a little sip of my drink. And Michael provides your thoughts on all this, because I know you're like, you're at the back end of that. You like, you're the, the horse's rear that gets kicked all the time in the testing world. It's like, yeah, take that, you know, you made six weeks of testing scripts. Can you get those done in a week? So that sets the table probably really nice for angry Michael to step up and talk about testing. So yeah. So you said the table really well for kind of defining the approach to setting deadlines. Now, Rob mentioned agile. He also mentioned waterfall. If you watched the pre show, the big thing is when you are building software, there needs to be some idea what it is you're going to build. But at the end of the day, you need to know what are you delivering and somewhere between the beginning and the end, you need to lay out a roadmap of how you're going to build it, how you're going to reach those features from concept to completion. We all run into this. In fact, we're in the middle of a project right now that has kind of gone off the rails multiple times, but we're still moving forward. That is the beauty of agile. However, there are benefits to waterfall too, where you spend a little more time at the beginning, flushing out all the requirements, you get all the requirements to find you flush out all the tickets you need, and then you start working. Okay. From a new project perspective, waterfall, spending a little more time at the beginning to do that may be a better start to the project for defining the deadlines, to defining the requirements, so you know when the deadline is actually achievable. For an existing project, you're already in it. You're in firefighting mode or you're in maintenance mode or a feature mode. So that's a totally different beast. So there you want to go through those cycles. You want to go through those sprints. You want to go through quickly, make changes, keep things moving, keep things forward, keeping features going out. So Rob mentioned testing and that's my wheelhouse or has been my wheelhouse for the last decade, but I'm still in all phases of development, which is where I struggle from a company perspective coming into a new project. I want to build the perspective up front, the test driven development approach. So we need to define or flush out most of the user stories before we write code. There is a difference between user story and requirement. User story defines how the users are going to use the application. At the end of the day, that is what you need to deliver. Now from the user story to the setting deadlines to the deliverable, that is the importance. If you can flush that out, it could be more requirements, but if you can define all the user stories up front, you will be in a much better place to say, okay, we have 150 user stories. We know 80% of these are small features. They're very quick to knock out, but 20% of these could include like a data migration. Data migrations could be easy. They could be hard, or you could be dealing with a 30 year old system, the esoteric, and you are not sure what you're getting into. It could be nice. It could be bad. It could be the seventh layer of hell, which unfortunately is where we find ourselves sometimes. Setting deadlines, and I digress, but setting deadlines is an art that isn't always perfect. You're going to get it right. You're going to get it wrong, and you're going to be so far out in left field that you might look for another career, but bear with it. It is not always perfect. You want to kind of stick with, what is it, permitto? That's the time you think. The word he's looking for is pomodoro. Yeah, but you're thinking the 80-20 rule. Dang, you just made me lose that one. Anyway, stick to the 80-20. Try to deliver 80% of the project. If you start out saying, okay, I'm going to set my deadline, and I want to meet 80%, meaning this is going to give us most of the features, you are setting yourself up for a better delivery. However, as you're doing that, you got to remember you have 20% left. So when you say, okay, we can get this 80% done, say, in six months, you better be tacking on another two to four months after that for that 20%. That 20% could be one month. It could be eight months. The reason I say this is there was a study done years ago with airlines to improve customer satisfaction. All airlines had to do was increase the time of the flight to make sure that if there were any delays or any problems, the flight still made it on time. But 80% of the time, the flight is early. So they have padded the flight times to ensure that customer satisfaction is going to be high because they're always, or in most cases, going to be getting you to your destination before the time you need to be there. Now, there are always the situations where you don't meet that deadline. And if you don't meet that deadline, we've talked about this in the past, as you're going through the project, if you start seeing this going off the rails, make sure you communicate with your customer at every step of the way. Make sure you have weekly conversations, make sure you have daily conversations. If things are on fire, if things are not happy, you did a demo, they're not happy. Make sure you include your customer as much as you can to ensure that, yes, we are addressing this. We are touching this. We are ensuring we are on the right path. So setting deadlines isn't just about ensuring that, hey, when I go into this contract or this proposal, this is when I'm going to get done. Also, you need to make sure that you meet that deadline or that you address any changes to the deadline as they occur through the whole process. What are your thoughts on that, Rob? Rob Bolling, Ph.D. My first thought is Pareto principle, P-A-R-E-T-O is the one you were thinking of, which is funny because it's always Pomodoro, but Pareto is the one that you now forgot. That was the one I was trying to remember. Rob Bolling, Ph.D. Wow, there's actually a lot there. I think the first one I want to touch on, and we've actually touched on this before, not really from a software point of view, but from a consistency point of view, is when you communicate a deadline to your customer, that is the ultimate priority. Michael nailed it. It is a little bit under-promised and over-delivered, but the neat thing, the magic that we have in software development is, and this is sometimes tough, and I'll talk about that, is that we can set our schedule. Usually, a customer is going to say, how long will it take to get X done? Now, this is an interesting one because Michael and I have been through some of these a couple times, is that we will say, he, I, whoever, developer says it will take, let's say, 10 weeks to get this done. Let's say $10 a week, 10 weeks. If you're doing a dollar, we need to talk. The important point is sometimes a customer will say, well, what can I get in eight weeks? Now, sometimes the proper answer is nothing. We cannot do what needs to be done to get you a proper solution in less than the time that we just gave you. Sometimes you're going to need to stick to your guns. Now, the important thing in all of this is that we could also say, instead of 10 weeks, we could say 12 weeks, and we stick to our guns. What we're doing is exactly what the airline did is we're saying it's going to take 12 weeks, but we are going to be different from, I'll have to go back. I have a nice little graphic, infographic that's a few years old, but talks about how many software projects fail. Now, I don't know, honestly, I don't know industry-wide if those have grown or shrunk in the last few years. There's a part of me that thinks that they have failed more often in the last few years, but they are under-reported because there's a lot of no code and things like that that goes on that have very low expectations, and although they still fail to meet those low expectations, they're not considered a failure. I think it is a huge benefit for us to set a deadline that is a publish, a communicated deadline that is actually further out than what we're going to do because that allows us to under-promise and over-deliver, and if there is an industry that needs it, other than maybe lawyers and used car salesmen, we are right up there, and congressmen, politicians, in general. Okay, I could be throwing shade all over the place, but we are living in the shade, so let's not go too crazy with that. Communicate it, and this is actually a critical thing because I think we tend to be too afraid, anxious, scared, pick your word, of saying that, hey, we need to move the deadline. So if you get far enough into a project and you realize that the project's deadline that you communicated early on, whatever you did, is not going to be correct, sooner rather than later, say, hey, I missed it, this is what up, this is the change, is it occurred, whatever it is, because you don't want to just say, well, we're going to move it back five weeks, suck it up. It doesn't work well with most customers. Say, we're moving it back five weeks, and be honest. So if you miss something, if you're like, hey, we did not include this piece of your application that we realize is critical in our estimates, that will get you a lot further than you guys suck and you didn't tell us enough, or whatever it is. I don't know what your other excuses are, or just it's magic and the markets or whatever. Be honest with your communication and that will take you a lot further. Michael has something to say. Yeah. You got to be careful with that too, because sometimes depending upon your rate, if it's a fixed rate, you have to bite the bullet. You have to eat the cost if you're running late. Now, if you're hourly or if you're week to week, you even have to be careful with that, because if you start going off, if you go longer than expected, they're not going to want to pay. So you may have to make a decision to complete the project. Hopefully you're honest enough that you always want to make sure your customer first, but there are times, bad customers, besides that, we always want to make sure we're providing the best detail, we're the best product to our customer. So if you do screw up, like Rob just mentioned, you may have to eat the cost. So keep that in mind. Sorry, Rob. Go back. No, I think that's actually really important is that sometimes we screw up. It's our mistake. And we talked about this actually in a prior episode. There are points where it's like, okay, I made a mistake. I'm going to eat the cost. But there are also times where you made the mistake. You thought that they were going to build a one-story house and you realized they were actually building a two-story house. That it's like, hey, I'm not going to make money maybe off of this error, but I can't afford to lose money on this error. It's like, look, this is legitimately, I thought we were building a thousand square foot house. We're building a 3000 square foot house. You are getting a higher value. Now we'll talk about that in another episode. We've talked about it. We will talk about it again about like understanding the requirements, but they're going to your best, your best friend, regular constant clear communication. And when you set a deadline, you should be very focused on that deadline. This actually goes back to the most simple ones that we've talked about is like, if you start a blog or a podcast and you say, I'm going to do, let's say you're, you have a podcast and you say, I'm going to produce a podcast every Friday come hell or high water. You need to make sure that you put one out every Friday. Now you can look at us. We have 800 plus episodes and there are maybe single digit number of episodes that did not go out on time. Half of those were because of like systemic errors and things like that. So we're not perfect, but we busted our, our little blue hinds many times to get that out because that's what is expected. And so you need to do the same thing. And so when you set a deadline and this is other than, you know, the one thing I want you to take out of this is what is it that is required to get from when you are done to actually put it into production with your customer. The other thing is making sure that you are realistic in what can you get done so you don't set a deadline that has you working, you know, 20 hour days for weeks and weeks and weeks. And instead you're actually doing something realistic. Now it brings us to the challenge and that is really the quintessential part of this is think about a current project that you're on, that you're working or a service that you're providing. First, let's start with what is done as far as you're concerned. When do you consider your work complete? And then I want you to step into the shoes of your customer and say, what did they consider work complete? Because it may be as simple as you create a product, you drop it in the mail and they receive it in the mail. However, there is something that goes on between like dropping it to mail and they pick it up in the mail. And it may be much more complicated that software delivery, I think we underestimate these days more than we even underestimate testing and not from a amount of time that is in that is needed, but more of a, we think it's like, it's just a snap and it's done and it's not. And this is from somebody who has done package software, shrink trap software, commercial, small and all that kind of stuff is that I know that getting to a product that you can put on your machine and you can run and the customer loves it, but then getting it onto their machine that they can run and they love it, there is a time difference in that and we need to be assured of it. And so the challenge I want to throw out is for you to think of your project, your product, your service. What are the steps literally detailed? What are the steps that are required from when you are complete to when it actually the customer gets to enjoy it and walk through those steps and think about that as you're setting deadlines. I think Michael has something to say, so I'm going to let him throw his little bonus onto this one. Yeah. So I'm not going to wait for the bonus bonus, but for this, if you're struggling to understand the challenge, Google the tree swing use case. And if you're Googling it, then click images and look for the software development image where you see a tree swing. It starts out with, Hey, the customer wants this, but at the end, the customer really wants this. It's a tire swing. Try that. You will, that almost totally explains this whole episode. It really does because we have different aspects, but I think it really is, is like, is we, we tend to simplify. We tended to say, yeah, I can knock that out, especially as coders. I'm just going to own it. And it's, it's, I could say it's just me, but it is literally every developer I've ever met. That is why project managers are told things like when a developer tells you time, double it or triple it. And I, I do it for myself. I triple it and I'm not always, I think sometimes I'm still struggling through it. And I am not new. I am done this for a long time. And so I know developers, just, it is not a science. It is an art, just like crafting emails, send us an email at info at developer.com. Leave us feedback, whether it's wherever you get your podcast, whether it's out on the developer channel on YouTube, whether it is on our forms, we have blogs, we have all kinds of stuff that you can leave feedback out on developer.com out on X we are at developer or out on the developer page out on Facebook for those boomers that are out there that actually use Facebook, like myself, even though I'm not a boomer. There is just, you name it. We are happy to hear from you. And whether it is a challenge you're working through, whether it is feedback or you like, or you just like an episode, we love to hear it because we are here for you. We are here partially for us because we enjoy doing this, but part of the enjoyment is being able to help other developers get better because we, when one developer gets better, we all get better. That's just like one of those little like kumbaya moments is that if, if you're a developer that I follow behind and you've gotten better, that means when I pick up your code six months later, I'm going to say far fewer cuss words when I'm looking through your code and vice versa. That being said, it's time for us to get out there and I don't know, write some code, create some projects, set some deadlines, go out there and have yourself a great day, great week. We will talk to you next time. Thank you for listening to building better developers to develop a newer podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.