Development Partner Due Diligence

Recently, over tea, I was asked about offshore partners.  During the course of the conversation, I shared my thoughts about selecting a partner.  While not an exhaustive list, nor in a particular order, here are some thoughts I believe represent significant consideration.

Demonstrated technical competence

In what technologies does the partner claim expertise?  Regardless of whether you have a technical stack in mind or are deferring to the partner, you want confidence the partner has skill and competence. 

The strongest evidence is successful completion of projects using the proposed technologies.  Your partner ought to provide examples of other projects, including how the technologies were used, the extent to which they were used, and the results.  You want to know the projects were roughly comparable in terms of complexity (scope and team size).  If not, then you want a clear picture of how the partner can scale their experience to meet the demands of your needs.

Second, ask for corporate credentials or relationships that indicate expertise with the given technologies.  For example, if the partner claims extensive .NET experience, ask them to elaborate on their relationship with Microsoft.  I'm not talking about getting a certification for buying a bunch of Microsoft stuff.  I'm talking about actually engaging the Microsoft developer tools and technology program teams. Have they participated in any Microsoft ISV programs?  Have they been in a TAP? While not perfect, this can give you a sense that they have invested additional effort in mastering one or more technologies.

As a concrete example, a partner I work with has the largest absolute (and as a percentage of staff) number of HL7 certified developers on staff of any company I know on the planet.  This is a strong signal of their deep organizational commitment to healthcare interoperability.

Reference customers

Your partner should have a set of customers willing to talk to you.  I like to ask for 5-6 customers.  Some in related fields and some not.  Then I pick some (or all) and call them.  Here are some of the questions I typically explore:

• How does the partner handle the contracting process?  What about changes? I want to know if the contractor views this as a transaction or a relationship.
• Are the people on the team the same as the people that were introduced during the sales process?  I want to know if I can trust the partner, or is this going to be bait-and-switch.
• How is the quality of the deliverables (not just the software)? How are quality problems addressed?  I want to know if the partner takes pride in what they produce.
• How is the interaction with the partner's leadership team?  How would you describe their character?  Organizations take on the characteristics of their leaders.
• If you have visited their location, describe the physical environment (including hardware and equipment they have) and work conditions.  Is it a sweat shop or do the employees appear well cared for?  This impacts turnover, and consequently, the overall productivity of the team.
• Have you awarded the partner additional business since you begin the relationship with them?  Yes or no, why?  You can finesse the other answers, but where you put your money says a lot.
• If possible, describe briefly your project.  Ask the reference if they would recommend the partner based on your description.  Arguably, it might be little to go on, but you would be surprised.  You may describe a highly technical research project and find that the partner is better suited at a well defined line of business application.

The team

Ask for resumes or biographies of the key team leaders that will be assigned to your project.  Don't accept "representative" overviews.  Get the details of the specific people that will be assigned.  And be sure to interview them to verify their credentials and background.  You should treat these key leaders no differently than if you were going to hire them onto your team directly - because that is what you are doing.

In addition to the team itself, ask about their training program.  Elements you should look for include:

• New hire orientation programs
• Domain specific training (e.g, Healthcare, Banking, etc.)
• Function specific ladders with associated expected skills (e.g., Junior Developer through to Developer Team Lead)
• If appropriate, language and communication skills training

The best partners I've seen (and therefore, do business with) are able to tell me, "When you hire a Senior Java developer, you are assured they have these skills, each at this level, and will receive the following training in the coming year."

Again, this is not an exhaustive list.  But it should get you thinking about more than just cost rates.  Leave some of your questions or other items as comments.  I'd love to hear what you think.

Winning with offshore

I recently had an opportunity to speak about being successful with offshore partners. Having worked with several partners in my career, I was fortunate to be able to have some experiences to draw on. There were three themes I eventually landed on:

• People versus resources
• Relationships versus transactions
• Collaboration versus isolation
  

People versus Resources
The language we use is a reflection of our thoughts and shapes future thoughts. So here's a simple question: Do you report the number of people or the number of resources you have offshore? You see, resources are interchangeable and anonymous. People are flesh and blood.

Several years ago, my former manager began penalizing our team every time we referenced our partner either by their country ("I don't know how that happened, Antarctica tested that feature") or by their company name ("I can't believe Igloo Offshore would have coded it that way!"). She forced us each to examine the way we viewed them. Were they simply a group of disposable parts? Or were they committed and loyal people, just like us.

And guess what? Things changed. Professional respect across the two teams emerged. As people visited (every try to buy a round trip air ticket for a 'resource'?) back and forth, we began to learn names of our counterparts. Phone calls, instant messaging, and web cams became the preferred method of communicating.

More importantly, we built trust. My manager was on to something those years ago. She knew that when a person has a name, they are real.

Relationships versus Transactions
Once we began to see our partner as a collection of people, this next distinction sort of fell into place. You can't have a relationship with a resource. You go to an ATM and withdraw money from a machine, not from Bob. Once we began to know each other as people, we evolved to a new relationship. We became interested in career development on both sides. We deepened our relationships with their families during visits.

OK, you might be asking what this has to do with costs and productivity. And that, I assure you, is my point. Sure, you can get what you negotiate for in terms of transactions (do project X by March for Y dollars.) But our product isn't piece meal. It is a living, breathing product that evolves over time. I can't afford to have people coming on and off my project, all the while keeping the "resource count" level.

That's the punch line.

Our relationships are the bond that allows for continuity. We have wonderfully low turnover and deep experience with our offshore team. I fundamentally believe that is a result of the relationships among people from both sides. It's more than just a cool project on the resume. It about being on a world-class team with people you care about.

Collaboration versus Isolation
This too is a natural extension of the previous point. We don't distinguish between whether a person is here or there, with the exception of a few key customer facing positions. In other words, if a test lead is better situated there, then so be it.

We often have feature (scrum) teams comprised of people from both us and our partner. And because of the strong relationship, they work well together. Not only in a "feel good" sense, but in a hard core results delivered sense. People work hard for each other because they know each other. They have shared a meal together. They know about each other's families and celebrations. They have worked side by side together.

So when we need that push, we get much more than compliance because we are the customer. We get the energy, the passion, and the loyalty that is the difference in being able to deliver great software.

Ironically, these themes are exactly the way you should be treating your onshore team members already. Ultimately, it's about being able to look across your two organizations and see one team.