Show Notes
Transcript
[00:00] Rob: In this episode of Startups for the Rest of Us, Mike and I discuss Seven Steps to Rescuing a Failing Software Project. This is Startups for the Rest of Us: Episode 132.
[00:10] Music
[00:19] Rob: Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product or you’re just thinking about it. I’m Rob.
[00:28] Mike: And I’m Mike.
[00:29] Rob: And we’re here to share our experiences to help you avoid the same mistake we’ve made. What’s the word this week, Mike?
[00:33] Mike: Well, last week I interviewed a bookkeeper and the hope is that I can basically hand off all of my bills and credit cards and you know, my books and everything and just not have to worry about any of it and free up some of my time every month.
[00:46] Rob: That is a very good idea. Are you doing it for your personal accounts or for your business accounts?
[00:50] Mike: Technically for my business but if it works out, then I may very well say, “Hey, can you also do this process as well?” [Laughter]
[00:56] Rob: Yup. So, I’m looking in to this exact thing actually since inDinero hasn’t worked out and I have a pretty complex system and lot of rules need to be put in place and I haven’t been able to find an online source to handle it. I think I’m also going to be hiring someone to handle it. It’s too much work and it’s work that doesn’t move your business forward at all.
[01:12] Mike: Yeah, I just feel like it’s a waste of time.
[01:14] Rob: Yeah, I agree. Is the person you hired or you’re talking to, are they local?
[01:18] Mike: Yeah, she is actually. You know, part of it was a comfortability with that and if I ever move and that’s fine but you know, I explained to her as like, “Look, I really want to get to a position where I can hand things to you and I don’t ever actually have to see you,” because she was concerned, well not concerned but she’s like, “Oh, do you need me to come in to your office? Do you need me to – you know, how many times a week do we need to meet?” I’m like, “No, no, no. I don’t ever actually want to see you.” [Laughter]
[01:40] Rob: Yeah, let’s get this straight, I don’t even have an office, you know. It’s my basement of my house.
[01:44] Mike: Right.
[01:45] Rob: Yeah. No, I feel the same way. I actually have it on my post MicroConf to-do list. I have three things and one of them is hire a bookkeeper. And now, since going to MicroConf, I’ve added a couple of comments to that Trello – that Trello item of hire a bookkeeper. I’ve heard that Xero , X-E-R-O, could potentially work for me and then someone mentioned that I should try LessAccounting as well. I had tried both of them about two and a half, three years ago and they didn’t work given my complexity of all the PayPal and bank accounts and merchant accounts, all that stuff that run through my company, the Numa Group but now that I’m out looking again, I’ll probably sign up for both of those guys and then also look in to getting a bookkeeper and figure out which of the three approaches is going to work best for me.
[02:26] Mike: I talked to several people at MicroConf who were using Outright as well which we use —
[02:30] Rob: Yup.
[02:30] Mike: …internally.
[02:31] Rob: Absolutely, yeah. I use Outright – we have two Outright accounts. One is for Micropreneur stuff and then DotNetInvoice has its own Outright account but the rest of my stuff is more complicated than Outright can easily handle it. It’s a pretty simple system which is great but it just can only support so much. And please, please don’t post a comment and tell me to do QuickBooks Online or QuickBooks of any kind. If I need to use QuickBooks if that really is the solution, then I’m definitely hiring a bookkeeper because I don’t want to touch it, you know. I want them to handle all of the – any interactions with QuickBooks is going to be handled by someone else.
[03:02] Mike: Yeah, this bookkeeper that I’m working with she primarily uses QuickBooks which I’m not terribly pleased about it but at the same time if I’m not dealing with it, then I don’t necessarily care a whole lot. So —
[03:11] Rob: That’s right.
[03:12] Mike: …you know, we’ll see how it works out and she actually has a relationship with QuickBooks consultant. So, anytime she has a question, she just goes talk to them and it’s a friend of hers and just gets it all straightened out. So, there, you know, she might even be doing my payroll. I may be switching over from Paychecks to have her do that as well.
[03:27] Rob: Yeah, that’d be nice for sure. So, hey, last month I had a projection of what HitTail was going to do. I actually mentioned it in my MicroConf talk. And it actually grew by more than expected like quite a bit more and I realized that at the end of every month like as the end of the month approaches, you know, you have projections in your dashboard that you’re looking out. I’ve just found it so difficult to be accurate with those projections even with four days left in a month. I mean I can be off by 20%, 30% of growth, not the 20% of revenue in the total month because I know where my base is but just the percentage of the growth or loss that month, I just have not found a good way that I feel confident that I can say yes within, you know, hundred dollars. That’s going to be the number.
[04:09] And the funny thing is I thought it was just me and that the data the way it sorted in HitTail but I’ve talked to several other people who own SaaS apps and software companies and it feels like this is a recurring problem. Everyone I know has it. I have an analysis apps and I have DigMyData and I have a bunch of apps that I can run reports on the stuff but there really isn’t a great solution for it. I just — I thought it was funny to – I ran the numbers in. I’m always a little bit surprise and you just think at this point I would have just dialed in.
[04:35] Mike: is that because of the way that the months fall? So like, you know, some have 30 days —
[04:40] Rob: Yup.
[04:40] Mike: …some have 31. Is that —
[04:41] Rob: Sometimes it is, you know, other times you’ll just get a chunk of cancelations for some reason just a little blip and it’s just enough that it kind of sense you – the growth is just a little smaller than you think. The reason I got the bigger bump, I don’t know. I had some boost – I don’t know if it’s going to improve conversion rates or if I just had a lot of trials in the funnel that I – just for the last couple of days of the month that I really hadn’t encountered on and suddenly convert it. It was something at that effect. And so, there’s always these small anomalies and again, it’s not like, “Oh, I can’t run my business because of this,” but I guess if you’re out there and you’re running a SaaS app and you’re on the same boat, don’t feel bad because everybody I talked to always has that thing of like how – where really am I going to be at the end of this month?
[05:16] Mike: I had a discussion this past week with my AuditShark developer to finalize the list of things that needs to get done before we can really start pushing on it. It’s really small at this point. I mean the only two things that are left I would say are e-mail reports and billing. And billing obviously doesn’t necessarily need to be completely in place but beyond that those things are both things that he’s taking care of and then just expanding the Policy File library. But other than that, I mean everything looks like it’s good to go. So, next week I’m going to be sitting down. I have the week off or I took the week off and I’m going to be sitting down and figuring out exactly who else I’m going to be putting in to my beta program and try to figure out exactly why I want to go live for the full public launch.
[05:54] Rob: Very good but at this point, do you think you’re within weeks?
[05:57] Mike: Yeah, it is definitely weeks [Laughter] and definitely not months unless something —
[06:00] Rob: Right.
[06:00] Mike: …major comes up that I didn’t see or wasn’t able to test, I don’t see an issue with getting out there, you know, within next several weeks.
[06:07] Rob: Right, very cool. Yeah, I would encourage you to launch without billing in place. And obviously as you’re collecting a credit card or maybe even you don’t need to collect a credit card if you’re not going to collect it upfront but —
[06:17] Mike: No, I’m going to. I want to because it’s until now I haven’t billed anybody for it yet so next week I want to get to the point where things are in place enough so that I could start billing people and I intend to. There’s a few minor pieces I need in place just to be able to put the credit card numbers in but the final billing code is probably not going to be ready when I, you know, go through that process. I’ll have my developer work on that while I’m going through with them.
[06:40] Rob: Right, definitely. Yeah, that’s a nice part about having a developer that – you know, there’s a couple of ways to do it right. If you’re writing all the code, then nothing gets done unless you’re doing it. But there’s also the hybrid where you’re writing some of it and they’re writing some of it and it’s nice because you can keep your hands in it and writing code is so much fun, right? But I find that that still weighs on me that I would still assign a lot of it, task that have to get done to me and if I wanted to get them done quick and then I just work until 1 or 2 in the morning just try to get a bunch done.
[07:09] Being able to outsource everything essentially to have someone else doing it, I find there’s like a certain level of – it’s actually it relieves – I don’t have the stress that I should be doing something right now because there are critical path is held up by how fast the code can get written but I’m not writing any code on this project. I’m talking about Drip now. And you know, I know you’ve written code on AuditShark. Are you – are there tasks here that you could feasibly get done faster if you pulled some of them back to you or is that it? Are you kind of done right now with writing a code and it’s all outsourced to your dev?
[07:40] Mike: They’re definitely things that I could pull back and work on myself that would get done quicker because he’s only working on it two days a week at this point. There’s things that could definitely get done quicker if I’m working on them because I could obviously work on them seven days a week but at the same time there are so many different things that need my attention. It’s just not worth the time and effort. If I start focusing on the code [0:08:00] at this point, I’m going to start dropping some of the other things and all the other things are sales, marketing or customer development related. So, those are the things that really need to get done.
[08:09] And then the policy library is kind of a big chunk that I have not sunk my teeth in to yet. I’ve really got to figure out how to get that built out as quickly as possible and put a process in place for somebody to kind of walk through and start implementing those things. And that’s a key component right now that I just don’t have a good handle on. So, I’ll be putting some time and effort in to that next week just because it needs to get done and it needs to be something that expands overtime. I can’t just do a bunch of work there and then just walk away. There’s other things that need to be built on an ongoing basis.
[08:38] Rob: Yeah and that makes sense, that’s actually what I’m saying is like not getting dragged back in to the code right now when all the marketing and sales and this other stuff needs to get done. There’s a certain amount of serenity to it. That’s what I was saying is that having someone that I can hand off the code do and say, get it done as fast as possible but not feeling the compulsion to go on and do it myself is better for the product in the long term. I mean that actually leads it right in to what’s going on with Drip.
[09:02] As we record this podcast, we’re in an hour or two of having all the features complete to install it on customer number one. And I expected this to come late last week but MicroConf just kind of trashed everything. And then when Derek and I met, he’s the Product Manager for, well, for HitTail and the developer on Drip, we went through some more features that we wanted to get in before we got customer one on. So, my hope is that by the next time we record, it’s realistically should be by tomorrow, our customer one, who I have already talked to should be installing it. I’m sure we’ll run in to a whole slew of other things small features here and there that we need to add and tweak to get it ready for customer number two.
[09:42] What’s cool is in FogBugz, I have milestones for each of the customers that I’m going to get on. There’s this milestone of – it’s called customer number one and it has all the issues that I need to fix and that I think that he needs. I’ve already e-mailed him and asked him exactly what he’s going to do with it and so, we had to add some things last minute to get it in. But it makes it really easy. It feels like it’s slow going but it makes it easy to know that when he gets in there, it should have everything he needs to basically do what he’s doing today with his software.
[10:11] Mike: That’s really interesting idea. I hadn’t thought about creating milestones for each individual customer where they look at that and they say, “Oh, well, this isn’t working for me,” or “I need something over here instead.” That’s a really good idea. I think I’ll steal that. [Laughter]
[10:23] Rob: And we are – I mean it’s not that we’re giving them access to it, it’s not that we’re letting them know, “Oh, here’s all the issues we’re fixing,” or “Here’s all the things we’re adding.” It makes it easy to not be like, “I’m launching to 500 people.” We’re really launching this week to one person. It’s one guy who owns a SaaS app. I was able to interview him and say exactly how you’re going to use this and he kind of said – gave me some ideas. I asked more questions and then I realized and you know, talked to Derek and said, “All right, our app doesn’t do these four things right now. We need to build this in order for us to support him.”
[10:52] And knowing that his needs are common is helpful, right? It’s not that he sends us off on a rabbit trail to do some random feature. The features that he needs, everyone is going to need. It’s just about prioritizing them. We have a list of say 50 features right now and I just picked the next four that we need to get him on the system because once we have him on the system, we’ll just start learning so much faster.
[11:12] Mike: Cool. Yeah, I had a similar discussion with Jason Roberts from the TechZing podcast at MicroConf last week and I was talking to him about his secret project. And told him I was like, “You know, these are the things that I would need and these are the thing that I would use in that. And these are the pieces that are important to me.” He’s like, “Oh, well, I haven’t really thought about that, you know, and that wouldn’t be too hard to add in.” But it just kind of highlighted some of the things that are fairly common used scenarios that, you know, just hadn’t really occurred to him.
[11:39] Rob: Yeah and that’s always the way it is. We never quite realize how people are going to use our apps. So, until someone is actually using it and I would – I dare I say paying for it although if they’re very serious about it even if they haven’t paid you a dime, if it’s the right people who really know, you know, who built apps themselves, they can often get you feedback even without giving you money. But I think the ideal case is that until you have someone using it and paying you for it, you just don’t know how folks are going to be utilizing it.
[12:08] Mike: So, one of our listeners his name is Masaj from Fired Up Digital. He started listening around episode 22 and he’s since left his job. He dropped us a few more productivity tips related to episode 125. The two tips that he sent in to us was the first one was to split the day. Do e-mail and stuff like that in the morning and then work in the afternoon in a coffee shop so that you’re not doing the same thing all day long in one location. And then second thing he said was that, you know, he exercises regularly to get some of the endorphins going and just recently had done a marathon. But both of those I think are really good tips to fit in with episode 125.
[12:44] Music
[12:47] Mike: So today, we’re talking about Seven Steps to Rescuing a Failing Software Project. And this idea is really about if you have a project that you’re working on whether it’s in-house development or you’re working on a product itself that you’re going to be launching out to the world and things are starting to go wrong, you know, whether the code isn’t getting done fast enough, there’s people who aren’t responding when you ask them for things. And you know, you’re trying to manage the project but at the same time there’s just lots of stuff going on that, you know, you’re not quite sure how to handle or those things are going off the rails a little bit. You need to be able to get things back on track. So, this episode is really about stepping in kind of assessing the situation and then rescuing that project put it back on track.
[13:32] Rob: And this applies both to being a – for being a pre-launched product as well as maybe you’re going from version 2.0 to version to 2.4 and you have a bunch of tasks that you’re trying to do. Maybe you’re working with developers and like you said, things aren’t working out.
[13:48] Mike: So, step one is to don’t assign blame. If you start assigning blame to people, they’re going to, you know, at least be a little bit resentful. Some things are beyond their control. Maybe they’re – you haven’t given them enough direction. Maybe they’re waiting for other people. The point here is that by assigning blame, you’re essentially pointing fingers and they’re going to resent that. What you really need to do is you need to step back. You need to figure out what’s going on and address the underlying reasons why things are starting to go wrong.
[14:14] Now, that doesn’t mean that, you know, if somebody is willfully ignoring you or they’re just not doing what you’re telling them to do, you know, obviously, you need to address that. But in a general sense, you don’t want to kind of bring everybody together as a group and say, “Hey, look. Joe over there, you’re not doing your stuff. This stuff is got to get done, you know, all these other people are counting on you but you’re just, you know, you’re not coming through a force. We need you to, you know, get on things.”
[14:37] The other thing that goes along with this is not doing it publicly either. I mean if you do need to provide some critical feedback to people because they are in that type of situation, definitely do it privately. You don’t want to make a big deal out of it in front of everybody because that will push them away instead of bring them in to the fold.
[14:53] Rob: The best example I’ve seen of this of a manager who handled this kind of stuff really well where mistakes were made and he wanted the entire team to learn about something. So, if you think about it like mistakes are opportunities for learning, right? A mistake would be made, he would correct that person privately just like you said and then he bring the team together and he would try to anonymize it, right and say like, “Hey, guys. This just happened…” And in any way he could – if he couldn’t anonymize it, he would just say, “This just happened. Here’s what we’re going to do to correct it. Here’s why we don’t do that, you know. Here’s the remedy for it so that we all don’t make it in the future.”
[15:27] And if he couldn’t anonymize it, he would say exactly what you just said. He’ll say, “Look, John here did this. He and I just talked about this. It was a mistake but the reason I’m bringing this up is not to shame him, it’s that all of us need to learn from this like this is a learning experience.” He would actually use it as kind of a teaching moment so everybody was feeling okay about it. And then, you know, as the project went on like it wasn’t a guilty thing where you felt like a mistake was this bad thing, right? It wasn’t – rather than assigning blame, it was used as kind of a learning thing to help improve everyone helped improve the team dynamics and just help move the project forward.
[16:02] Mike: Step number two is to look at the numbers. Is it time to pull the plug and you need to be able to make an honest assessment as to whether or not the project can be salvaged. If there are definite milestones that you need to reach, if it’s an outsource project to you or your customers are coming in saying, “Hey, we need this by this particular date,” look at those numbers, any timelines that you have or try and figure out honestly where exactly things stand. I mean you have to be realistic about everything because if you can’t, then it makes it very difficult to plan for the future. You need to be able to be honest with yourself, be honest with your team and ask people, “You know, do you think this project can be saved?”
[16:39] And by asking everybody, you get different people’s feedback on that and it’s really important to not just depend on your own optimism or pessimism is the case maybe. Ask everybody on your team and let them know, “This is where things stand. Do you think this project can be saved under these parameters?”
[16:56] Rob: This is such a hard question to answer because it is such a case by case basis thing. A lot of it depends on trusting your own gut and looking at a project and really asking some tough questions. Shutting a project down is – it always feels so painful right because you’ve invested time, money, resources, everything in to a project whether it’s month’s old or even if it’s just a few weeks old but at the same time, there’s that that expression sending good money after bad.
[17:23] I’ve actually a little bit dealing with this right now on a project dealing with HitTail. It’s not a development project but I hired a contractor to help out with something. We’re about three months in to it and it’s not moving as fast as I would want it but the contractors had been really good about communicating with me and really good about pointing out, you know, road blocks and bumps along the way. So, there’s that thing of like if they just don’t communicate, then yes, it’s obvious it’s not going to work out. But he’s always one step away from delivering something.
[17:50] So, I’m in a place of like I’d ask myself this morning I was in a call with him and I said, “You know, is it time to pull the plug on this? Can it be salvaged?” And so, I brought that up to him and I said, “Hey, here’s how I’m feeling. I’m feeling right now like we’re three months in to this and I’m not sure that you’re going to be able to deliver on this and here’s what I need. I need to feel confident that the next thing you do, you’ll hit the deadline and you’re going to deliver it at the level that I need.”
[18:15] And that actually turned out to be a really good conversation and I appreciated he – he was very professional about it and now we have a hard deadline with like an exact milestone that happens in a couple of weeks. And we both agreed, you know, if it doesn’t work out at that point, we are just going to walk away and he’s actually going to refund all the money that I paid him. I don’t know. It’s just a worth while thing.
[18:34] So, that’s I found especially lately it’s like if a contractor is either unprofessional or unreliable or an employee for that matter, then that tends to be, you know a better reason to pull that plug. But if they’re willing to work with you and like commit to things and get them done and actually do start delivering, then a lot of things can be salvaged even when maybe you think they can’t.
[18:56] Mike: The third step is to stop looking at the software you’re building. A lot of times if a software development project starts to go off the rails a little bit, people will look at the software and say, “Well, why are these things not getting done? You know, what is it in a software that’s so complicated?” And they start digging in and they tend to go down the rabbit hole. The problem is the software is probably not to blame. It’s the management over the project. It is the deadlines that you’re putting in place and the time estimates that you’re putting in to those.
[19:23] I mean if those things are being created in such a way that is unrealistic to even be able to come up with those time estimates, then that’s the issue that needs to be addressed. It’s not building the software that’s the problem, it’s the time estimates that you’re associating with it. You really need to assess where things are going wrong and deal with those issues rather than just assuming that the problem is in writing of the code.
[19:45] Rob: Moving from developer to project manager is hard. You know, a lot of developers don’t estimate how long it’s going to take them to do something and they want to move ahead with the fun stuff which is coding, the building and the creating. And I totally get that. That’s how I am built by nature. And so, if a project is going off the rails, the first place I look at obviously is the project manager because here she’s the one responsible but more importantly I start looking at like well, where are your estimates and how close or how far off have you been from those? And figuring out either that you are a bad estimator or that, you know, that you missed pieces of the estimate.
[20:25] Somehow taking away like realize this is probably a mistake on your part and learning from that so that you don’t do it next time is extremely valuable as opposed to just ignoring it or like you said, you know, blaming it on the software, blaming – it was too technically hard or I didn’t do estimates because I’d just wanted to have fun building it. It’s like none of that is helpful. If you actually do want to get better and improve at this whole project management thing or just even at building software products, you have to sit there and examine the process and figure out where you went wrong and improve yourself.
[20:57] Mike: Yeah, that’s something that I have to personally take a little bit stronger look at just because we haven’t really put a lot of time estimates in to AuditShark. I mean there are certain places where there are but there’s a lot of places, a lot of things in FogBugz where there are not time estimates which makes it hard to do scheduling and trying to figure out where different dates are going to fall. So, that’s definitely something I need to get better at on my end. But I think that that’s a common problem too.
[21:20] Rob: I sometimes feel like a broken record because everytime I talk to one of my developers and we talk about doing in a feature, the first thing I say is, “All right, I need an estimate on that. And you have to give it to me right now. You have to think about it for five minutes and send me an e-mail. Put it directly in FogBugz or the Google doc we have set up but I need before you write a line of code, I need an estimate so that we have some idea of how long this is going to take.”
[21:43] And the thing is if you get 20 or 30 small little features, you know, all in your issue tracking system, it’s impossible to know. It’s impossible to estimate how long that’s going to take especially when someone is not working fulltime. That’s where it gets weird, right, if they’re working 16 or 20 hours in a week, then things get kind of hairy. I think all of us learned if you’ve been developing, you know, writing code for 20 years, you think in terms of a person weeks.
[22:09] And so if they’re only working 15, 20 hours a week, I find it really hard to just look at a swath of and things oh, this is going to take them X amount of weeks because you’re – you don’t have in mind that they’re only working, you know, part-time. And so, having those actual hour estimates even they’re off by a 10 or 20%, it really makes it a lot clearer as to when potentially you could deliver the thing.
[22:30] Mike: So, step four is to cut twice and then cut again. And this is really in reference to feature creep because feature creep is real. It bugs on a project. There’s always new things to be implemented. There’s always new features that are coming in whether they’re from customers or from project management which is tends to be you but you have to be able to make the project manageable and make the milestones manageable by cutting things out that are just unnecessary.
[22:54] Rob: This is where I’d become a pretty big believer in this whole early access model when we’re – as we’ve been building Drip, I have been looking at just the minimum feature set we needed to get it installed on HitTail. And whenever we had a question or decision to make about should we implement that, I asked Derek and I said, “Do we need that to install on HitTail?” And then we’d say yes or no and that will go in to the HitTail milestone, the customer zero milestone we had. And as soon as we got it on HitTail, yay, big celebration and even that took way longer than we wanted to rather than we thought which it always does.
[23:27] Then we said, “Okay. What are we going to do next?” And that’s when I interviewed customer one, looked at exactly what he needed that we didn’t have and everything since then that we’ve discovered, you know, the other five to ten things we found on our own, we’ve asked the question, does he need this to launch because if he doesn’t, then don’t put it in this milestone yet. Put it in customer two or even way down the line we have a public launch milestone in FogBugz. And so, that’s the one that we need before everybody gets in.
[23:54] So, that’s things like setting a settings page and updating your password and all the billing stuff and I mean there’s a lot of stuff that’s not in place at this point. It is absolutely, you know, about as much of an MVP as we could do and feel reasonable about. No matter how much you do that, it’s still going to take longer than you think. You can only cut so far and being able to focus on a handful of customers upfront and just building for them makes it much easier to prioritize than if you’re just picking things out of the air and trying to decide yes or no or should be build this because the answer is always yes, we should build this but the question is when should we build it? How soon should we build it? Can we push this off one more milestone down the line? Can we push it off the public launch? Or maybe to one point one which is after public launch when you have that revenue coming in and you have the motivation and the excitement of having customers paying you that the pay off of all that because that will be the time where you can really hunker down and potentially hire more developers if you have more revenue, pushing things off pass that is really a benefit to a bootstrapped product.
[24:59] Mike: Step five is to be honest about your project risks. Anytime there’s a dependency on something when things go wrong, it’s going to push everything back. And this is one of the fundamental problems with the waterfall method that Agile and Scrum tried to solve. But if you’re not honest about the project risks and the project risk can be any sort of dependencies that you have whether they’re on software or people or availability of resources, new hardware coming out, new software releases.
[25:25] So, if you’re – I mean you’re waiting for the next version of Windows or the next kernel Linux to become available. Those things are probably beyond your control. You don’t have any say in when those things actually occur and although you may get commitments from people, they’re not necessarily setting stone and they can decide, “Oh, well, we’re going to push this back because of XY and Z,” and they may very well be legitimate reasons. But because they’re outside of your control, you have to take that as a risk and taking in to account what you’re going to do if those things don’t come through.
[25:53] Rob: Yeah, an element of a project having risk or not really it isn’t a binary thing, right? It’s not a yes or no. It’s more of a gradient but in my project plans, I always just have a yes or no because most things you’re doing as you’re writing code have very little risk because if you’re inserting data in to a database, validating it, pulling it out and displaying it like these are virtually zero risk. But the – anytime you’re integrating with an external API or you’re doing any type of algorithm that needs to do kind of some magic that you’re going to have to play around with or any type of external dealing with, you know, third-parties that you have to rely on in some form of fashion. Those things are all in my opinion the risk is just through the roof.
[26:37] There’s a big risk of running over your estimate more than anything. There’s always a risk that you’re never going to get it done, you know, it’s just not going to work or not going to do the thing but that’s lower risk within. You’re just going to be 50 or a hundred percent over your estimate. So, when I have project plans, I – if it’s in a Google doc, I’ll put a big like risk column and then say, “Yes. This part right here, I’m really sketchy about. I just don’t know if we’re going to be able to deliver this. I want to build that first,” like I want to eliminate the risk as soon as possible in a project and that tends to be the opposite of the natural inclination which is to push all the risky stuff off to the end and do the easy stuff first.
[27:12] So, you’re attacking a project and you don’t want it to get to the point where it’s becoming a failing project, try to stack up the hard things first, the tricky things first and build them before everything else because we know that you can write billing code and we know that you build the settings pages where people can reset their password, that’s the trivial part. It’s doing a hard stuff first that’s, you know, going to hopefully ensure the success of your project.
[27:34] Mike: I think the biggest thing I ran in to in those types of things is kind of what you alluded to. It’s like third-party libraries and third-party integrations, any external APIs because you can always run in to a bug in those or you know, if it’s an open source project you may have to resort to reading the source code to figure out exactly how it works and be able to do what it is that you need to do.
[27:54] Step six is to intervene when necessary. There are times when you’re going to have to make hard decisions or accept some technical debt now to get a project out the door. You may also need to overrule the opinions of some of your developers, some of the – more extreme cases, you may need to cut people out of the project or bring in news ones but the fact of the matter is that this is your business and you’re the one who asked to make those hard decisions nobody else can make them for you. And you do have to take in to account all the previous things that, you know, we’ve talked about so far in this podcast episode. You have to be willing to intervene when it’s absolutely necessary and make those decisions.
[28:29] Rob: And this counts both for when you’ve hired a developer or when you’re writing the code yourself and that’s the hard part that I think most people don’t think about is that just because you’re the project manager and the developer doesn’t mean you shouldn’t have some type of mental separation between those hats because making the call to not implement something that the developers had really wants to implement because it’s either going to be fun or you know it’s easier, you know you can do it and “just a few hours” if it’s not going to get you closer to launch and closer to having people getting value out of your app and paying you money, then that’s the time to step in and say, “We need to push this off.”
[29:04] Mike: And the seventh and final step is to fix your processes and procedures. You need to document things, figure out how things went wrong and figure out how to do them better in the future. You want to be able to avoid repeated problems from one project to the next and use each project as a learning experience to be able to take those experiences and those good lessons that you’ve learned and apply them to the next project so that things will run smoother the next time around. This applies whether or not you’ve got a single product and you’re just trying to get multiple releases out the door or you’re trying to build multiple products and sell each of them independently and build a small company that, you know, manages multiple products.
[29:41] Rob: You know, I hate processes and I despise procedures but sometimes they’re required so that you don’t make the same mistakes over and over. When I really like processes and procedures is when they make my life easier in the future when they allow me to essentially hand something off to someone else so that it can be done right over and over and over and thereby leveraging someone else’s time instead of mine and when it saves me from losing time or money or just making a big mistake in the future.
[30:10] You know, it’s kind of the entrepreneurial goal with your gut as to how much you need but for sure if you’re a one-person shop, you don’t need very many. But as you grow, even if you only grow with part-time contractors or you know, getting in to some fulltime contractors, you need to start ramping it up just a little bit, just enough so that you can hands stuff off with confidence and not be bogged down by handling all of the processes and then so you can learn from your mistakes and be, you know, more successful in the future and more efficient moving forward.
[30:39] Mike: And don’t forget that that includes documenting things as well because just because you wrote the code for something doesn’t mean that somebody else’s is going to be able to understand it or it’s going to know intuitively exactly how to use it. So, make sure that you put together documentation and not just about your code but around, you know, for example your build process if you have a complicated build setup, make sure you document that so that even if you’re rebuilding your machine and going from one machine to the next, you know how that is supposed to work and you can hand that off to a developer.
[31:08] The same thing that goes with some of your marketing collateral or anything else but I mean we’ve kind of talked about a lot of these things in the past in terms of documenting all the different procedures that you use in your business that you can outsource them and that’s part of what this entails as well.
[31:21] Rob: So, to recap our seven steps Seven Steps to Rescuing a Failing Software Project are don’t assign blame. Number two, look at the numbers. Number three, stop looking at the software you’re building. Number four, cut twice and then cut again. Number five, be honest about your project risks. Number six, intervene when necessary and number seven, fix your processes and procedures.
[31:42] Music
[31:45] Mike: If you have a question for us, you can call it to our voicemail number at 1-888-801-9690. Or e-mail us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt used under Creative Commons. You can subscribe to us on iTunes by searching for startups or via RSS at startupsfortherestofus.com where you’ll also find a full transcript of each episode. Thanks for listening. We’ll see you next time.
