Software Outsourcing Pitfalls

Congratulations! You’ve found a reliable, relatively inexpensive software development team in a different country to help get your dream project off the ground. Everything’s going to go smoothly, right? Umm… not so fast. There are a lot of common blunders and mistakes that people make on both sides of the equation: whether it be client or vendor, things do go wrong. Over the last 12 years of running an outsourcing software development shop, I’ve picked up a few things that help keep projects on track. Here are a few of the main points that I’ve found to help the most:

(Note: most of these apply to cases where we’re working with a small company/individual entrepreneur on the other end. I’ll write something about working with bigger companies in a future post).

1. Have daily standups: If you want a project to go smoothly, please, please have daily standups. For the uninitiated, daily standups are short meetings (5–10 minutes) that allow everyone working on a project to go over 3 things: What they worked on yesterday, what they’re going to work on today and also a list of problems their facing, if any. This allows you to get a good sense of how the project is progressing. This is one of the things we really like having in place and, for the most part, we do it with all of our projects. It keeps everyone aligned and nips communication issues in the bud. These can taper off in frequency after the project is in a good rhythm, but is extremely beneficial at the outset.
2. Working together on requirements/specifications: Sometimes, we have clients who know exactly what they want and have it fully documented. Sometimes, we have clients that only have a vague understanding. In both cases, it is important to work together to get things further refined as the work progresses. Working with a client to figure out the solution they want is a rewarding experience in and of itself. A fully spec’ed project still has room for interpretation, so it’s a great idea for the development team to understand the business use case of the project to aid in decision making. Also, we firmly believe that it falls on the development team to forward their own ideas so the customer gets a better product at the end of the day. The customer may not take suggestions, but that’s OK. The important part is having a conversation about it.
3. Have weekly deliverables: This probably applies more to the small/medium sized projects we work on, but having regular code drops/builds is an important part of our process. We usually have automated deployments go out to a staging environment, so the client can always take a look at the latest development. We warn them up front that things might break at any time, so they don’t stress out about the staging deployment being down. This greatly helps with making sure expectations match the actual progress. It can also lead to a lot of stress, but that stress usually serves to get you back on track, so it’s all good in the long run.
4. Both sides need to be respectful: Clients and service providers alike need to make sure they’re respectful and also need to appreciate the other person’s perspective. I’ve seen several projects get into a “us and them” kind of state; this doesn’t lead anywhere. Everyone needs to remember that they’re working on the project together so they have similar goals.
5. Making sure the developers have what they need: If the team you’ve hired doesn’t do design, don’t expect them to come up with a brilliant user experience. You’ll have to hire a separate person for that. If the team doesn’t have an Amazon Web Services account, sign up for one and add them as users (although if they don’t have one of these, are you sure you want to work with them?). Giving the team the tools they need to get things done is essential and sadly, very easily forgotten.
6. Don’t overwhelm them with ideas: Don’t throw every idea that you have into a conversation. It can lead to a lot of distraction and stress for developers. Let those ideas ferment a bit, write them down and then share them. Remember, the team needs to focus on delivering what you need right now. The “next” part can wait a bit.
7. Have a technical person involved: This is probably the thing that makes the most difference: having a technical person on your (the client’s) end gets rid of about 90% of communication issues and makes the experience more pleasant for both parties. The only reason you should not have someone technical on your immediate team is if you can’t find one at all.

I hope these tips help someone at some point.

An outsourced team can be a great asset and also a great liability. If you choose well and are good at being involved and following up, most of your projects should go smoothly.

Good Luck!