This is How Your Project Can Fail

We have done a lot of custom software and we have seen these mistakes done (we’ve even made a couple of them ourselves — oops!) So learn from our experience and avoid these potential failure points in your project.

Full Transcript Below:

Andrew:

I understand exactly what they need. I understand my users perfectly. I’m just going to take all my money and blow it on that.

Cris:

Pitfalls, common failure points, things that hopefully will help them understand ways to not mess up on their project.

Cris:

Where we built something, we’re like, “Man, the world wants this.” And you don’t get it out in front of people in time and suddenly you realize that no one except you actually wanted that.

Andrew:

Yeah. I mean, there’s so many. There’s so many reasons your project can fail.

Cris:

Today we get to sit down and talk about reasons that your project can fail. So there’s a lot of things that play into that, but we want to cover for those people watching today pitfalls, common failure points, things that hopeful will help them understand ways to not mess up on their project.

Andrew:

Got it.

Cris:

So what in your mind are some of the common pitfalls that you’ve seen or even just what are some pitfalls?

Andrew:

Mm-hmm (affirmative). Yeah, I mean, there’s so many. There’s so many reasons your project could fail. I mean, just to rattle off a few of them. Not having a clear success criteria. What does winning look like for your project? If we don’t understand clearly the target that we’re aiming at, chances are we’re not going to hit it. Just being overly optimistic. This is really common one, both on the development firm side. The development firm can be overly optimistic about how long it’s going to take or how little it’s going to cost.

Andrew:

On the client side, you could be overly optimistic with this is all the users you’re going to want or overly optimistic like I understand exactly what they need. I understand my users perfectly. I’m just going to take all my money and blow it on that. And if by chance, which there’s a pretty good chance you didn’t hit the nail on the head the first time, then you’re out of money.

Cris:

Yeah. And we’ve seen that before, even on internal projects that we’ve done or maybe even in a client-based project where if we’re not pressing enough to say, “Hey, let’s make sure we have a good feedback loop with your users.” They may build something or we’ve even done it before where we built something, we’re like, “Man, the world wants this.” And you don’t get it out in front of people in time and suddenly you realize that no one except you actually wanted that. And that’s a problem and it’s costly.

Cris:

What else? What are some other pitfalls and why is it important to keep these in mind as we build it?

Andrew:

Sure, sure. So just not understanding your users so this is why we’ll help people put together user personas. And try to understand what’s valuable to your users. What problem is this application solving for them. At least that way, you’re putting yourself in their shoes. And again, it’s giving you a more accurate target to aim at. Just communication breakdown issues. That’s a really common one. Be it as the project’s going on long or even kind of upfront planning. Yeah, communication’s just so, so important.

Andrew:

Not that you have to have every detail planned out, but at least you have to be on the same page about what it is you’re doing between your stakeholders, between the development firm. Another common one I’ve seen is so our firm will provide a project manager, but you need to have a product owner on your end. That’s the person that understands, again, the requirements, what does success look like? That we’ll really make decisions upon, “Okay, we need this here. We need this to be green.”

Andrew:

Not so much like here’s how it’s going to work technically, but this is what needs to be built. And that’s what the product owner decides is based on my users, this is what it needs to be. So that’s a long way of saying that if we don’t have a product owner, if somebody doesn’t take responsibility on the client side for making those decisions, if they just kind of defer to us to make all the decisions, then surely we’re not going to end up making what their clients want because they’re the ones that should understand what their clients want.

Cris:

Yeah. Well, and I also think a common pitfall and back to communication is it’s important that you’re keeping regular communication throughout the life of the project. Obviously, we’re not having to constantly, constantly check in at every twist and turn, but I think about like a car and you’re driving to a destination. We know where we’re starting. We know where we’re going to get. We know even maybe the route that we’re going to take to get there, but that doesn’t mean I just set my car on cruise control and never hit the brake once or whatever.

Cris:

Occasionally, someone’s going to pull out in front of me and I got to divert or do something. And that happens I think naturally if you’re not careful on a project. You kind of put that cruise control on and you’re like, “No, no, no. I know where we’re going. We don’t really need to talk about this.” And that’s how you get those black box type projects as we call them where clients will disappear for months at a time or the development team disappears for months at a time. And you’re just kind of going on this trajectory and suddenly you pop out on the other side, and there was a lot of hazard along the way that you didn’t look out for and you didn’t miss.

Andrew:

Yeah, because finishing a project on time and on budget doesn’t necessarily mean it was successful, right?

Cris:

Exactly.

Andrew:

Right. So like you said, communication, knowing where we’re going, being on that same page. If we’re going to pivot, great as long as we’re all on the same page about it.

Cris:

Mm-hmm (affirmative). And so, yeah, on time on budget, those are also of common pitfalls too. I think it’s very common for people to think that something will take longer or will be faster. Usually it’s the, “I think this will be faster,” but occasionally, sometimes people will misappropriate funds because they plan that this is going to take longer and then you might miss out on something. So again, planning, communication is so important.

Cris:

And budget wise, things are always going to be more expensive than you think that they’re going to be. It’s just going to happen. Stuff pops up. So those budgeting type questions, conversations are so important. And if you don’t have them, be ready that that’s probably going to end up as a pitfall on your project.

Andrew:

Well, and circling back to the whole optimism thing. I mean, we see that all different angles. I mean, a really common one I’ll see is a client will start using verbiage like, “Oh, well this is really simple. This is really trivial” because they’re kind of looking at the tip of the iceberg and like, “Oh yeah, there’s these three forms here and it’s simple.” But what all is happening behind that? How many different systems is it hitting? How many different processes need to happen and what stars need to align for this to really work?

Andrew:

And again, what kind of pitfalls could happen? So just kind of taking that overly optimistic view of this is going to be really fast. It’s going to be really easy. It’s going to be really cheap. Yeah, everybody likes that to be the outcome, but a lot of times that’s not the outcome. So we constantly challenge optimism both on the client side to get them to reevaluate. And then internally with the developers when they come to us and say, “It’s going to be two hours.” It’s like, okay, that’s best case, but maybe not what’s worst case, but what’s like 90% worst case, you know?

Cris:

Yeah. As a developer, as a project manager, product owner, whatever side you’re on within the project, you want to have hope for the project. And you want to obviously assume that things are going to go well, but you also want to assume that there’s going to be some hiccups along the way. And we always have the mantra of it’s better to undersell and to over-deliver than to obviously oversell and then under-deliver at the end of it.

Cris:

No one gets angry when you say, “Hey, listen, this is going to take three hours” and you do it in two and a half. But if it takes you four, well, there’s a conversation there. Or it goes from hours to days, that’s when it really starts to be a problem. So optimism I think is probably one of the most common pitfalls that I’ve seen over the years. And so, again, we’re not asking you to be pessimistic. We’re just asking you to be realistic. So any other thoughts, common things? We’ve talked budget. We’ve talked being, again, over-optimistic, timelines, just keeping good communication. What are some other things to be aware of on projects so everyone can have the best success?

Andrew:

Yeah. I mean as far as planning, doing the road mapping with us to kind of spend a few weeks there to really get a good goal, get a good target. Again, defining success. Another one that’s really important is doing an MVP. And again, that ties back to, we don’t want to blow all our budget on the first version. And it’s really important to get your user feedback, to get it in their hands, to hear what they like, what they don’t like. And the MVP or the minimum viable product allows you to do that because you’re building the simplest possible version of that product.

Cris:

Yeah. I enjoy playing soccer and whenever I coach, I always explain to people and this relates to MVP. You don’t need to do in two or three touches or passes what you can do in one. So it’s always about with an MVP is what do you need to get done with the project in order to keep your investors happy, ensure that you’re hitting your goals and milestones, and it’s actually helping the company in the manner that needs to be helped? How are your users going to be affected by this? Are they getting what they’re looking for? And how can you do that, in again, the minimum viable way, MVP, minimum viable product in order to achieve your goal?

Cris:

Because why, again, do something in five, six steps that you can do in two? So it is so important and so crucial. It will save you time. It will save you money. And overall, everyone’s just going to be happier. So we’ve talked about all these pitfalls. What are some actual examples maybe of some things internally or personally that we’ve done? Because again, we don’t want to always put things on the client side. We share the onus on projects and it’s just as important for us to keep an eye on pitfalls. So let’s be kind of candid. Where have we had some of these issues with pitfalls?

Andrew:

All right, Well, I’ll give an example of myself pre-Bixly, okay?

Cris:

Ooh, okay.

Andrew:

There we go.

Cris:

All right.

Andrew:

So this was quite some time ago, but it comes back to the whole communication thing. Doing a lot on phone calls with clients and things like that. Communication’s important, but something I’ve found was just because you talked about something on a phone call doesn’t mean you’re all on the same page about it. Like you think that you’re on one page and the client thinks you are, but maybe that’s not the case.

Andrew:

So I had an instance with a client where we had kind of an impromptu discussion about the general direction of the project and we discussed, “Okay, we’re going this way.” At one point during the conversation, there was an idea thrown out. It turned out it wasn’t the right idea. And so that was shot down. So we moved forward after the call and a week later when we talked the client, that idea that we shot down. In their mind that was the direction we were going.

Cris:

Ah, okay.

Andrew:

And so fortunately there were other people on the call to kind of verify that, Yeah, that wasn’t actually the decision that was made, but it still left a really bad taste in the client’s mouth. So a way we mitigate that now is after pretty much every phone call, if any sort of decision’s made, there’s just a quick follow-up email. We do this kind of bullet points like these are the key things we touched on. This is the direction we’re going.

Andrew:

It just helps refresh everybody’s memory. It is easy to misunderstand something or maybe they’re they got a phone call during that part of the conversation. I don’t know it. I just assume they heard it. So just doing it as a recap emails to keep everybody in sync has been really helpful.

Cris:

That’s good. And it’s why it’s so important that have some sort of just task management tool, whether that is literally task tracking within your GitHub or GitLab instance or spinning up something like a Jira or a Basecamp or a Trello or whatever it is. A Google Doc if that’s what it is. I mean, at minimum, have a Google Doc and know that you’re recapping everything after a call in some way because things come across differently in a conversation than they might even come down on paper. But ultimately that paper trail, whether that’s digital or physical is important to have because it keeps everybody responsible and it’s something you can look back on.

Cris:

There’s no issues. It’s not, “did we say that?” Yes we did. It’s right there. So I think that’s definitely another common pitfall that over the years we have learned and you’ve been really strong on pushing that. That if we talk with a client, let’s get that written down. Let’s get that emailed out to them. Let’s get it documented because it’s going to help everybody.

Cris:

Other things, other ideas, things that are important for projects and why it’s so important to look out for these pitfalls that we should be talking about?

Andrew:

I mean, the main reason it’s important to look out for pitfalls is it allows us to do risk mitigation so we can take precautionary measures if we know what the risks are, we can help mitigate those.

Cris:

And we being everybody involved in the project. This is not just for our benefit. This is for the clients and other development teams we might be working with. Everybody benefits from that risk mitigation. No one likes bad surprises. We like good surprises.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday. I hope you enjoyed that conversation between Cris and Andrew as they talked about all of the different kinds of pitfalls that you should keep an eye out for so that you can avoid them, do some risk mitigation on your software project. If you have any questions at all about what they talked about, go ahead and leave it in the comment section.

Alexandra:

And don’t forget to check out the description box down below. We have a lot of helpful links in there for you, including a link to our free custom software guide, as well as a link to our website, bixly.com.

Alexandra:

If you head over there, you can actually find right at the top Start My Project Roadmap. And that gives you a free 60-minute conversation with Cris to talk about your next app idea. It’s free. It’s obligation-free so don’t hesitate to reach out and connect with us. Until next time, this has been an episode of Bixly Tech Tuesday.