I speak to many software companies that would like to outsource but don’t think they are ready. Sometimes they just don’t know how to get started with outsourcing.
What do you need to do before you can successfully outsource software development of your product?
Here are five things you should at least think about before starting to work with an outsourced software development team.
Create Your Product Roadmap
Where you plan out the future releases of your product along with the major features and benefits they will provide. Your product roadmap usually comes out of the process of gathering product requirements.
For example, at one of my software companies we had product releases planned out for a year and a half. This was mainly because our minds went wild imagining product features customers would want. Or what we thought they would want.
We knew customers would not wait for a super-duper product release containing all features. We budgeted out the features according to need, difficulty and customer desire. It is also difficult to design and develop a large software system all at once. Divide and conquer is a better strategy.
We assigned features to the releases in a product roadmap according to our estimates of usefulness and difficulty of implementation. The less useful or the harder-to-implement features were pushed out to a later release. Then we would show customers and prospects the roadmap. If they drooled over a future feature, we would try to move it up to a more near-term release.
Having a product roadmap is important for outsourcing because it helps you accurately judge the size of the engineering team you need and how long you will need them. Defining future features and releases also helps you from architecting yourself into a corner. (The “Oops! I didn’t know it had to run on a Mac” problem) Your product architecture and your programming team members should both be chosen to support future releases.
Gather Requirements and Write a Specification
As a way to explore and explain what your product needs to do. Software companies have different emotions about specifications. Some consider them dreaded programming artifacts that are quickly out of date and never read to begin with. Others are overly formal and treat the specification as if it is as important as the software product itself.
A major myth of outsourcing is you need a huge and detailed specification to do outsourcing effectively. The more detailed the specification, the more of an insurance policy it becomes for getting exactly what you want. It’s just not true.
Your specification should be a guide to the development team on how to get started designing and developing your product. Involve the outsourced team in the specification process. They can ask probing questions and offer insights into ways your product should be designed.
Imagine the best engineering team you have worked with at your company here in the US. Remember the give and take and intelligent discussions that took place as your products were designed and came to life?
Now imagine you do most of this communication by email, instant messaging and phone. You probably did anyway when the engineers were here in the US, right? That is how outsourcing works today. The type same smart engineers just happen to be in another time zone.
For example, one software company I spoke with recently starts outsourced software development by sending the outsourced team a page or two of product requirements. The VP of Engineering then carries out an on-line discussion where the product details are fleshed out. The outsourced team asks questions, he answers and after a week or two there is enough information to begin coding. It’s doing product design using the Socratic method.
I have written before about the process of gathering product requirements – what your product should do. (See Runtime – The Requirements of Good Product Requirements.) The requirements lead to the creation of a product specification – how your product should satisfy the requirements. (See Runtime - The Serenity of Knowing What You Are Doing.)
If there is just one thing you have time to specify about your product, it should be the Use Cases or scenarios of how you product will be used. Write down the names of the various roles of the people and systems using your product. Then write out the sequence of steps they carry out to use the product.
Do this for the major use cases of your product, the ones that deliver the biggest benefits, and you will be well on your way to successfully using outsourced software development.
Architect Your Product to Facilitate Outsourcing
Intellectual property is the life blood of a software company and should be guarded carefully. Most outsourced software development companies will fiercely defend your IP as part of their normal business procedures. Nevertheless, you should carve out the most sensitive parts and develop them internally.
Or you can parcel out the development of your product to multiple independent outsourced teams. That way no one team will have all the IP.
If you have an existing version of your product you can consider three ways to use outsourcing: (1) create your new product in-house and outsource maintenance of the existing version, (2) outsource development of your new version and continue to maintain the old version with an in-house engineering team, or (3) outsource both and use the internal team to manage your outsourced resources effectively.
You can read more about architecture and outsourcing in this past issue of Runtime – Architecting Your Software For Outsourcing.
Define Your Engineering Management Structure
To effectively manage and achieve success with outsourced software development. You need to hire a core technical team that does more product management than coding.
Should the CEO be responsible for the day-to-day activities of outsourced software development? Probably not. But it is important to have someone in your company be responsible for the successful delivery of your product. He or she needs to have the authority to deal with other employees and outsourced teams to get the job done.
A core technical team comprised of experienced product and engineering managers should handle coordination of outsourced teams. It is a mistake to hire very technical, hands-on programmers to manage software development in this situation.
Do not rely exclusively on the project management resources within the outsourced team to guide your product to successful release. Only your employees have the proper perspective that comes from proximity to your customers to play this role.
More details about structuring your engineering organization when using outsourcing are in this previous issue of Runtime – Engineered for Outsourcing.
Define Your Software Development Methodology
As the process and procedures you need to develop your product. It should include the details of source code control and defect tracking as well as acceptance tests and release criteria.
Will you use pair programming and test-driven development? Do you prefer Agile Development methods over the Rational Unified Process? Are you using Microsoft technology and following a Model-Driven Architecture approach?
There is no one right answer for each product or software development project you might carry out, outsourced or not. But you should consider these approaches and whether you want to adopt a label for the software development methodology you choose.
Personally, I like Agile Development methods because of the commitment to frequentproduct builds and releases. It is a great way to track the progress of your product development and make corrections if results veer off of plan, and as the plan inevitably changes.
Whatever software development methodology you choose you must make sure the outsourced team understands your process. It should be used as an important criteria for choosing a team to begin with.
In summary, there are multiple things you should do to prepare for outsourced software development. Many outsourced teams will help you with the technical details. A company like Accelerance also helps with business issues. Use an experienced consultant or consulting service like Accelerance to help you get a good start with outsourcing
Andy Hilliard
As CEO, Andy leads and advocates for the globalization and collaboration of great software teams with companies in search of talent, innovation and a globally-distributed extension of their engineering function and culture. Andy founded the ground-breaking nearshore software development services company, Isthmus Costa...
Recently Published Articles
View All PostsSubscribe to email updates
Stay up-to-date on what's happening at this blog and get additional content about the benefits of subscribing.