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.

Big rewrites: Summing things up

My last several posts dealt with migrating technologies, people, and skills considerations. Certainly, a few posts can't do justice to something as complex as a system technology refresh.  On the other hand, there are a few principles that can be helpful guides as you navigate the the complexity.

• Iterate
  If possible, break the rewrite into smaller chunks.  Determine the smallest amount of business value you can deliver and start there.   This allows you to stay focused on software delivery fundamentals and to use the new technology in the real world.  Release management, branching and merging, and patching are just a few of the processes I've seen atrophy after years of rewriting software without a delivery.
• People
  A blended team of existing folks and new hires is desired, but comes with issues that require supportive, yet firm, management. The technology transition is going to happen - that is where you must remain firm.    It is not reasonable to expect your existing team to learn a new technology stack in the context of significant business implications.  You will have acquire skills and that will cause friction.  These new folks have to be integrated into a new, combined team.
• Skills
  The existing team members are a key to success due to expertise of the system, customers, and industry.  Your commitment to their education, skills, and to be blunt - employment, is the supportive aspect. Show them how they will participate in the transition itself, as well as their contribution in the new world after the change.  Provide them a picture of their role after the new technology is in place to assure them that they aren't helping the "new folks" build the system that is putting them out of a job.

These principles provide you a start at identifying the core issues you will face regardless of technology or industry.  For example, iteration is simple in theory.  In practice you have to address factors such as, "What is the least meaningful value I can ship to the market?", "How can I deliver 'less than everything' alongside existing software?", and "How long do I really have in the market with the existing product?"

The questions that follow from the principles are the real power.  Conversations surrounding the questions and their answers will do more to increase project success than all the project management during the project itself.  After all, if you don't have the right skills, your team is demoralized, and the project is a multi-year science project, your project status reports are going to be the least of your worries.

System migration and people: Part 2

Technologists often align themselves to the skills they possess.  You see it in job titles: Senior .NET developer; Java architect, and so on.  In the midst of a migration to a new technology stack, you are changing more than a person's business card.  You are changing who they perceive themselves to be.

This presents a fundamental challenge to large-scale technology migration. And one of the greatest ironies. 

Possession of the required new skills is the least important contribution from your existing team.  Yes - you read that right.  During this transition, what makes your existing team so valuable is not their technical skills.  So what does?

• Domain knowledge
  No matter your business, there is specialized domain knowledge.  Mine is healthcare.  That means deep understanding of patient registration, ordering medications, patient care documentation, and scores of other complex workflows.  These don't change with new technology.  Your team has spent years learning these and the interplay among them.
• Customer understanding
  Your team understands how your customers operate at the intersection of the current product and the domain.  You can't do a migration without some consideration for your customer base.  Your team has customer relationships and trust (hopefully) to increase the chances of the transition going smoothly.
• Organizational knowledge
  As I wrote last time, you may supplement your team with expertise in the new technology. These folks aren't going to have a clue about anything related to the items above.  Your team can help them navigate the challenges of finding information about the existing system and processes - or even who knows the answer in the first place.

Returning to the challenge - changing who a person perceives themselves to be.  Your goal is to shift that perception.  You have to state (and restate) that technology is fleeting - and that it can be learned.  The emphasis for the existing team is on their knowledge of domain, customer, and organization.  That can't be extinguished by Java 8, HTML 5, or any other technology.

System migration and people: Part 1

My last post discussed migrating to a new technology stack as part of extending the life of a software system.  Next, I'll explore people considerations.  The first topic is skills related to the technology stack.  My next post will discuss the role of domain experience.  Finally, I'll attempt to tie it all together with a summary post.

Chances are your current team possesses skills to evolve and maintain the existing system. Unfortunately, these may not be the technical skills needed by the new technology stack. This may be a source of fear among the team. While there are no easy solutions, here are some thoughts:

• Get expertise in the new technology stack
  The most effective way I've seen this done is to hire additional people to supplement the team.   Find people who know the new technology well and have demonstrated its use in bringing to market solutions that have some matching characteristics to your product.
  
  You need people with experience, otherwise you will end up with the old solution implemented in new technology - not at all what you intend.Your goal is to quickly apply best practices with the new technology.  Consultants have their place, but in this situation I find that nothing beats employees who are fully dedicated to the project.

• Commit to trainingFor those who want to, provide training in the new technology. It's OK if some want to stay with the older stack.  it will be around for a while and you will need to maintain it.  However, show people that you are willing to invest in their future and they will be more likely to stay with you through the transition.
  In addition to training, integrate new employees with existing teams to increase the pace of learning.  This will create one team, demonstrate by example how to apply the new tech stack, and allow new employees exposure to existing rationale, business rules, and architecture.

Understand that for some, they will equate their value to their existing skills.  My next post will address this directly.

Migrating technology

I've been thinking a lot about extending the life of a software system.   There are several hard problems to solve.  The first problem I want to discuss is migrating to a new technology stack.  I'm skipping the discussions that take place before the decision to transition to a different technical stack are made.  Whether that decision is good or bad, if it has been made it is your job to get it done.

Consideration #0 - Don't do it all at once

Big rewrites are very likely to fail. So don't try them.  Learn from our collective Agile experience and establish a backlog for your migration.  You will learn a lot from planning the backlog, such as business and sales pain points, architecture dependencies, and areas that don't require immediate attention.  This gives you the advantage of putting new technology into the market faster, further accelerating your learning feedback cycle.

Consideration #1 - Build new features in the new technical stack

While straightforward to understand, this is perhaps the most difficult to implement.  Your end user work flows have to be (relatively) seamless.  The existing system was designed to support a collection of end user goals and workflows.  If the new feature is presented is a jarring manner, you risk putting your users off.

A few years back, my team was challenged to move from Delphi to .NET.  We found ways to render .NET screens inside Delphi containers.  Although we used different component libraries, an end user had to be extremely astute to notice subtle control rendering variations.  A more recent experience involving more disparate technologies has required some visual redesign of the existing application to reduce the perception gap.

Regardless of your technologies, you have to make the user experience transition as seamless as possible.  

Consideration #2 - Rewrite parts of the existing system when appropriate

As your existing system requires modifications, determine if the feature to modify is a good candidate for being rewritten.  Again going back a few years, we were faced with a major overhaul to government reimbursement for Home Health services.

Instead of modifying the existing (tried and true Delphi) payment system, we left it alone.  We wrote the new billing engine in .NET.  This allowed us to guarantee no regression to existing billing and to add significant capability in the new system.

Consideration #3 - Accept that some stuff will remain around for a very long time, maybe forever

This can be hard to accept.  Engineering, and I suppose business, is about choices.  Those choices involve what you do and what you don't do.  There are parts of your system that work, are reliable, and aren't causing you lost sales.  Before you rewrite those pieces, have a compelling reason to do so.

In general, your goal is to devise a scheme to migrate to the new technology over a reasonable period of time, incrementally, with little impact to your end users.  I know this is hard.  But it is possible.  The alternative - a massive all-or-nothing rewrite - has proven again and again to lead to failure.