Runaway Project

Welcome to Building Better Developers, the developer podcast where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season where we're looking at mistakes, errors, missteps and things like how they either led to success or lessons learned that made them valuable for us to usually in this case for me to have made and then learn from it advanced somewhere down the road. This episode, two things. One is more of a, oh, we'll say an administrative kind of thing. I'm doing stuff a little different this time. I'm going to record it a little differently so we will see how this goes. Hopefully it's good. I'm going to work with a little bit of the recording stuff this season, trying to find some adjustments here and there. This time I'm trying to avoid being curled over a mic as I talk and actually sitting back and carrying the mic around with me a little bit. So it's a little different. Hopefully it will be as clear and awesome as always or if not awesome, but at least audible. This episode though, we're going to focus on, I guess we'll call it like a runaway project in a sense. And it's probably easier to just dive into this story. What happened is we had a situation where there was a project that was going on and there was a, this is one where I was a contractor. There's a person working with me that was a contractor. I think even the person running the project was a contractor. And the person running the project had multiple responsibilities. So he was not full-time focused on project management or anything of that nature. What ended up happening is there was a back and forth between the contractor that worked for me and the project manager type person that as work was turned in, there was essentially this like constantly this pushback that said, you know, hey, you should, you know, you should test this more and I want to see more testing. And so those requests kept coming in. And then the guy that worked for me, it's like, okay, we're going to, you know, we're going to slow this down a little bit. We're going to spend our time to cross all our T's, dot all our I's, make sure that the code is, you know, as, as close to perfect as you can get, we're going to have some tests include, you know, basically some regression testing and stuff like that's included with it. And I think there's even some documentation. There's kinds of things that while important sometimes can add a lot to the cost, particularly when you're doing like minor code changes and stuff like that, or minor, maybe a strong word, but where you're really just adding like a little feature here, a little feature there, a little function here, a little function there into an application, which was the bulk of this work. Well, this goes on for probably about six weeks, something like that. I mean, it was, it was over a month and I don't think we got to two months. And what happened is that the contractor was turning in hours that was, you know, billing I don't remember, you know, just roughly like, let's say it went from 10 hours a week to 20 hours a week, you know, effectively doubling and maybe even gone higher than that. So maybe even over doubling what the cost, you know, per, per month, per week, however you want to look at it of that contractor was. And the, the owner, the person that paid the checks, the guy that was, you know, flitting the bills, looked at that and picked up the phone and gave me a call and said, Hey, we've got somebody that's billing outrageous amount of hours. And I looked at it and I was like, I'll hear it. And I'd known a little bit about the conversations that were going on. So I said, well, you know, this is what's going on. He was asked to do all this stuff. So he would, he put the extra time in to do this. And the, the guy writing the checks was basically like, I can't do this. You know, this is not, this is not what I'm looking for. I need somebody cheaper. Long story short, ended up like working something out so that we didn't, you know, didn't bill them for some amount of those hours. I remember how much it was. It was, I mean, a large portion of those hours did not get billed. And what the conversation was that I had with, with the guy that worked for me was, you know, we sat down, we, we sort of did a, did a retrospective on it. And one of the things that we were not doing, at least he was not doing, was sending in a weekly status. Yeah, there would be sort of catch is catch can statuses that would go out maybe in an email or things like that. But it really wasn't a status type of communication. And by that, I mean something where like in my case, typically, you know, weekly and partially because of this, it will be a, you know, an email or a document that basically says, here's how many hours billable hours that were worked this week. Some cases, you know, so many billable hours, this is how many additional hours of work went in just to let them know that, you know, hey, you know, you're getting extra work and any issues that rose and then plan for the next week. So it may be that, you know, hey, I worked 10 billable hours this week. I plan on billing 10 hours next week. And while that may seem very minor and in some cases, customers pretty much ignore that. And they'll look at it like once a month or something like that. But you know that they're really not paying much attention to it. But the thing that does is that gives you one a little bit of, you know, CYA if something goes wrong like this, but also something that if those things start to change and particularly if it's in an email, not like a document that you attach, but you have something, thing, easy to see that says something like, hey, I work 10 hours next week. I plan on working 20 hours next week that they're going to be able to see those fluctuations and be able to step in before you do it, which would have saved everybody because what would have happened, presumably it, well, I guess there's two ways it could have gone. Either the guy writing the checks would have seen that and said, hey, that's not what we're looking for. Let's adjust. This is the amount of hours I'm looking for you to put in. And so then there would be the discussion of, OK, well, here's what we can deliver within that time. And all of this extra tests, extra tests section, all that kind of stuff, we're not going to be able to, you know, we're not going to build that or we're not going to be able to do that because it wouldn't, you know, it's us giving you free stuff essentially. Or the guy would say, hey, why is this going on? The answer would be, well, we're doing A, B and C that are extra stuff. And he'd say, OK, that sounds good. I'm going to go ahead and pay it. But it would allow the customer to make that decision up front, which is critical. And also to be notified as early as possible if something goes wrong or is expected to go wrong. And this is something we see even with the blockers and obstacles and things like that, part of the status. Is there be situations where you're cruising right along and then you have a week where something's come up and you've got now a little, you know, little red flag in that status or something that says, hey, I'm bringing in this problem and it's blocking me or costing me extra hours, I know extra time. This is important, I think, even if you are an employee, even if you're not like, you don't have to necessarily be billing these hours. It could be something where you're just saying, I worked out of my 40 hour work week, I spent 20 hours last week, I'm spending 30 hours this week on this project. So that you're the manager or whoever it is can see that and say, oh, your time is being shifted to this project or away from that project. And they can make decisions based on that before the fact as opposed to weeks, sometimes or months later coming back and saying, wait, why did you spend 150 hours on that project? We didn't expect that to be more than 10. And that can cause some problems and confusion. So this little mistake while being costly at the time, cost real money, it was hours that were, development hours that were basically just thrown away. But luckily, the relationship was saved, continued to work for that guy for quite a while and was, had always been, even at that point, pretty good about providing weekly status. And I think it was because early on it was a weekly billing cycle, so it just worked perfect for that. But I continued to do so. And I think the other thing is they switched their billing from the guy that signed the checks to somebody in accounting. So the guy didn't see status as much. He didn't see that weekly billing. He would see it come out at the end of the month. Moving forward, that was lesson learned there. It was like, okay, we're doing weekly statuses. And so I'm going to go ahead and make sure that each week you guys can see what is out there. What is it that we're doing? What is we're planning? If there's any change that is needed. And that is something I've carried forward for ever since. I have templates. I think there's even templates out on the developer site. If you go dig around for like, you know, time sheets or status, there's definitely some included in the, I say definitely. There's probably one included in the project management book on creating software. There's a lot of examples out there. If you just jump out like using Excel or numbers or something like that, I'm pretty sure they have status examples and they're usually not that complicated. It's what did I do? What do I plan on doing? What are my blockers? And you can include, which I do, you know, how many hours did I spend on this thing? What was my breakdown of these different tasks that I worked on? And in some cases, it's like, what is the status of that task? So is it, is it something that I'm working on right now? Did I just start it? Is it needing some sort of review? Is it ready for testing? Is it ready to be deployed? Something like that. Because it also gives you sort of a running, especially because you've got and keep your status every week. You can see sort of a running progression on what did you do? When did you do it? When was available? And for your customers, they can, you know, or whoever that happens to be, whether it's or your boss, you know, the management, you can see what's going on and what has been delivered and sort of when was it delivered? You know, things like that, which can be important when you get in situations where you have something ready, but some somebody else downstream is not ready for it yet. And so you have something that's been ready for weeks, but they can't move forward because somebody else is blocking that. Then you've got that paper trail. And you can also raise those, you know, those concerns early on and say, hey, this is ready to go so that management can push on the right people to get it to be ready to be deployed. So status is simple. It's typically, depending on how complicated you get with it, it's probably not going to be more than five or 10 minutes of time spent. Often ideally, you know, either at the beginning of the week, but usually I do it at the end of the week. And here's what I did this week. Here's what I'm planning on next week so that there's some time, particularly, you know, they can take a look at it sometime over the weekend and then Monday morning and then come in worst case and say, hey, we need you to adjust your your planning. If you get it out a little earlier, if you get it out like on a Friday morning, that's probably almost ideal because then it allows a little bit of time for them to just like they have to schedule a call or if they have to move some stuff around, they can do so Friday so you're ready to hit the ground running on Monday. The bottom line is that if you're communicating, then you're far less likely to surprise your customer and customers do not like surprises. It's a really good like surprise. We got this done in half the time and half the budget, which basically never happens. Almost every surprise. 99.999% of the time, the surprises in software development are something has come up that's costing us time that's costing us money that's moving our dates, that's causing us to miss milestones, that's causing project slip. None of those being good things. So when you put your status in and make sure that you highlight concerns and stuff like that, even I think even if it's not real yet, where it's something where you say, hey, I'm starting to worry about these three tasks getting done on time because I'm seeing this other thing falling behind or there's this thing that is now raised a concern so that you have raised your hand sooner rather than later to say, hey, this is something that we need to be aware of at least and understand that it is a risk and maybe a different risk from what we originally thought it would be. When you communicate that, it makes the whole thing go better. It makes it a lot easier for your customer to and feel like they are in control, even though surprises come up. But then if you know sooner rather than later, then you have more opportunity to make adjustments to absorb that mistake or steer around that mistake or whatever you need to do. When you wait to the last second, it just isn't very helpful. And if you wait till after the fact, then the options are limited. Like this case, this guy signing the check finds out four weeks after this stuff had started. So one, that stuff's all behind. He can't do anything about that. That's time that's been spent. And however he wants it spent, it was spent that way. Two, he doesn't have any options with that as far as saying, hey, let's shift it somewhere else. Maybe I want you to do that. Maybe I want to try this out for a week because it's already passed. And now he's in a situation where it's like, okay, here's a bill. He's in a situation where he just has to decide, I don't think I asked for that. And it's basically now either accept it or don't. As opposed to if it was upfront, it would be you can accept it or not or make some adjustments so that the work is done in a way that makes sense. And you're not trying to reach back in time and try to figure something out. You can't because you can't go backwards. I know it's tricky. Some people may be confused by that, but you can't go back in time and go replay and go get a do over. So the sooner you can get stuff notified and in front of people that are decision makers, the better. That being said, I think it's time to wrap this one up and we're not done yet. There are still errors, mistakes and miss stuff out there. But for now, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor 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. Hi, this is Rob from Building Better Developers, the Develop-a-Noor podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers. And we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.