This is our final installment in the “Rightsourcing” series. At this point you have done your due diligence in research. You have a timeline, a roadmap, and a budget. With a solid endorsement from management secured, it’s time to Rightsource a partner.
Although you’re likely eager to put the decision behind you and get the project launched or augmented, now is the time to carefully screen your options. Partnering with a sub-optimal provider will cost you far more in headaches, rework, and delays than a more deliberate approach. Furthermore, it will likely stigmatize the future use of outsourcing in your organization.
1. CONSTRUCT A COMPETITIVE LANDSCAPE, THEN FILTER IT
Share your tentative IT augmentation requirements with a list of potential partners to initiate conversations. Even at this initial contact, pay attention to relative timeliness, ability to listen, attention to detail, and overall tone—all of which will ultimately build confidence in the partner’s integrity. Be sure to ask challenging questions and validate your impressions with multiple client references. Be clear with prospective partners and assume nothing.
Create a database or spreadsheet to capture subsequent, more-detailed follow-up about rates, retention levels, and client references. Trust your judgment and screen out providers as soon as any problematic flags appear.
2. APPLY A RECRUITER’S MINDSET TO THE OUTSOURCER’S TALENT POOL
An outsourcing partner is more than just another external contractor. It is (or should be) a full partner whose remote workforce will play on the same field as yours, interacting and contributing daily. The offsite engineers must be able to win the home team’s respect and trust. If you condescend to the remote developers in any way, you’ll ultimately undermine the joint team’s effectiveness, so don’t compromise your standards.
Determine how many client teams the outsourcer currently supports. Is it spread too thin? How large is a typical team, and what range of clients (scale, industry, location, etc.) does the outsourcer support? Has it supported multiple projects over time with long-term customers? Based on experience, are there projects or clients it does not engage?
Interview not just project managers and intermediaries but also some of the engineers who would be dedicated to your project. Assess their technical chops—providing a coding challenge is often worthwhile—and their communications skills. Understand what hiring criteria and priorities the outsourcer employs to select its engineers and whether that filtering process yields the kind of contractors you seek.
3. ASSESS “SOFT” VARIABLES
If your budget permits, try to arrange visits to each finalist’s engineering location or do your best with video calls. In addition to conducting face-to-face interviews, a visit is your opportunity to get a feel for the vendor’s workplace culture and values, and whether they will align with yours. Is their style formal or casual? Hierarchical or flat? Rigid or flexible? Opaque or transparent?
This “vibe” can be difficult to define, but if you find yourself comfortable there, it’s likely a good fit. And once the project is underway, periodic visits in both directions help sustain personal relationships within the team.
At the individual-contributor level, get a sense of temperament, enthusiasm, and general curiosity about your project. Learn about his or her other, similar projects. If specific domain, device, or framework familiarity is important to your project, ask about that too.
4. CONFIRM THE VENDOR’S SOFTWARE DEVELOPMENT METHODOLOGY
Most contemporary software development relies on some flavor of Agile, and it’s important to drill down on this with the candidate vendors to ensure compatibility. What Scrum ceremonies or Kanban cycles do they endorse? How do they measure progress? How long are time-boxed sprints? What delivery model do they follow? How do they interface with DevOps?
Because they work with a variety of clients, most outsourcers can flexibly adapt to your current procedures. Stay open, however, to the possibility that their field-tested implementation of Agile might be more productive than yours, and that you can improve by adopting all or part of their approach.
