I presented “Managing Your Projects to Success” to the Xojo Virtual User Group in February 2018. In this presentation, I cover some of the most common project problems that software developers run into and how you can use project management tips to manage your project to success.
Please find the full video transcript below:
Wayne: Now I’m going to pass over to Susan who’s going to do her presentation. Susan, if you want to ping the screen.
Susan: All right, guys. Hi. Good to see you, or, I guess, not see, but hear me, guys. I am Susan Fennema. I am not a Xojo developer. I run Beyond the Chaos, and Beyond the Chaos does operational and project management system setup and actual project management for small companies, many software development companies. A lot of this is very targeted to the software development world.
Let me tell you a little bit more about me since you guys don’t know me that well. I do participate in the forums. I have spoken at Xojo last year, and I will be there again this year. I am a non-technical, non-certified project manager, but I love technology. I adore it. I do everything in the technology way.
I am a Texan, and I’m a Texas Aggie, class of ’88. I am a home chef. Let me just tell you, as a project manager, if you do those types of events, you have a spreadsheet for it, so you get to actually project-manage your hobby. That’s fun for me. Other people might think I’m insane, but I think it’s a blast. I am the wife of a mechanic and the mother of two cats and a dog, and I am the daughter, sister, and best friend of small business owners. I’m a huge fan of small business. I worked in one large corporation. I couldn’t stand it. I’ve always worked for small companies, and that’s who I serve now too. By small companies, I mean one to five. The biggest company I work with right now is about 25 people.
Enough about me. I’m going to address some of the problems that you guys are probably facing. I’m going to assume that many of you struggle with finishing your projects; that you probably have some problems managing scope; that you get pulled in a lot of different directions, you don’t always know what to work on next, probably just answering the squeakiest wheel question, bouncing around a little bit.
I’m guessing, and I’d love to see in the chat if, or, I guess in the Q&A, if you can tell me as we go, and then I can try to tailor a little bit, whether or not you work with some contractors or other team members or if you have people to delegate to or if you’re just all one-person shops. That would help me a little bit in pointing some of my presentation to you. I am sure that you all wish you had a way to keep things organized instead of stacks of paper or everything in email. The bottom line comes down to I want you to be running your business and projects. I don’t want them to be running you and your life. That’s where we’re going to get to.
Let’s solve the root problem, and just so you know, all businesses have the same challenges. This is not only software people. It’s not only developers. Everyone has the same issues. Many of the small businesses like yourself, you don’t want to add bureaucracy. You want to add some structure, but we don’t want to add this layer of bureaucracy that makes things harder. We want to add structure that makes things a little bit easier. We want to be able to repeat successes, prevent disorganization. That kind of thing comes with structure.
Let’s talk about the basics. First is policy. That’s going to be more for multi-person teams. You have processes and procedures, and then there’s also project management then on top of that. We’re going to talk through those three things. Let’s first talk about the difference between policy, process, and procedure.
Policy are the rules. If you are a one-person shop, you probably don’t need a rule that says what time you open in the morning and what time you leave and what are the requirements to do your timesheet. Those are the policies. They’re just the rules that you follow. Now, if you even have one subcontractor that works with you, you should have some sort of basic policy, just “these are the days we’re closed, these are the hours of operation,” those types of things to help them understand the expectation of when they should be available.
A process is a system. This is usually written. It’s a document, and it’s in prose. It’s not exciting prose. It’s not like you want to sit and read it as a book, but it’s something that you can refer to to figure out what the next step is.
A procedure, on the other hand, is a checklist, just a straight up-and-down-the-list checklist. It might be how you install software, just one thing after the other. Another perfect example is an airplane pilot’s checklist, the things that they go down the list every single time and check off so that they don’t have to think about it, and they don’t have to forget or remember all of the specifics. This checklist lets them do it repeatedly over and over without much thought.
Let’s focus a little bit on process because I think that that’s where many of us fail in having a consistent way of doing things. First with processes, why do you need them? Really, the key is to repeat your successes. Those things that you do well? You want to make sure you remember how you did it well so that you can do it again well. The other is not reinventing the wheel, just like we were talking about with the procedure for the airplane pilot. If every single time you try to onboard a subcontractor, you have to remember everything they need access to, everything that you need from them, paperwork, all of that, it’s harder. If you just have your list, if you have that process of how you’re doing it, you can just go through and check it all off and not have to think about it.
More importantly, think about off-boarding that subcontractor. When you’re ready to cut them off, if you don’t have a clear list of what to disable for them, that could be a bigger problem than what to enable. Those are important things in not reinventing the wheel. You waste a lot of time. A lot of those things too are not done that often. Maybe you do it once a year. It’s really hard to remember what you did last year.
The other thing about processes is it lets you start delegating. That is a big key. One of the ways that I did this, I have a project manager that works for me. One of the ways I wrote the processes for Beyond the Chaos was I did a Zoom meeting just like this with my new person. It’s the very first time I’d ever done it. I talked her through the process. We then sent the recording off to have it transcribed, and then I already even had the words. It was real easy just to go through, edit that, and get it posted in a central location, and now, she has something to refer back to, we have something that we agreed on as a way that she was going to do things for me. That is a really good little cheat-sheet way of getting some processes written down for yourselves.
What do I recommend as minimum processes for a small business? That includes even one person. First, your sales process. As far as sales, I mean from the point that you talk to them the first time to the point you get paid. How do you navigate that? How do you make sure that you’re following up, that you’re not forgetting to touch them again when you didn’t hear back from them? Part of sales is that your job is to get the answer from them, not just to ask the questions. You have to have a method of how to get that information back if they don’t answer the first email you send.
Invoicing and getting paid is important too. In my business, I have some fixed-price projects, which I will send an invoice in advance for. I’m paid in advance. That’s easy. But then I have others that are more project management-oriented that are banks of hours. Since there are multiple clients in that area, it would be really hard to just figure out when each client is out of hours and bill them. Instead, I have the process that every Tuesday, I check in on their hours, and I see where they are, and if they’re close, I bill them another one. It’s a repeating process instead of a “one day, maybe I’ll figure out that they’ve already burned through the next bank without me billing them.”
Of course, projects. Without question, you need a project process. With that, how do you open them? What is the general structure? What are the milestones that you’re going to be following? Then also important, how do you close a project? It’s important to remember that the goal is to deliver something to the client and to finish it. That closing process might include things like asking for screenshots to put up on your website for use with other clients, asking for a testimonial or a referral or making them aware of a referral policy you have to encourage them to refer you. In general, you look at all of these things, and they’re all big things, but the way to accomplish it is to do all the little things that make it up, and that’s what we’re talking about when we’re talking about writing a process, those little steps.
Project management tools. Now, if you heard me at Xojo last year, I’ll say it again. I say this in pretty much every presentation I make. Email’s not a project management tool. If you’re using email, you’re doing it wrong. Please stop. Make sure that you have some sort of a tool, and I don’t care if it’s something that you’ve built or something off the shelf.
Basecamp and Teamwork are very, very good tools. I know that many of you want to build your own, but your job is to build them for other people. Many times when we build our own, what happens is it never works right. It always has bugs. You never have time to finish it. It’s three versions back. I could go on and on with all the things that I’ve seen with people trying to build their own custom solution. Basecamp and Teamwork work out of the box. They do the things you need. You don’t need to reinvent the wheel on that. Those things, you have to add structure to them, and none of these are magic. You still have to actually project manage, but the tools give you the framework to work with them.
Another part of your project management toolkit is regularly-scheduled status meetings. If you are working actively on a new project, and in this case, too, I’m not talking about ongoing maintenance where you’re doing bugs on a regular basis or you have one off little request to fix. I’m talking about actually implementing a new solution. You would want to have regularly-scheduled status meetings with those clients. If it’s very busy, if it’s a very fast-paced, I’d say weekly, minimum. These are only half an hour. You’re not spending hours and hours talking about technology in here. You’re talking about where you are, what you need to accomplish, and what might be a stop from them, and get that information from them.
The other key of status meetings is that it helps prevent interruptions. If your client knows that they’re going to talk to you next week at 2:00 on Monday, then they might not pick up the phone on Friday and interrupt you. More than likely, they’ll say, “Oh, I’m going to talk on Monday. That’s great.”
The other project management tool is your proposal. All of it starts from the proposal, how well you scoped it, how well you’ve defined it, that you’ve put a timeframe in it. All of those things are important to start at the very beginning, which is when you tell the client what the expectation should be.
Let me give you a few tips on project management. In a solution like Basecamp or Teamwork, each client needs its own project. Now, might there be a subset of clients that needs access to something separate, yes, of course. If you have a different department or a completely different solution that’s being built for a different group of people, even though that might be the same client, it might logically need to be its own project. It’s not a hard-and-fast rule. It’s a guideline, as most of these are. Make them your own, use them the way that it works for you.
Any to-do or task needs a date and a deadline. If you just put the list into Basecamp or Teamwork or any, Asana, any of the software out there, it’s going to get lost. It needs a date and a deadline, and it also needs a person responsible for them. Those three, the date and the person is what allows you to pull up a working list of what needs to be done and who needs to do it.
Also, you can include milestones rather than setting deadlines for each task. Back to my “install the software on the server” idea, you might have 10 steps for that, depending on what you’re doing. You can just have the one milestone of the software will be installed by March 31st, and then all of those other ones fall underneath it. That’s fine, but make sure that that has that milestone date. You can’t drive a project without the dates. All you can do is hope it happens.
It’s like setting a New Year’s resolution versus setting a goal. New Year’s resolution is, “Hey, I want to lose 25 pounds.” A goal is, “I am going to lose 25 pounds by losing two pounds every month by going to the gym, by eating better. I’m going to cut back on fatty foods on the weekend.” Those are actually steps, and you have a timeframe to it. A project works the same way. If you just have your tasks and no milestones and no timeline, you just have a hope that, one day, it might get finished.
The other is that if you’re struggling, you can get a professional like me, there are others, to build your structure and your template for you. This is not always a small business owner’s thing is the details. They like the big picture. They don’t always like finishing. They like creating, and this is not always that creative. This is the down-and-dirty “get it down.” If you don’t have or know a professional or want to use one, consider using somebody you know is good at it. It might be a spouse. It could be a colleague. Maybe you can exchange that kind of work for each other to help you get set up and following up.
How do you set milestones? You want to start when the project is due and build backwards. Many times, what you find out is when you do that, if you start at the due date and you build backwards, you might already be late. Make sure that you have allowed ample time your proposal. Not a bad idea if you are putting that proposal out to do a rough draft of your milestones before you send it out so that you do know you have time to do it. If you have not set a deadline, you can schedule forward. If there is no set delivery date, you can schedule from the first step and move forward, and then you can see whether it turns out to be a realistic date. That’s the other thing. Sometimes, you’re like, “Oh, well, that’s next year, so I might have to tighten that up a little bit.”
It is important to set all of these because you push the project forward by having these deadlines. That is the other thing of having a status meeting with your client that also helps is because you are obligated to show or talk to them or at least feel badly that you The other thing is to make sure that if something happens to affect the deadline, that you communicate in advance with your client. If you run into a technology challenge or if, as something, some, happened to one of my clients, they had appendicitis. They had to go to the hospital. You want to make sure that you’re saying, “Hey, listen … ” Maybe after you get out of the hospital, you might tell them, “Hey, listen. I’ve been in the hospital. I’m late. This is not going to happen. We’re going to have to reschedule. I need another week.”
As long as you’re telling your client in advance, they’re usually very good about understanding the situation, but if you just show up on the date it’s due and say, “Oh, yeah. I had appendicitis in the middle of this, and I didn’t get it done,” they’re going to not be quite as accommodating. Make sure that you’re doing it as in advance or as immediately thereafter as possible.
As part of your milestone-setting, you’ll include every major step that you can think of. You’ve done this before. You know the steps. Put them all in there. Share the schedule with your client when you start. That keeps you both on track. It also gives you the ability to modify that schedule at the beginning versus the client’s, and if you have team members, their schedules. If you are ready for the client to test on June 1st, and they’re like, “Oh, yeah. My child’s graduating May 31st, and June 1st, we’re leaving for a month to take them to Spain,” you might not be able to meet your schedule. Having that ability to have that conversation with the client when you start the project will help you adjust it as need be to accommodate any of those things that might come up.
We have it all set out. It’s all out, and guess what? Changes. They happen every time. I can do a whole hour on changes. I’m not going to do a whole hour on changes. I’m just going to give you the gist here.
First, don’t let them get you off track. You did discovery. You did a proposal. You guys worked together for a long time on what they needed. The little changes that come up in the middle are very exciting for a developer, oftentimes, because it’s, “Oh, yeah. I could totally do that. It’d be so cool,” but that’s going to get you off track. You’ll burn through their hours if you’re billing by the hour. You’ll eat into your profit if you’re billing by a fixed price. Just be very careful with those changes. Learn to say no. It’s hard, but you can.
Thing to remember too, I think a lot of times, we want to serve our client by doing what they’re asking, but remember this: An undelivered project has absolutely no value to the client. If you’re constantly being sidetracked, you’re not going to deliver them the solution that gives them the value. You’re the service professional, and it’s your obligation to keep the client held to that original scope so that they can get the value that they expected in the beginning. Remember that this is, software is your job, but you’re just making a tool for them to do theirs. Sometimes, you have to calm them down too because they get excited, and they start dreaming. You want them to dream about what you could create, but until they have something in front of them that they can use to do their job better, the solution has no value to them at all.
Always fulfill the scope that you decided first, and then come back and address the changes. I’ll give you some ways to make sure that you capture those too.
Stop and talk about any dramatic change. Now, if all of a sudden it changes the whole outlook of the solution, yes, you have to stop and talk about that. You might then have to re-quote the job. You might have to give them the new timeline. You might have to tell them that you can’t even do it anymore. Who knows? Maybe there’s something that now has been brought up that the software can’t solve or you don’t have the experience to solve. You might have to bring in other people. That’s a delay, that’s more money, all of those things. If something dramatic happens, stop and reset.
Also, as mentioned with the appendicitis, also consider issues that are beyond your control. We had fires in California this past year, and we had hurricanes and Houston and in Florida. Those things are, they stop the people’s lives, if you’re working with them. When you’re working on timelines and you’re waiting on them, and something like that has come up, you’re going to have to redo the schedule, regroup when it comes back, and reset.
Part of all of this is setting the client expectations. I know that in dealing with changes, it’s hard to remember that you’re serving them, and sometimes it’s scary. It’s scary to say no. It’s scary to have that conflict, but don’t think of it as conflict. It’s very simple. The scope is a scope. You wrote it down. You have a project tool that demonstrates it. That’s straightforward. It’s nonemotional. The scope’s a scope. The timeline is based on the scope. You built your timeline based on the scope that you agreed to. If one of those changes, the timeline or the scope, it’s going to affect the other.
Any of these changes affect the price, whether it’s if you bill by the hour, if it’s the number of hours that you’re putting in, or if you’re on a fixed price and you’re adding scope to it, then they don’t need to get stuff for free. If you’re trying to do it faster, they don’t necessarily need that as part of the free price either. Even if they do things slower, it will just eat up your time. You want that timeline to be reflective in the price as well.
It is very important that you have clear communication with consequences to your client. These are my four Cs, and I think that they’re really important. It gives you the ability to say, “Hey, listen. If I don’t hear back from you on Friday, this project’s going to be delayed.” Now, if the project’s delayed another week, you can even come back and say, “Hey, listen. I know you’re busy. I know you’re struggling with some things, and you can’t get to me right now, but if I don’t hear back from you within another week, it is going to take me more time to get back into the solution, which is going to cost you more money.”
You can say some things like that so that the client is clear, and they’re making the decision. They can still make the decision of, “Yeah, we are having way too many things going on at our company right now. We’re going to hold, and that’s okay. I will pay more for it later,” but if you don’t tell them that up front, then they’re going to be like, “Uh, why does this cost more?” You’re like, “Well, because it took me three more hours to figure out where I even was since it was a month later when you heard back from me.” Well, they’re not going to respond to that as well as, again, like we spoke about before, is if you tell them in advance.
The other is to give them a way to dream, and this is the wish list. This is what I was talking about when you’re saying no to the little things. Capture it. Make a list on your software, Basecamp, Teamwork, any of those, your project management software, of a place where the clients can actually dream. This is little changes. It’s big things. It’s a whole new module. It’s all of those.
Here are the results of using that wish list: Your next project can be built off the wish list. You can group those things and make a change order as individual group of tasks. You can also say, “Oh, there’s a whole bunch of little things. I’m going to make a change bucket.” This might be a retainer or a bank of hours, but money on deposit with you. This is money paid in advance, which kind of buys your time and attention so that when they do come up with little things that they want fixed, that you’re a lot more apt to, “Oh, yeah, that’s 15 minutes. I’ll just take it out of your bank or your bucket or your retainer, and I’ll knock that out for you right away.” If you have to figure out how to bill for it after the fact, it sometimes just doesn’t get billed.
Those types of change buckets or retainers, that is a great long-term support option for people after you’ve actually put together their initial project, but that wish list is where they can track all of these and decide which ones they want to do and when they want to do them. Then you can figure out how to get them paid for after the fact, so more money, more money, more money. That’s always good.
All of this requires you project managing yourself. Part of what I often recommend is making sure that you create a project for your business, that you have tasks that you can remember and assign to yourself and that you can remember that you want to write a blog post every two weeks. Make something of yourself for yourself to manage you and your business. You can keep your operations tasks there with any due dates and assign to you or your team members.
The other thing is to block out time on your calendar. If you … I’m a big proponent of time-blocking. If you want to develop uninterrupted, put three hours on your calendar that’s development time, or four or eight, however many you want, and block it out. Now, when somebody tries to call you, you are in a meeting. It is a meeting with yourself, but it’s a lot, mentally, it’s a lot easier to say, “No. I’m in a meeting. I’ll let the phone ring. I’ll check email later. No, I’m not going to take a meeting that day. This is what I’m focusing on.”
Another tip is, at the end of each day, not in the morning, and I’ll tell you the psychology of that, but at the end of each day, look at what is on your list to accomplish versus your calendar, and be realistic. You can’t finish everything. If something has to give, figure out what’s the priority. If you do this at the end of the day, the psychology is, is that in the morning, you’re staring with a plan instead of spending your morning figuring out your plan. When you’re fresh and ready to go, you know what your main number one thing to do is.
That is, in general, project management. I mean, there’s a lot more to it, but those are the top tips I can share with you.