LEARN HOW TO BUILD YOUR OWN SOFTWARE EMPIRE CLICK HERE TO LEARN HOW

Episode 13: The Importance of Project Management

Episode thirteen is all about the importance of project management and Garrett and Scott relay multiple experiences they’ve had that has taught them this over the years.

Software Funnels is still coming along but we do talk about a little hurdle we overcame while Scott and Garrett were in Guatemala.

Ironically enough it was a great segway into why a project manager is such a critical piece to building software though.

Lots of “secrets” are given in this episode so be sure to listen!

Be sure to subscribe to our podcast and automatically receive updates on each episode release. Thanks for listening!

Click here to read the podcast transcript

 

Garrett Pierson: Hello, and welcome back to Episode 13 of the Software Secrets Podcast. Today, we’re going to talk about the importance of project management, super important, and we’re going to give you a status update on software funnels. I’m Garrett Pierson.

Lindsay Halling: I’m Lindsay Halling.

Scott Brandley: And Scott Brandley.

Garrett Pierson: We’re excited to be here, again. Another week! Let’s give you guys a status update of where we are with software funnels. I feel like we’ve got a long way to go and a short time to get there. That’s what I was trying to get at.

Scott Brandley: I’m thinking of Smokey and the Bandit.

Garrett Pierson: I totally spaced. Yes, we’ve got a lot to do and not a lot of time. Funny enough, that’s when, I think, things get done. When your back is up against the wall, when we’ve got to push the programmers a little harder, when we’ve got to think things through. I like this, in the sense of getting rid of that scope creep and feature bloat, where we’re just putting in the necessary things to get this to the market as fast as we can. That’s what you guys need to do when you’re building software and you’re starting out and getting that minimal viable product to market. That’s, kind of, where we’re at.

Lindsay, you’ve been working with the programmers. Wireframing is so close. It’s going to be done this week.

Lindsay Halling: I think it will be done, for sure, this week. I want to say they said the last update was 90 percent done. We’re pretty dang close.

Garrett Pierson: We’ve got that going. We’ve got projects going; our Trello comparable tool. A lot is getting done on that, so that’s awesome. Analytics tool, still getting through a lot of that and I think that might be done in the next couple of weeks, really. Lots of calculations, though, with those analytics. That’s exciting.

Scott Brandley: Should we talk about when we were in Guatemala and we were up against wall of the projects? I think that’s an interesting story.

Garrett Pierson: What projects?

Scott Brandley: Wasn’t it projects that they said they couldn’t do?

Garrett Pierson: Oh, yeah.

Lindsay Halling: We didn’t talk about that.

Garrett Pierson: Yeah, that’s a good thing. We’ll do that in a second. The next thing is, Lindsay and I have gone through, again, the chat tool. Just making sure we had all the details because as soon as he’s done with wireframing tool, he’s going straight to chat. We went through that again, just to make sure we didn’t miss anything and the details were all in order and looking really good.

We also went through the whole help desk. We’re not done yet, but we got through a lot of the details for the help desk tool. As we said in our last podcast, we’ve got another programmer joining the team to build that out so that can be ready for our launch, as well.

We’ve been working really hard. The Guatemala trip threw us off a little bit. Let’s talk about that; what Scott just brought up. We were in Guatemala, just happened to get cell service that night. I remember, we were driving back, I was checking some e-mails, and I got an e-mail from our head developer saying that the open source projects tool, like Trello, isn’t going to work. We can’t use it.

Scott Brandley: He’s like, “I looked around and I found another option, and I think we can make it work.” We looked at it and it was just garbage.

Garrett Pierson: We looked at it and it was like, “Okay, we might as well just build this from scratch because this open source really isn’t going to help.” Funny enough, I didn’t have connection with Lindsay, so Scott and I, on the fly, was figuring out … I’ve been through this before, and more than likely, you’ll come upon this situation where a developer says it can’t be done.

The first thing Scott and I did was, we were literally bouncing in a van in the middle of Guatemala, in the potholes, going back to the house we were staying at and talking this through. There was really two options; we start from scratch, which would be a huge project and lots of time.

Scott Brandley: We’d basically be building Trello.

Garrett Pierson: The second option, which I knew right off that we needed to do but we were just talking thing through, was push back on the programmers. I wrote them an e-mail. I still remember I got car sick a little bit because I was writing it, on the way back to the place that we were staying, in the van.

I wrote the head developer. What they were saying is the open source isn’t going to work in the environment that we have and there’s just a lot of problems and blah, blah, blah. I pushed back and was bold and said, “Look, you need to try and figure it out. Once you’ve exhausted all possible options, then we’ll go to a plan B. Otherwise, we’re not doing plan B until you tell me, 100 percent, you can’t get this to work.”

The next day, they went to work and figured it out.

Scott Brandley: By the morning, they were like, “Yeah, we can make it work. We figured out how to make it work.”

Garrett Pierson: It doesn’t mean that they weren’t trying. Sometimes, programmers just need a little bit of push back. This goes right into what we wanted to talk about today, which is the importance of project management.

You need a project manager that is managing your project even when you finish developing it. There’s always going to be bugs. There’s always going to be innovation and improvements. You need a project manager that is pushing these programmers and getting things done so that they can be managed.

One of our companies, our biggest one, we’re growing and so we’re adding more programmers to the team. We’ve been meeting a lot the last couple of days on, “How do we manage these programmers well?” It just reiterated to us the importance of project management.

That’s, literally, what software development is. It is developing software through managing programmers.

Scott Brandley: And people. There’s graphic designers and things …

Garrett Pierson: It’s so important that somebody is managing the project. Generally, that’s going to be you. You, the one listening to us. Maybe, you’ve hired somebody to do that. In the case of software funnels, we’re managing that project. Lindsay’s doing a lot of that, but Scott and I are right there with her because we’ve been there before and we know all the ins and outs. She’s doing a great job of pushing things through.

This is just one example of when a team member, or a team, can’t figure something out. A project manager, in this case, me, because I couldn’t get a hold of Lindsay to send the e-mail, but we pushed them to figure things out. Communication; we’ve talked about communication a lot.

Basically, this is my opinion. A programmer is only as good as they’re being managed. Any programmer, whether they’re in the states, whether they’re overseas, it doesn’t matter. They’re only as good as they’re being managed because most programmers aren’t, necessarily, organized. They’re just analytical. They just try to get things done, but if they’re not managed in doing the priorities, they’ll naturally go to their comfort zone and do what they want to do. It doesn’t work that way. You’re not going to get anywhere. You’re not going to progress. A programming team is only as good as they are being managed.

Lots of times I’ve heard people, and this has even happened to us before, where you go out and hire somebody and you’re like, “Well, they’re not that good.” Generally, within the programming world, they’re not that good because they’re not being managed very well. That’s my opinion. That’s my thoughts.

Lindsay, what are your thoughts on this? You’re a project manager, now, what are your thoughts on this?

Lindsay Halling: It’s interesting that we use the Guatemala experience as our example because, on the flip side of that, while Garrett and Scott are in Guatemala, I get that e-mail and my first reaction is, “I don’t want to make that decision without Garrett and Scott.” I still needed that little bit of mentorship. Luckily, a couple of hours later, they resolved it. I just had this little bit …

That’s a perfect example of where a project manager need to come in. That’s supposed to be me, but obviously, with you guys as my mentors, you’re still very heavily involved and stepped up when I needed you to.

Garrett Pierson: You’re listening to this and you’re like, “Well, I don’t have a Garrett and Scott.” Well, yeah, you do. Especially when we launch the Software Secrets program. You can read our book and see how we’ve done things.

Basically, you have to be the leader when it comes down to it. I think that’s where Lindsay is saying we’re still in that leadership role, for now, with her. She didn’t want to make a decision with us being out of the country and just talking it through. When it comes to you, and you’re managing this project, you have to be the leader and make the decision. You are in charge. I’m talking to you, listening, you just need to be bold. If you want something done a certain way, the team better give you lots of good reasons of why they can’t do it that way because you’re in charge.

That doesn’t mean that you don’t get feedback from these programmers. They can tell you why they can’t do it or they can, maybe, even give you a better way. That’s totally fine, but if you want something done a certain way, then you be bold and you be the leader and you be nice about it, but you tell them how you want it and why you want it. Generally, through communication, everything will be fine and things will get done.

Let’s talk, quickly, a little bit more about project management and how a good …

Scott Brandley: Prioritizing?

Garrett Pierson: Yeah. How this works out and how you can be a good project manager.

Here are a couple of tips. Tip number one: Communication. To me, that’s number one. If you are not communicating daily, at least, or just making sure that your programmers don’t need anything from you, you are going to fail them. So, communication and, again, with software funnels, we’re going to have the chat area. A lot of communication happens through the project management.

They need to have access to you. You need to be aware of that. A lot of times, I’ll reach out, and I know Lindsay does this, too, we’ll just bug them. “Hey, how are things going?” That’s, literally, the question I ask. “How are things going?” I let them reply, then I’ll ask another question. “Are you stuck anywhere? Is there any questions that you have?” I’ll do that almost every day.

Scott Brandley: You’re saying you need to have active communication, not passive communication.

Garrett Pierson: Perfect, that’s even better.

Scott Brandley: You can’t expect the programmers to communicate with you. You have to be active. You’ve got to be the dominant voice.

Garrett Pierson: I like that much better. Tip number one, active communication; mostly by you or the project manager.

Tip number two would be: Priorities. That’s what project management is and leading; building a company, really. What is the priority? What is the number one, number two priorities right now? You focus on just those until you gt those things done.

Here’s the wrong way to do it: You have a hundred things that you’ve got to do and they’re all priorities. You’re going to fail, or nobody knows what the priority is out of those hundred things. You have to prioritize, “What are the one to three things that we need to get done?”

If you have more programmers, now it becomes … Let’s see. You have three programmers, now, on your team. Now it becomes, “What are all the priorities?” Now, I’ve prioritized all the priorities, now you prioritize all of those priorities into each programmer. Now, they each have priorities, as well.

In our project management tool, what we do is we create labels. We name them Priority One, and it’s red, Priority Two is orange, Priority Three is yellow. They’re in order that way so the programmers, we’ve trained them, they always know what the number one priority is.

We’ve taught them that if you can’t get priority number one done, then you must go to number two. If there’s a roadblock, you don’t just stop; go and work on priority number two. Don’t go to priority number two unless priority number one is done or you can’t move further anymore because you’re stuck. Even then, if they’re stuck, if they’re just waiting on something from a third party, or whatever, then they can move to priority two.

Priorities. Really, all you need to do is go through and map out what your priorities are. That’s what Lindsay and I do when we’re in the building stage. Let’s say we just told you that we did the help desk. What we do is we go through all the changes that we want and we put them in the project management tool and then, that’s when we start moving things around and start putting priorities to them.

Any thoughts on that, guys?

Scott Brandley: I’m thinking, when you first said that one of the problems is if you don’t prioritize, you’re going to have a hundred things on your list. That’s true. Naturally, that’s going to happen. If you don’t prioritize those things, what will happen is that everyone will get overwhelmed and nothing will get done, and you’ll always be treading water instead of getting above …

Garrett Pierson: What will happen, like I mentioned earlier, naturally the programmers, if they’ve got higher things, they’re just going to work on the things that they want to work on that’s in their comfort zone. Generally, those are the things that are not the priorities.

Scott Brandley: Right.

Garrett Pierson: Tip number three. What you need to do is, you need to organize these things in a project management tool. It’s just essential. You’ve got to put them into the project management tool; Trello, our Software Funnels project’s tool.

Here’s the next tip … So, tip 3.5: We may have talked about this before, but it’s so important. Never give a programmer more than two to three projects or tasks.

This is where it gets a little tricky. In Trello, it’s a card, right? In software tools projects area, we call it a task. Within a task, there can be multiple items that need to happen to accomplish that overall task, or project. It doesn’t mean that you just create a Trello card or a task card for every tiny little thing. What you do is you say, “Here’s what needs to be accomplished.” Within the card, or task card, all the little things that need to happen are in that. You never give a programmer, one programmer, more than two to three of those cards. Hopefully, that makes sense.

Scott, from your perspective because you don’t live in this world all the time, what do you think of that? Can you explain it a little bit?

Scott Brandley: When we were talking about this earlier today, one thing that helped me to make more sense of it is the whole idea of having a checklist inside of a card. Those are more like little items, almost line items, inside of the task or project that need attention, need to get done, that make up the overall task or project.

Garrett Pierson: Exactly. That’s my biggest worry; people listening are like, “Now I can never programmer more than two or three things to do.” No, that’s not what we’re saying. Never give them more than two or three Trello cards or task cards at a time because then they will get overwhelmed because they have too much to do. We’ve seen that happen. Let’s say you do have a hundred things, and you put all one hundred things in your Trello board, or your project’s area, they’re not going to get anything done because it’s too much.

Lindsay, why don’t you give us your feedback on this. What’s your take on this?

Lindsay Halling: When you bring up using a project management tool, there’s features within that that naturally force you to be organized. The card is a great example. You have to figure out what that specific card is going to be, and it actually compartmentalizes your entire project. For Software Funnels, a card might be one of the tools. It just naturally forces you to think through and be more organized. Can you imagine trying to send that in an e-mail? It would just be ugly. I really do think that’s a huge key to building software.

Garrett Pierson: Here’s a good example, I’m going to open up Trello right now. That’s currently what we use until we get our software out.

You go to our Software Funnels programming board, and each programmer has their own column. Within that column, there’s a card or a task or a project, essentially, that they need to work on. Our programmer working on the projects … We’ve got the functionality of the projects area, all the functionality that we want changed. That’s its own card and within that card, there’s a checklist full of details of the functionality that we want added or changed.

For example, he worked on the checklist functionality. The open source software that we’ve decided to use didn’t have a checklist and that was huge. That was one of the functionality items that we wanted to use. We put that as one of the tasks for this overall card project. The checklist functionality that we added details with screenshots and everything that we wanted it to do. That was one of the line items for the checklist.

That’s funny; the checklist of the checklist. The checklist task inside the checklist. We can see right here … You guys can’t see it, but he’s checked that off. He’s got that done, which was really cool. He got that done quicker than we thought.

I know this might be a little bit convoluted. When we do launch the Software Secrets training program, there will be a whole module on project management and how to use the project management tool and do it how we do it. You can use your own flair and use your own ideas, but if you keep those 3.5 tips that we just told you, you will be on your way to success in managing your project.

Scott Brandley: This is a critical piece of your success; effectively managing your projects. We didn’t always do this, and we look back to when we didn’t do this effectively and it was a nightmare. Things went really slowly and we were always flying by the seat of our pants.

Garrett Pierson: A lot of times, we didn’t even know what the next step was.

Scott Brandley: We didn’t because we never took the time to think it through. This is the right way to do it. If you want to be successful, then you need to follow people that have done it and that are successful. That’s why we’re telling you what we do. We can help you to eliminate that learning curve.

Garrett Pierson: In my opinion, this is the secret. This is the secret of Software Secrets. As weird as that sounds, it’s true. This is the secret; this piece right here and those tips that we just gave you in project management. This is the secret to effectively developing software and building your software empire. That’s what we’ve learned. We’ve made a lot os mistakes, but we’ve learned a lot on how to do it correctly.

Thanks, everybody, for listening. Next week, we are going to talk about pricing; how to price your product, some mistakes we’ve made, some tips.

Scott Brandley: What happens if somebody cancels and you start …

Garrett Pierson: We just had an experience with that today that we will share with you guys next week.

Go subscribe, if you haven’t yet, and leave a review. We’d really appreciate that. That helps us get the word out to more people. You can subscribe and leave a review by going to SoftwareSecretsPodcast.com.

Thanks, everybody.

Lindsay Halling: Talk to you later.

Scott Brandley: Bye!

Comments