At SourceSeek we spend a lot of time helping clients to improve their distributed-engineering practices, and the vast majority of discussions start with the client saying that the outsourced software team “just wasn’t doing a good job.” Without a doubt, many projects go wrong because the vendor was deficient, but getting at the truth or details as to why takes some work – important work.
Management needs to understand if a vendor is really deficient or if something else is going on, and reports from the trenches can be misleading. Here are a few tips to separate myth from reality and fact from fiction.
The key question
There are a lot of terrible teams out there, and plenty of vendor side issues that can derail a project (shifting resources, bad project management, or morale, to name a few). So, it’s absolutely possible that when your team tells you that the vendor is blowing it, they’re correct. But didn’t you hire a team that seemed skilled and up to the task? Hadn’t they successfully delivered for a range of customers previously? Why would they suddenly drop the ball?
The reality is that clients suffer from most of the same issues as vendors. Things like burnout and morale inside the client team can quickly bring down a whole project, and frequently it will look like the outsourced software team’s fault when it may not be. Insiders are much more adept at internal politics, knowing what higher-ups want to hear, covering their rear-ends, and more.
So the key question is: Is it the vendor, or the internal team? You need to look and listen widely to uncover the truth.
The buck stops…
“I really trust my tech lead and he says that these guys are producing bad code and going really slow.”
Seems pretty conclusive, right? But more often than not, this same tech lead was happy with the output from the same team just a few months prior.
He’s now just making an observation that the team isn’t putting out good – or enough – code. But the concept that “they aren’t good anymore” goes beyond code output, or any other isolated factor. Let’s face it: Tech leads are just more comfortable talking about code, rather than other aspects of their jobs.
If we judge the outsourced software team simply by their productivity and quality we really can’t tell if they are ‘good’ or not. There are too many interdependencies for that, so before you terminate your team be sure to look for some common client-side issues that make vendors look bad.
Other key questions
But you can help your tech lead give you the answers you need. In most troubled projects we see, we find a weak link in the communications chain causing the majority of the issues.
Sit down with your lead and identify the points of contact and evaluate the communications in both directions. Look at communications related to requirements, quality, workflow, and testing, and ask questions like:
- Are the developers getting good instructions?
- Are questions being answered quickly?
- Are they being asked to make assumptions and doing their best to run with it?
- Are the people who are supposed to be accepting/validating the features doing a good job?
- Do the developers have an easy way to request information? Is it efficient?
- Who are the primary communicators? How is their morale?
- Do the developers feel like they are able to be critical of plans or decisions?
- Do your project managers speak highly of the developers (most of the time)? How healthy are those relationships?
- Are things like timeline and deadlines being conveyed to the team? Do they feel like they are on a wild ride?
Now a real trick here is to not make your tech lead feel as if you’re out for his scalp. It will take a lot of your management skill and some finesse to get the answers you need, so listen for clues about poor communication, unresponsive contacts, erratic communication, overworked managers who don’t have time, grudge matches, crankiness, personal issues, or anything else that is damaging the communication between your team and the contract team.
As you likely well know, the impact of a minor communication issue can be huge, even if the actual issue is small. Communication problems tend to be progressive – as in the game of Telephone, small inaccuracies get more distorted with each telling. If the miscommunication travels outside the project team, it can affect your entire organization.
When in doubt…
If you haven’t gotten the answers you need or still have doubts, arrange to speak with the vendor directly. Again, you’ll need to use finesse so your team doesn’t think you’re going behind their back.
In our experience, if you ask the IT outsourcing partner, “how can we get this engagement back on track?” they will usually give you the answer. The accuracy of that response will depend, though, on talking with someone on the vendor side who is confident and empowered enough to be honest with you, and that he feels more like a partner or confidante than a snitch.
No matter how he may feel, you’ll have a challenge here: Vendors are very uncomfortable being overly critical of a client’s team. That’s no surprise, really: No matter how often clients say they want the truth, they rarely respond well to criticism. You’ll have to listen closely.
But some responses can give you very clear insights:
- “We haven’t had as much time to clean up the code as we’d like” – Probe further for deadline pressures they feel, or if requirements are shifting (resulting in sloppy code).
- “We’re doing our best, but it’s been a very tough project” – Here’s a clue that morale may be low – possibly because the project really has been chaotic and stressful – and that some simple actions to warm up the relationship can provide an easy fix.
- “We’re proud of the code and question the validity of the complaint” – This could be code for “We’re doing a great job under the circumstances,” and you’ll need to keep digging to get the real story, even possibly bringing your tech and vendor leads together for a deeper code review.
The idea is to ask open-ended questions and follow their lead to finding out what’s on their minds. You can learn a lot about how the engagement looks and feels from the other side, and a lot of fixable issues can emerge quickly.
And the winner is…
You and your team.
Outsourcing is expensive enough without switching vendors mid-stream, so the time you invested in diagnosing the project glitches can really pay off.
Hopefully, you’ve identified a few clear issues and solutions for your outsourced software team to implement and get your project back on track. If, however, you’ve looked everywhere for the blame and it keeps falling on the vendor side, you can be confident in your decision to find a new team.
The work you’ve just done will help your project going forward, no matter the vendor, but you’ll likely need to stay in the mix so your team will start off strong with the new vendor, with things like knowledge transfer and other transitional needs. We advise clients to begin quietly planning any transition well before you announce it to the vendor.
Sometimes, you just need a great new team that will deliver.
Photos by elvissa
Dave Hecker
Latest posts by Dave Hecker (see all)
- Empowering Developers: The Software Estimation Hotseat - April 18, 2017
- Impressions from Lviv IT Arena 2016 - October 11, 2016
- Contracts with Russian Teams: Interview with Gene Taschkinov - September 30, 2016