How to make specifications for an outsourced project?

The traditional notion of outsourcing projects, whether it’s to a nearby firm or a team on the other side of the planet, is that you need to specify things. Many people believe that in order to outsource a project far away, they need to specify everything. And because it takes time to specify, they are reluctant to engage remote teams. Usually, the idea of outsourcing starts because of time constraints – you don’t have the people or the time to do it inside your own company. So we have a chicken and egg problem.

I experienced the same when I started with outsourcing 10 years ago. Because it’s hard to get your ideas across to other people, especially in software development, you believe specifying everything detailed is the only solution. But nowadays, humanity and software development has evolved. Remote teams became more mature and know what it takes to collaborate successfully with clients from the West. Tools to structure communication have become much stronger and more widely available. And software development has changed.  

 While for smaller projects, specifying every detail might still work, in most cases a more agile approach works much better. Instead of specifying everything, you describe short user stories. These stories you store in a tool like Jira. And every week or two weeks you do a sprint planning session with your team to walk through all the user stories you (and the team) has gathered. In this session, you discuss what the user story means in both functional and technical terms. The scrum master stores the solutions in the tracker in words, supported by graphics or links or diagrams. The product owner (typically onshore) could re-check what was agreed before everything is implemented.

So there is no need for the onshore project manager to specify everything, it We have a project in which I am engaged. The setup we chose is to have a product owner facing customers in the Netherlands. Then we have a proxy product owner, who’s in India, together with the scrum master and the team. As it’s a marketplace we’re building, I gather feedback from the supplier side (as well as from the buyer side). To share the things I learn from my feedback talks, I join the backlog grooming session as well as the demo. In those meetings, I share insights, suggestions for user stories and give my feedback on what we’ve built so far. I have no need to specify anything, this is the role of the product owners. The Dutch product owner does the sprint planning, but remains on headlines and agrees them with the proxy product owner. Then proxy product owner then describes the ‘real work’ together with the team and scrum master. And it works! 

We do weekly sprints and continuous integration, so whenever I learn something crucial on day x, I can oftentimes see it implemented on day x + 1 or 2. To get the team up to speed this way, took us some time. You need to do strong retrospectives, agree on good engineering practices. Above all, you need to have a team that can do the thinking and doesn’t need you to specify everything in detail. But I am convinced that with a strong team and a strong collaboration process, you don’t need to specify a thing and you could start outsourcing your projects wherever the team is located. It’s 2014, not 2004.