Outsourcing Development Part I: Clear Communication
It’s always the same
I’m having a nervous breakdown
Drive me insane!
Few things will waste money faster, and cause more strife across teams, than miscommunication. The risk goes up with distributed or outsourced teams. Luckily, there are simple, effective practices to overcome these challenges. They work regardless of whether it’s a big enterprise project or a startup MVP. And not only do they work, they save you time and effort!
I don’t think there’s a more important concept in software project management than ubiquitous language, and it couldn’t be simpler.1 Whenever you talk (or write) about the project, consistently use the same terms for the same concepts.2 And make everyone – business analysts, users, programmers, designers, managers, etc. – do the same. Use it in the documentation, code, database, and UI. The result? Incredible communication efficiency! And drastically reduced chance of implementing an incorrect requirement (one of the most expensive mistakes you can make).
At project start, create a glossary of all terms and get everyone to use it. Of course, keep it updated as it evolves. I like Google Docs for this, but a wiki, or even a text file in Dropbox, works just as well.
A Little More Conversation, A Little Less Action, Please
They say a picture is worth a thousand words, and that’s just as true of wireframes (AKA pen and paper prototypes). If you decide you’re building from scratch, start by sketching out the UI. List out the actions different users (e.g., admin, customer, vendor, etc.) will take and draw a simple interface to get this done. As you include more user actions, your UI will grow more robust. Then, ask your customers if that’s what they need. That is hard if you’re in love with the idea, but it’s so much cheaper to change that prototype than it is to change your software, and your customers will understand it just as well. It will also give you a deep appreciation for the UI/UX design process.
The good news is that you don’t have to use pen and paper, as there are several programs that will make this easy. Balsamiq is probably the most popular, but you may prefer Mockingbird or HotGloo. If this task is at all intimidating, first read Steve Krug’s fantastic book Don’t Make Me Think. It’s quick, fun read that will radically improve your interface (especially if you’ve never designed one before).
One Tool to Rule Them All
It’s important to choose a project management system that is made for tracking software development. The right system will capture requirements (include any wireframes you made) and defects, and allow developers to connect them to code in the repository. That leads to easy documentation and faster developer on-boarding. It will also allow stakeholders to comment on issues and get updates via email.
I like JIRA or FogBugz for this, but there are many, and the company you hire may have one it prefers. It’s important to note that popular project management tools like Basecamp and Microsoft Project do not handle this.
Most of all, don’t invite miscommunication by using two systems, with the client/managers on one and developers on the other. We have the client sign up for the PM system and the code repository so they never worry about getting access to that when the project ends for whatever reason.3 We still manage the technical side of it all and train them how to use it.
These practices will lead to a major reduction in risk. Now, continue reading about build vs. buy to learn about cost savings. And feel free to share your ideas and experiences in the comments, or contact us for advice.
Part II: Build vs. Buy
- Credit goes to Eric Evans, author of Domain Driven Design. There’s a statue of him somewhere in the Project Management Hall of Justice.
- As Martin Fowler wrote, you can think of this as unambiguous language.
- I imagine some agency managers are blinking rapidly as they read that in disbelief, but yes, making it easy to leave us is one less barrier to hiring us.