8 Pitfalls To Avoid When Outsourcing Your Software Development
Misinterpretation of requirements, loss of institutional knowledge, and more
Having been on both the client and service provider side, I know what each party wants to get out of the relationship — and it can be at odds with each other.
I’ve seen the good, the bad, and the ugly. This includes ending a contract early to build a product that successfully got acquired.
If you are considering or are currently working with an outsourced team, this article will help you avoid common mistakes from kickoff to the completion of the project.
1. Getting Subpar Talent
To increase their margins, teams may forgo more capable engineers who ask for higher pay. Some even have the same resource working on multiple projects behind the scenes — even if you are paying for that person full time.
Most agencies have a sales or account manager to negotiate the contracts. Think of tactics you can use to increase their “skin in the game.” Are they looking to increase their portfolios in certain industries or geographic locations? Do they want to include you as a case study to get more clients like you?
2. Contractors Are Not As Committed as Your Employees
Once the resources are assigned to you, take the time to understand what drives them to do their best work. Remember that their real boss is the agency. They will likely put their direct employer’s interest over yours. You can appeal to extrinsic motivations, such as putting in a good word to their managers.
What I found more effective is to make them feel that they are growing their career. I made it clear that I want them to learn the skills that will make them successful when working on any client’s project.
One example is coaching my offshore team on how to write better requirement docs. After noticing all kinds of grammatical errors, I recommended using Grammarly (a tool that scans for grammatical error). It turns out this tool is not known in the team member’s area. This helps him improve his English to better work with other clients in America.
3. Language Barrier
Even if their accents are hard to understand, they should be able to write out what they are thinking. If their emails are full of typos and grammatical errors, reading the requirements they write will be even more challenging. Raise the bar if they work in a different time zone that requires frequent asynchronous communication.
The project manager who interphases between you and the developers must be a clear writer. If that person doesn’t meet your expectations, request to have a different person manage your project. You don’t want to spend additional weeks onboarding a new person halfway through the project.
4. Broken Communication Process
You will have lots of feedback after seeing the designs and demos of what was built. Is the outsource team keeping track of them so the engineers are not wasting time working on the wrong specs and accumulating critical bugs?
Here are examples of how I learned it the hard way:
- In the demos, I requested several critical changes to be included in the next build. It might be because of the language barrier, but only half of them got captured and worked on. What I should have done was ask the team to repeat the changes they heard — not only to make sure nothing was missed but also so I could rank them by importance.
- I sent my design feedback via email, but it got lost in the designer’s inbox. The wrong designs trickled down to the engineers. Knowing the designers would give the engineers a walkthrough before building, I should have left my feedback as comments directly in the design tool. So when they opened the design tool, they would have caught the unread comments right before the wrong information got passed on.
The best process is the one that gets the receiver to take the actions you want them to do (which can vary by role). Learn from the miscommunications — especially at the start of the project. This will save you a lot of unnecessary rework down the road.
5. Misinterpretation of Requirements
If the contractors are rewriting a legacy product with complex logic accumulated over the years, have someone with institutional knowledge demo how the feature works. This will save them time from reading pages of requirement docs that will easily be misunderstood.
If there isn’t an existing product or prototype the outsource team can “play around” with, the requirements you sent to the project manager are up for interpretation. When I was working at an agency, I saw project managers incorrectly explaining what the clients wanted and leading the entire team down the wrong path.
Avoid playing telephone. Ask to include the team members who are directly involved with building the product in requirement-gathering meetings. Some dev shops have strict rules that only project managers can communicate directly to the client. They fear that the engineers will say the “wrong” thing.
However, relying on the project managers to do the correct translation is risky and slows down the feedback loop. The team that is executing the details should be able to ask you for clarifications and hear the answers directly from you. The designers may want to know how quickly one screen should flow to the other. The engineers may ask you if rounding numbers would lead to incorrect calculations.
6. Finding Out What Went Wrong Last Minute
Some offshore teams come from cultures that are afraid of disappointing or saying no to authority. To keep you, the client, happy, the natural reaction is to shove bad news under the rug. They will attempt to fix issues until the very last minute. By the time you find out, it is too late.
You will hear “excuses” when probing why they didn’t hit the deadline. Instead, ask when they start noticing the red flags. The goal is to proactively avoid surprises so you have time to change course or come up with plan B.
Create a safe space to share project risks. I encourage the outsource team to speak up when these situations happen:
- If the scope is not achievable within a given timeline, tell me early. That way, we can work to better prioritize and reduce the scope.
- If the scope is not clear, do not fear that I will take it defensively. Ask clarifying questions rather than assuming so we can build it right the first time.
I coached my fellow project managers to do the same when I was at an agency, diplomatically telling the client that they contributed to the problem so they don’t think that you mismanaged the project. This false impression would make the clients want to end the contract early.
7. Poor Quality That Doesn’t Scale
Most contractors’ knee-jerk reaction is to ship features as quickly as possible so they can deliver on time and get paid. They will take the “easy way” out and won’t consider quality or scalability.
This will become an issue for a mature product that has a growing number of users. You need to change the outsource team’s mindset by setting measurable goals. For example, test coverage to reduce the number of recurring bugs and critical incidents that occurred over time.
For example, our application became sluggish and buggy over time. Nothing improved for months until I showed them the page load time increasing since they joined and the number of recurring bugs that users have reported. I escalated to their managers because I know they tend to look at the story points achieved (which are no longer how I want to measure the contribution of their team). This creates the same mandate from their top-down.
The other way to ensure quality standards is to have in-house team work on core foundations while having the outsource team do the “fine-tuning.”
A building won’t be stable if the foundations or pillars are not solid. Even if the paint is patchy, the cost of repainting is low. Taking this analogy further, have the in-house team work on major architectural changes that other features depend on. The outsource team can work on painting the walls (e.g. bug fixes and enhancements) so they can ramp up on what the in-house team has built while delivering immediate value.
This is even more important if your project is a re-write. There will be dependencies with the old system, such as migrating or syncing data to the new technologies. You don’t want to leave the outsource team that doesn’t understand the existing systems and users to make all the architectural decisions.
8. Loss of Institutional Knowledge
When you already have a team of in-house developers, set checkpoints to review the outsource team’s work throughout the development cycle. Before building, sign off on the documents that outline the technical approach and rationale behind it.
The in-house team should code review critical tasks to catch any deviation from the original plan. Setting up these routines reduces the risk of widening the knowledge gaps and saves time from playing catch-up.
What if you are building an MVP and haven’t hired an in-house team?
Find someone you trust with the technical knowledge to review the outsource team’s work — especially for complex and core features.
When the outsourced team hands over the code, ask your trusted advisor to run the code from scratch. This ensures they didn’t miss any pieces or leave out any proprietary information. Using Ikea furniture as an analogy, you don’t want to find out parts are missing.
