Five Pitfalls To Avoid When Outsourcing Software Development

The IT outsourcing industry garnered $62 billion in revenue in 2018 and has become a truly global business; you’re just as likely to outsource work to Ukraine or Canada as you are to India or Brazil. It’s not just helpful for startups and non-tech firms. Major companies like Slack, GitHub, Alibaba, and WhatsApp, have successfully leveraged the benefits of outsourcing development in their initial days to reach their current heights of success.

Outsourcing has the potential to improve your business’ efficiency, reduce the time to market of your application, and result in significant cost-savings, but only if it is done correctly. There are significant risks involved in outsourcing development as well. These can negatively affect your business’ bottom line and cause projects to come crashing down before you get a chance to launch.

Crafting an effective outsourcing strategy

While outsourcing development has its set of benefits, it can quickly turn out to be detrimental to the business goals if it isn’t set up and managed in an organized manner. Let’s be real, finding a trustworthy development company to partner with you in your development efforts can be a tricky task. The task becomes even more intricate if the company outsourcing development is not a tech company. 

Having worked extensively with outsourcing firms in the past and subsequently co-founding a custom software development company, here’s my guide to the dos and don’ts of outsourcing software development.

Common pitfalls in outsourcing development and how to avoid them

1. Communication barriers

The biggest benefit of outsourcing development, gaining access to a global pool of talent, also creates one of the major pitfalls — issues in communication. You’ll need to overcome different time zones, languages, and cultural conventions. Establishing regular channels of communication with the outsourced team becomes of crucial importance for ensuring project success. 

Vivek Kumar, the founder and CEO of Qlicket, experienced first hand the downsides of poor communication channels when he outsourced the development of his employee feedback kiosk. He mentioned in a recent survey that the developers stopped responding one day out of the blue and failed to deliver the assignment. “Whether it comes in the form of relocating a founder, holding frequent check-in calls, or some other method, transparency and frequent communications are necessities for small business outsourcing”, he told Clutch.co. He now firmly believes in the importance of frequently communicating and engaging with remote contractors.

Effective communication is a skill, while English is merely a language. When communicating with outsourced developers, comprehension of the project requirements and clarity on the deliverables are the most important factors.

Use of collaboration tools, like Jira and Asana, regular engagement with the remote team via video or audio communication, and stand-up meetings at regular intervals, are best practices for establishing communication channels with the outsourced development team. 

2. Failure in understanding the scope of the project

Before outsourcing development to a remote team, clarity on the requirements and deliverables that you expect, expected timeline to deliver, and overall scope of the project, is essential for successful outsourcing. 

Failure to communicate these details may result in scope creep and misalignment on the product vision. Without resolving these issues, the software engineers will continue working in silos and there will be a widening gap between your expectations and the actual deliverables.

The groundwork has to be established by you and the features that you want to be incorporated in the app need to be clearly documented. A software requirements specification(SRS) document can be an excellent starting point that gives the development team clear insights into the requirements. 

For non-tech companies, drafting this kind of document can seem daunting. I recommend using an SRS template which can help with the documentation process. 

The SRS document helps you organize the essential project requirements you want the outsourced development team to be aware of when they start. The dev team then does their own work adding further detailing on it. This collaboration allows both sides to build a common plan, a shared blueprint that is established before any actual production work begins. 

For example, if the application to be developed needs a signup page, the initial SRS document will only list out the signup options that need to be incorporated. Through collaboration with your software vendor, it would be wise to then add additional detail: for example to specify the functional specifications for each element on the signup page, the validation checks that need to be in place, and a list of possible scenarios that need to be covered. 

Clarity in documentation is the first step in ensuring that your expectations and the deliverables that the outsourced company provides are in sync with each other. 

3. Code quality challenges

Determining whether the outsourced development team is adhering to the quality standards while coding your application is a challenge that becomes amplified when you work for or run a non-tech firm without significant coding expertise. Code quality is an ambiguous term because there are arguably no strict definitions for high quality and low-quality code. 

Code quality is a collection of attributes that need to be communicated with the outsourced development team. In my experience, good code needs to have two key qualities: clarity and maintainability. 

Well-documented and well-tested code that follows the formatting best practices and coding conventions of the programming language the application is being written in is crucial for long-term success and bug-free execution (or as close to bug-free as anyone can reasonably expect. You can’t squash em’ all.)

Maintaining code quality when outsourcing development to offshore teams requires communication of expectations, laying down the quality benchmarks in advance, and regular briefings with the team to stay on top of the development efforts. 

The team that you are outsourcing to should have checks in place to ensure consistency in code quality. Before you sign on a firm, ask if they take measures like code review (both peer-to-peer and with management), unit testing, as well as functional testing. These precautions will help ensure they have developed a robust application before releasing it to you. 

An established quality assurance process with thorough application testing — including regression testing whenever any changes are made to the code and use of project management tools for logging of issues and management of backlogs — are some of the basics I recommend you look for when choosing where to outsource your work.   

4. Ambiguity of stakeholders

Lack of project ownership is one of the biggest downsides of outsourcing. If the outsourcing partner that you pick employs programmers on a contractual basis and not full time, the actual project ownership becomes dicey. Back-and-forth of resources on your project can result in inconsistency on the deliverables, because there is no project leader or consistent team who is accountable for the work and present throughout the entire process.

When outsourcing development of a software project, make sure you understand who will be working on it and try to ensure that at least a few of the project managers stay consistent throughout the entire process. These are the folks who you can hold accountable, and who should be present on email threads, video calls, and other regular check-ins. 

I find it’s very helpful to have a business analyst or project manager as a key stakeholder on the team. This person can act as a facilitator between you and the developers, documenting the functional specifications and breaking down the requirements to the developers.

A developer who doesn’t just write the code but is also invested in providing a stellar user experience to your customers is another asset you should look for when selecting an outsourcing partner. Finding a company who can become potential stakeholders in your project and who are committed to finding the right solutions rather than implementing quick fixes is key to successful outsourcing. 

5. Loopholes when signing the contract

In the early days of a startup, handing out huge amounts of money for legal fees doesn’t seem like a viable option. But a loosely framed contract, or one that leans in favor of the contractor, may result in loopholes which can be exploited by the outsourcing company and result in severe monetary losses. 

Yoav Achiam, the co-founder of GuardianEYE, knows the price of a poorly written outsourcing contract. In an article on tips for signing an outsourcing contract, he talks about all that went wrong when he signed a contract with the outsourcing company himself. “The contract did not include a time commitment, layout of the assigned manpower, penalties if deadlines were not met, nor positive reinforcement if development went faster than expected,” he wrote. It’s no surprise that things soon went downhill from there.

The age-old saying “Get it in writingis vital in software development as well. A properly drafted contract acts as a roadmap for the outsourced contractors to follow and safeguards you from bearing the brunt of losses in case things take a wrong turn.  

Best practices when signing an outsourcing contract

Drafting a tight contract that is free from any legal loopholes helps ensure that you do not miss out on any of the vital issues during application development. Here are the things that you should be keeping in mind when drafting a contract with the outsourcing agency. 

  • Outline the deliverables as well as the timeframes: The contract needs to clearly state the deliverables expected in the form of feature lists or user stories and the estimated timeline that the contractor would be able to complete work. An outsourcing agency that follows Agile development methodology and breaks down the requirements into sprints can help give an accurate picture of the development progress. 
  • Feature-based contacts over time-based ones: Instead of contracts that outline time-based development and deployment, having a feature-based contract that prioritizes a well-written and thoroughly tested application over one in which the developers are motivated to simply adhere to the timelines. Dividing the deliverables into task level sprints helps to ensure ownership and accountability in the company you are outsourcing to. 
  • Milestone based payments: Breaking down the project into distinct milestones and defining the payment schedule in accordance with the achievement of these milestones simplifies the payment structure. Plan regular follow-ups for achieving milestones and schedule stand up meetings with the team. Having a milestone-based payment schedule brings a lot of clarity to the contract and eases the resolution of any conflicts in payment. 
  • Instilling code guarantees: Application acceptance without code guarantee is a big no-no. The contract that you sign that should specify that the code you receive is free of any malware and specify the acceptance testing period. A period of 5-10 days is a reasonable timeframe within which any bugs found within the application need to be fixed at the contractor’s expense. The contract should also specify how the web hosting or app store submissions would be managed
  • Maintenance support contracts: Any outsourcing company worth their salt would not leave you hanging in the air without any support contracts. A maintenance support contract should clearly state the duration for which the team will provide support on software they built and delivered. Specifying support in the project also results in an enhanced sense of ownership for the developers working on building your application. They know sloppy code will mean more work for them down the road. 
  • Intellectual property rights: As a client, you have the complete rights to your project but make sure you have this in writing by including the intellectual property rights clause in the contract. This will save you from some big headaches if any rights infringement issues pop up in the future. It would also prevent the contractor from reusing the code written for your application when working for a possible competitor in the future. 
  • Confidentiality agreement: A confidentiality agreement is a non-disclosure clause that ensures the secrecy of the proprietary information that you share with the contractors. It ensures that your app idea cannot be copied or shared with others. Non-disclosure and confidentiality agreements should be signed not just with the outsourcing agency but with individual developers. That offers some protection against coders who leave the outsourcing firm and work on your business idea themselves. 
  • Indemnity clauses: Indemnity clauses are the legal provisions included within the contract that addresses the risk responsibility distribution between you and the outsourcing agency. It states who would bear the legal fees and pay for any lawsuits that crop up in the application being developed. 
  • Termination clause: While you hope that things should go smoothly, it is always advisable to be prepared for worst-case scenarios. Make sure you include a termination clause in your contract that clearly states the course of action that will be taken when things go south and project fails to reach completion. 
  • Jurisdiction for resolution of issues: Outsourcing has made software development a truly global process. Deciding the jurisdiction in which any dispute that arises would get resolved and mentioning it in the contract is necessary to determine the laws under which the contract is covered.
Rahul Varshneya is the co-founder and President of Arkenea. Rahul has been featured as a technology thought leader in numerous media channels such as Bloomberg TV, Forbes, HuffPost, Inc, among others.

Related Articles

Comments

  1. A big one that I would add is: Have someone technical on your team.
    Without them, you have no way to judge if what the outsourcers are telling you is reasonable, and no good way to QA their work.

  2. Jaap Coetzer says:

    Thanks Rahul!
    We are looking to get into the game as a software development company. This article will help do the groundwork for presenting to potential clients to gain some trust and understanding.

  3. Regarding the outsourcing contract point “Intellectual property rights”, I would love to see more open contracts in the future.

    Ofcourse, noone wants a whole application idea to be delivered to a different customer. However, software development comes with a lot of potentially reusable code and a contract that allows this code to be reused in unrelated projects would benefit all involved parties in the long term.

    Personally, I only coded very few little projects on contract. It was software for internal usage within a company, which is probably not comparable to a product that waits to be sold a few thousand times. I always specified, that the client only gets non-exclusive unrestricted usage rights on the delivered code, so I could incorporate previously written code into other projects. As soon as this is made explicit, there is always room for refined conditions that protect the clients idea without wasting development resources in future projects.

  4. Good Article. I would add “Learn the culture of the country you are outsourcing too, and if you’re serious about this, learn the language too”

    Everyone in the world gets all the same things done, but they do it in different ways. What’s rude in one culture, is perfectly acceptable in another. You need to visit them, in country, and spend time there. Learn how things work. Understand how they communicate both verbally and non verbally.

    Contracts with developers in other countries mean nothing. Your success will be a function of the depth of the relationships you create, and the level of trust you and the outsourcers have in each other.

    Outsourcing is very, very hard. I started with it in 1995, failed many times, and now run a successful software development business with developers in three countries.

  5. Luke McGregor says:

    As someone in the software services industry I think that this is completely the wrong way to go when approaching a services vendor. We have long known in the software industry lengthy specs and rigid timelines simply do not work. In fact in my experience they are one of the biggest indicators to failed projects. Technical or not no one truely understands a project and its requirements until it has been seen, played with and shown to real users.

    So whats a better way to engage?

    – Build in small autonomous chunks, and deliver working software quickly. If you don’t see something running and solving a small problem in the first few weeks something is probably wrong.
    – Try and get the risky bits solved sooner, what small steps can you take to answer risk today, or in the next week.
    – Be involved in the build process, evaluate and change direction as you go. You want to know ASAP if the project is going in the wrong direction and correct it. The best way to know is to look at working software, and test it vs your users.
    – If the vendor isn’t delivering what you want, find this out really early and work to resolve it either with the vendor or by finding a new one. Moving codebases (especially large or poor quality ones) between vendors is really expensive, so you want to avoid this if possible.
    – You tend to get what you pay for, be wary of companies that estimate low. Projects estimated low often end up costing much more. These vendors tend to resolve price overruns in fixed price work by frequent change requests or poor quality work.
    – Fixed price work tends to end by delivering a product which may meet some interpretation of the spec but doesn’t meet the actual underlying need the software was built for. The only comprehensive spec is working software.

    1. hear! hear!

  6. Totally agree, we do and have outsourced some of our work but we spend considerable time up front to “vet” the crew before assigning them any work, we have well established boundaries and processes built over time and past mistakes. This ensures everyone is on a level playing field of understanding.

    One way we’re combatting “scope creep” is our new flat-rate unlimited service, a reduced scope development serviced aimed at G Suite users. We can build almost anything in Apps Script and there is no time frame or delivery requirements, we just build everything you need month in month out, and as soon as you want to stop you can. It’s working really well and now there isn’t any expectation of timeframes for features (as long as we’re still delivering value) and each month they pay the same amount.

    Doesn’t matter how well you prepare, there is ALWAYS scope creep in a project either it creeps in and you let it or have to manage it which is a pain.

    1. What is “G Suite” and “Apps Script”?

      1. G Suite is Google Suite – Google products for business.

  7. Philippe Futureboy says:

    Great article Adrian, thanks for sharing your thoughts on the subject!
    My sole question would be, do you have a template contract that you could share with us that covers sensible defaults for all the items listed above?

    Thanks a lot!

  8. Bruno Juchli says:

    I agree with Luke McGregor and I would like to add a few points.

    Create value as soon as possible. If you fail to create a positive ROI, move on.
    As time goes by, continued work on the software will inevitably get more expensive. In the beginning it’s easy to add a new feature. Years later it’ll cost tenfolds more. If software development is too expensive in the beginning, it’ll only get worse. Consider this an incurable illness.
    If you’re really convinced of your business idea, you might try another contractor/team. Otherwise, just write off your business idea as “not worth it”.

    Legal:
    Going to court probably won’t cover your losses, it’ll probably even have negative ROI. Especially if it’s an international deal.
    So don’t focus on legal loopholes, but make sure everyone understands the expectations. Do write a contract to put them in writing (human memory = unreliable), use a simple and understandable language. Go through it with the contractor. If there’s questions adapt the contract to make it more understandable. Probably no need to waste money on lawyers (unless you have an intra-country contract and a quick legal system with low court fees. Haven’t heard of country that matches this. Have you?).

    You may want to invest in the technical expertise to judge code quality. If you do, ensure that the technical expertise comes from an impartial party. It’s no good to hire a consultant from a big company just to have them bad-mouth the contractors work because they’d like all of the cake for themselves (seen that happening, but only take it as anecdotal evidence).

  9. I would also like to see an example/template contract. Great article thanks for sharing your experiences!

  10. Good article and lots of good comments.
    What I have seen in outsourcing that goes badliy is that the end-user looses control to the point that less that ideal things are being done, or they are getting mediocre service, but under the contracts they have no way to enforce the things to be done well.

    In times past, there would have been a client IT person (a mid-manager) with the company’s best interests in mind and directly responsilble to his or her employer, which is often lost when IT efforts are outsourced and the mid-manager postion is eliminated.

    I personally have spent and charged the client for my time working arounf the contraint that we need to accomplish some goal, but need to do a lot of extra work since the easy way would involve asking the outsource folks to do something. Not that they are incompetent, just that (by contract) they can, and do, takes weeks to do it. (and when it’s not right, it’s weeks more to fix it)

  11. The Geektime link above shows an HTTP 503 error in my browser.

  12. 0. Communicate with internal development staff.

    Nothing is more demoralizing to your internal people than seeing work being outsourced.

    Make sure your internal staff is not becoming support only as new work is outsourced. Usually because the internal staff is too busy, or they “know the system”.

    Consider outsourcing the support and routine maintenance work. Hopefully you are paying your internal people because of their big brains, and want to utilize them in the best fashion

    Make sure our internal stuff is truly busy, not “make work” etc.

    1. Luke McGregor says:

      Yeah I totally agree communication with internal staff is really important. I’ve been on both ends of this issue.

      My advice is to assimilate contractors into your teams as much as possible and make them part of ‘us’. This will likely get their best work and also make you feel good about the contributions you make as a collective. I realise some are quite resistant to this and if so I’d find someone else (lone wolves are bad news in software).

      As a contractor tact is incredibly important here, good ideas are great but listening and understanding the bigger picture is better by far.

      I will however disagree on the maintenance part of this, managing existing software is complicated and takes care and experience with the code. Someone who has never worked on it before and who is likely transient is probably the worst person to make a fix that doesn’t cause another issue.

      I’d also say one of the most important principals I go by as a dev is where possible clean up your own mess. This makes you a better dev.

  13. Cory Wandling says:

    What I read here was a waterfall model to project development albeit outsourced. This model is doomed to failure. Why not apply agile principles to outsourced software development?

    Two week sprints. Stories with points. Spring reviews…

  14. JustRandomGuy says:

    When they provide a detailed document and in the middle of the coding they change everything…….

    First, they want to build a bridge over a river but out of sudden you will be building an swimming pool in the desert not knowing where the hell you gonna get those water from

  15. I think, the traditional reasons for offshore software development outsourcing are also changing with time. Similarly, the reasons to outsource. Companies now look to outsource a software to find talent and technical skills that they don’t get internally.

    One of the biggest barrier to success has to be unrealistic expectations from the clients side. Succeeding that, there is always the problem with ever-changing requirement spec. To mitigate these, both the client and the vendor must have end-to-end discussions of the project flow, starting from plan all the way to testing. Also, once the spec is made, freeze it and treat it like a bible. Any major changes to the spec means additional money and time.

  16. Disaster recovery is also one of the important elements of outsourcing and should be considered before offload work to the third party be it nearshore or offshore.

  17. Outsourcing just because labour is cheap in say (India or Ukraine) isn’t correct and shouldn’t be encouraged. If people get the hint that they are being used to prosper or nourish the client’s company/country it isn’t going to be good quality work. I would suggest to outsource because there is incredible, innovative and useful, unique, specialized talent in the countries outsourced to and give them their due credit (intellectual property, patents, etc) in their own country.

  18. Let’s try thinking of a dedicated model as not fixed-price contract but outstaff team, that is a part of the client’s company at a time. Client hires already formed a qualified team of IT professionals (developers, PM, QA, designer) that will concentrate only on his business tasks and goals, share client’s company vision. Outsource company set everything up, scale the team according to client’s requirements, solve many software development challenges. At the same time, the client can work within the project coordination and has full management control over the team.

    At least, this is what it looks like for DevCom customers. We use a custom agile development approach that is designed to put the project in control. It reduces your risk, increases transparency between the teams, and gives you predictable project velocity. We both agree on the workload and project requirements for a specified amount of time.

  19. Outsourcing software development is really tricky. I support the information mentioned in the blog post. Very helpful information. Great job!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.