Outsourcing Sucks!...Wait...What?...This Actually Works Great!

In one sentence, this title sums up my journey from outsourcing skeptic to believer. First, a little background on me. I am an American living on the east coast who has been in the software industry for 20 years. I have been a hands on developer, manager of dev teams, and qa teams. I have held senior management positions and built highly effective development organizations. I have worked in small, medium and large companies. Startups to big name companies. Insurance, real estate, commercial software companies. Basically I am saying I have some experience in the software field. Along the way I have had some exposure to software outsourcing. I want to share a little of my experience.

Now, if you are an American in software reading this, I have a pretty good idea of what your experience is and what you are thinking. You're thinking "Mike, outsourcing sucks. I have had horrible experiences and so has everyone I know". I hear ya. Usually it's a ton of frustration and crap quality jammed down your throat by management that THINKS it's a great deal because it seems cheaper. You and I know that's not the case in the traditional outsourcing model. Supposed cost savings are eaten up by onshore fixing of low quality work which is hard to show on a budget line item. The onshore team is frustrated. Life sucks but management thinks they are saving money. Welcome to your new life in a typical outsourcing scenario.

Now before some of you start yelling at me about how I am being unfair and not all situations are like that, I'll say that it's common enough that almost anyone in US software who has actually written code will roll their eyes when you start suggesting offshore development is a good thing. You might also be a CEO or CFO who doesn't know shit about software development. You guys are generally responsible for the poor reputation of offshore development...no offense. Not all of you. I know some great CEOs who get it.

So, why does most offshore development suck? It's quite simple. The whole typical offshore development model was built on a faulty premise. I'm not going to go into detail of what the "typical" model is. I think most of you know what I am talking about. So what is that faulty premise? "I can give you 3 software developers for the price of 1 US developer in <<insert name of low cost country>>". Or something similar. Sounds like a great deal! Sign me up! Says random CEO or CFO (Sorry for picking on you guys). Now this would work if the job entailed something like, I don't know, pushing a button a la Homer Simpson. But for those of us who know about writing software, it is as much art as it is science. And one software developer does not equal another. They are NOT widgets. The whole appeal is cost savings based on the idea that software developers are interchangeable. Plenty of companies bought into this went down this path. Unfortunately, what often got lost here was quality. More often than not, the offshore developers were not of the same skill level as their US counterparts. Language and cultural differences caused various amounts of frustration and many in the US software market tasked with actually ensuring quality software got built were left disillusioned and frustrated. Again, I am speaking in generalizations and there are plenty of situations that worked out well. But the offshore industry would have a MUCH better reputation in the United States if more people had positive experiences. That does not seem to be the case.

Ok, you might be asking "If outsourcing sucks so much, how did you become a believer in it?" I'm getting to that. I was like many in the Software Industry. I hadn't had any positive experiences with outsourcing and I didn't know anybody that had a positive experience. I was working at a mid sized software company and was told by management "We will finally give you the developers you have been asking for to build the product...oh, it will be offshore, here is your partner...make it work" It probably didn't go exactly like that but you get the basic gist. My first thought after this meeting was "Oh crap. This is going to suck" I bet a number of you have been in that situation. So there I was. An outsourcing skeptic with no choice other than to make the best of it. Little did I know that the best of it was going to be pretty damn good!

So, what was different about this experience? Primarily the partner and the location. I was working with a provider whose team was based in Ukraine. Ukraine you say? That's like Russia right? Yes, Ukraine. No, its not like Russia...it's Ukraine. I'll be honest. I didn't know a damn thing about Ukraine at the time. Like most Americans, I also thought Russia and Ukraine were basically the same place. I also thought it was cold. I will sum up my knowledge like this. I thought Ukraine and Russia are the same. When I thought of Russia, I thought of Siberia, which is cold. Therefore I assumed Ukraine was just an extension of Russia and freezing cold. None of those things are true. In the past 5 years, I would say I now know more about Ukraine than 98% of all Americans and maybe even more than a lot of Ukrainians. I know its politics, its culture, its people and most importantly for this topic, its IT industry. And the Ukrainian IT industry is what has made me a believer in what outsourced software development can do for US companies building software.

What's different about Ukrainian outsourcing specifically and Eastern European outsourcing in general? It is based on a different philosophy than the typical outsourcing models. The focus is on delivering value as opposed to simply low cost. Ukrainian outsourcing is not the cheapest. If you want to get the cheapest rates possible, look somewhere else. And let me know what your product is because I want to avoid it. If you care about software development, you want to get the best quality possible at the best price. And that my friends, is what Ukraine has to offer. The strong education system, the long, rich history in technology and engineering as well as the large population means that Ukraine has some pretty damn good software developers. I put them on par with what you can find in the US. Its not up for debate. Ukraine produces some really skilled tech people. Your costs will be about 50 to 60% of what you would pay in the US and you get literally, no drop off in quality. Like I said, if you give a shit about your software product, then quality is what you want. Comparable quality at almost half the price? Now that is something worth signing up for. That is what the promise of offshore development was always about. Lower prices AND good quality. Ukraine has that figured out.

So back to me. What was so great about my experience with Ukrainian outsourcing? Really, it comes down to the people. We built a team of around 20 which included developers, QA and analysts. One thing that we did differently is that we treated the offshore team the same as the onshore team. Essentially they were just team members in a different location. We already had two separate US locations as part of the team and a few remote workers in other parts of the US. Our Ukraine team was just a third location that included a timezone difference. My philosophy and approach to offshore teams is to treat it the same way you would when building a local team. We were involved in interviewing everyone for our team. We brought them to the US for at least a month to start. We integrated our sprint teams. We used video conferencing extensively. We got to know them. We built a great team and treated them as equals and we were rewarded with a group of dedicated employees who were engaged, who were accountable, and who felt ownership and took pride in their work. Our team in Ukraine was an extension of our team in the US. They were partners in the truest sense of the word. They were invested in us and truly wanted us all to succeed. I often tell people, I could have probably built an equal team of onshore US based employees, but I couldn't have built a better team.

You might think "Mike, you got lucky, you worked with a company that happened to have some good people". That wasn't the reason. No company has a team of people waiting for you to come along. Almost everyone we hired was recruited for us. Some were available because other projects were finished. Any provider that tells you they have a team of people just waiting for you is lying. Who would pay people to sit around and do nothing? The fact is, we built a good team because there was a great available talent pool of highly qualified people. Oh, and cost? The cost was about 50-60% of what we would have paid for a comparable team in the US. I am not going to say that you can't have a positive experience with outsourcing in other locations. I have had positive experiences in other locations. Most notably, South Africa. But I do believe if you want to give yourself the best chance to succeed, you should choose a location that has the biggest pool of the strongest available talent. And in general that is found in Eastern Europe and more specifically in Ukraine.

Have questions? Want to know more about my experiences in outsourcing and with Ukraine? Let me know how I can help you! You can find me on LinkedIn: www.linkedin.com/in/mike-mclaughlin-81a9443 and Twitter: @infiniteblinker or send me an email: mike@infiniteblinker.com.

Read More

Realizing the Potential in Offshore Development

Offshore development, particularly in the United States, has suffered from a reputation problem. Unrealized promises and faulty approaches have created scores of dissatisfied customers. Recently, we wrote a whitepaper to address these issues and provide insight on how offshore development can be truly successful. The full whitepaper can be downloaded at the end of this post.

Introduction

For the past two decades, the utilization of software development resources located overseas has been a common practice in the United States. The promise has been one of tremendous cost savings accomplished by shifting away from high priced technical resources locally and replacing them with significantly lower cost resources overseas. The basic premise is simple. Depending on the offshore location, technical resources can cost a fraction of what a US resource costs so therefore one can accomplish significantly more work for the same cost or achieve targeted goals for a greatly reduced cost. This model has been very effective in the manufacturing sector so therefore it should work in the software development and technical sector.

Twenty years later, it’s safe to say that the initial promise of offshore development has gone largely unrealized. There are a number of factors which have contributed to this less than stellar result.

• Software Developers are not Commodities – A typical software developer in most common offshore destinations is not the same as a software developer in the United States, primarily due to the differences in education and training. 
• Software Development is not Manufacturing – Software development is as much art as it is science. While there are always efficiency improvements gained by adding process and structure, there is no substitute for highly skilled people. 
• A Myopic View on Cost Savings over Quality – Offshore development has typically been driven solely by a perceived cost savings. Quality is treated as a second class citizen. In reality, initial cost savings are significantly lowered by additional overhead and hidden maintenance costs resulting from a lack of quality. 

These are some of the key reasons why to date; offshore development has not lived up to its potential. This has led to a pervasive negative feeling regarding offshore development within the US technical community. There is reluctance from many to utilize offshore resources due to their past negative experiences. In other cases there is an acceptance that offshore development means poor quality and the only option is to grin and bear it.

The goal of this paper is not to explore the reasons why the majority of offshore engagements have failed to meet expectations but to show that it doesn't have to be this way. Offshore development can deliver both high quality and lower cost. The key to achieving this is to abandon the “old school” offshore models that continue to fail and embrace a new, “enlightened” model that will offer a roadmap to success.

Why Most Offshore Projects Fail

Before we go into detail on how to achieve a successful offshore project, let’s briefly look at some of the common causes for failure. Understanding where things go wrong is the first step in addressing the problem and finding a solution.

Many of the issues that occur in troubled offshore engagements fall into one of three categories: unrealistic expectations, a lack of oversight or an incompatible partner. Generally it is a combination of these three issues that derail a project and lead to failure.

Unrealistic Expectations

Offshore development is not and never was a magic bullet that was going to solve all of a company's problems. Many offshore initiatives are driven from a high level under the mistaken premise that utilizing lower priced offshore resources will lead to significant savings roughly equal to cost differences between onshore and offshore resources. This thought process misses a few key factors. First, an offshore project will require more project and administrative oversight which creates additional cost. Second, quality in most of the common outsourcing destinations is not equal to their onshore counterparts. This leads to significant hidden costs incurred when code has to be rewritten or refactored once delivered by the offshore partner. These additional costs are much harder to track and can ultimately erase or significantly reduce the initial perceived cost savings.

An offshore project should be viewed from a value perspective instead of a purely cost based perspective. A “Smartsourcing” approach should look at a number of factors when evaluating if it is worthwhile to engage in an offshore partnership. Cost savings should be one of a number of factors considered. Perhaps the project allows onshore personnel to focus on more mission critical work, maybe it’s an exploratory project that needs to be vetted before committing significant resources. Quality should be a primary driver as well. Saving money and getting an inferior product rarely benefits anyone. Ultimately a determination on the received value versus the actual cost should be the main driver for undertaking an offshore engagement.

Lack of Oversight

Offshore Development projects are complex projects involving multiple companies, people, locations and time zones. They require significant oversight and management. All too often this fact is ignored and lack of communication leads to major issues. A common mistake is to assume that once an offshore partner is chosen that management of the project will be handled by the offshore team. Often there will be a primary point of contact on the customer and offshore partner side and occasional interaction between other team members. One of the biggest mistakes that can be made is to treat the offshore component as a black box. If you expect to provide requirements to the offshore team and patiently wait for the finished product to come out the other side, you are in for a great deal of disappointment.

Offshore projects should be managed much the same way an onshore project would be managed. Communication is essential. There needs to be regular communication at multiple levels to ensure that everyone is on the same page and that things are moving forward and meeting expectations. The more moving parts that exist in a project the more important it is to have an effective process in place to manage the project.

Incompatible Partners

Choosing the correct offshore partner will make the difference between success and failure. It is important to find a partner that is a fit for your company. Your offshore partner ultimately will be an extension of your company. The same care and deliberation that is taken to find the right employees to work onshore for a company should be applied when selecting an offshore partner. A highly structured company utilizing a waterfall development approach will not be a good fit with an offshore partner who espouses an Agile methodology as its key to successful development and vice versa. It is important to find a partner who can easily adapt to how you want to do business.

Key aspects of partner compatibility are corporate and cultural fit, availability of resources and quality of resources. Offshore engagements that are expected to be long term need to take this into consideration. It is easy to find a single strong technical resource anywhere in the world. If you need a team of 100 by the end of next week, not every location can accommodate that. Even before considering specific partners, understand your longer term goals and assess the potential offshore destinations that fit. Only then should you start looking at specific companies as partners. Evaluate the pool of resources for quantity and skill level. Assess the strength of the education system producing the resource pool. Consider cultural similarity and communication skills to better understand what the working relationship will be like on a day to day basis. Depending on the specific need, some offshore locations are better options than others.

A Roadmap for Succeeding with Offshore Projects

...

If you'd like to read the rest of this whitepaper, complete the form below and click submit.

White Paper Download
Company*
First Name*
Last Name*
Email*

Read More

Getting Value from Offshore Development Teams

Recently I was interviewed by Viktor Bogdanov for the Intersog Blog Podcast series to discuss my experiences working with offshore development teams.

Listen to the interview below.

Read More

Corporate Culture and (Offshore) Software Development

Corporate culture.  It gets written about a lot these days.  In fact I am writing about it because I recently read a good article on Recruiter.com that had all kinds of detail about cost to businesses of disengaged workers and why culture is so important.  I don't know a lot about those kinds of details and I don't know if I am breaking any new ground here but I can share my perspective on company culture in the software development field and also how it extends to offshore development.

Company culture in software development is particularly important.  Software development is as much art as it is science.  It is a creative endeavor that typically requires a group of people to work together in a highly collaborative manner.  It involves people from many disciplines; development, QA, business analysis, IT, etc.  The whole Agile concept is built around groups of people working together closely and sharing ideas in order to build high quality software that adds value to the business.  Nothing is more disruptive to that process than a team that suffers major personality clashes and can't find a way to effectively work together despite having all the necessary skills.

I am not here to tell you there is a right culture and a wrong culture...let me revise that.  There definitely ARE wrong corporate cultures that really don't benefit anybody but that is another topic.  There are many different corporate cultures that work very effectively for their respective companies.  I am aware of one company where everyone is encouraged...no expected to speak up and question things regardless of their position, rank or seniority in the company.  If you disagree with something it is your responsibility to raise your concern even if its your boss, their boss or the CEO with whom you disagree.  I don't think that is a very common corporate culture but it works for this company which is a VERY successful company.  The real point here is you need the right people that fit into your corporate culture.  My philosophy on hiring is to put a lot of emphasis on team fit.  I would rather higher a less skilled employee who is a good team fit than a more skilled individual who nobody will want to work with.  I can teach someone new skills.  I can't teach someone NOT to be an ass.

I find that in outsourcing and offshore software development environments, this approach of hiring for cultural fit is often thrown out the window.  Too many companies treat offshore development as a commodity the same as if they were buying PCs or servers.  While there may not be a huge difference between HP and Dell computers, the same can't be said of software developers.  The same approach you would take when hiring full time employees should be utilized when you hire an offshore team.  The Agile methodology is increasingly being applied to distributed and offshore development teams.  This means a higher degree of collaboration and interaction with your offshore team.  You want to hire the same type of team that you would if they were working in your corporate headquarters.  I have seen first hand how beneficial this can be.  It really shouldn't come as a surprise.  Offshore teams that fit your corporate and team culture make it much easier to collaborate and interact with onshore teams.  They are more engaged and feel a greater sense of ownership.  It ultimately brings your entire team closer together.  And when working in a distributed environment, anything that helps in that regard is worth trying.

My recommendation when engaging an offshore partner is to get involved in the hiring process and treat it the same as you would when hiring full time employees.  With Skype and video conferencing widely available, there is no excuse not to.  The goal of any working with any outsourcing provider should be establishing a collaborative partnership.  Hiring for corporate cultural fit should be a goal regardless of where the employee sits.  Ultimately it leads to a more productive relationship.

Read More

Building and Managing Successful Offshore Teams

Originally published on the Intersog Blog

I have spent a fair amount of time in building from scratch and managing an offshore development team in Ukraine.  When the topic of offshore development comes up in conversation it always leads to questions about how to make it successful.  I have spoken with many people who have had less than positive experiences with offshore development.  Typically those followed what I view as an older model of limited interaction with the team and primarily handing off requirements and waiting for results.  My experience has been much different and I view offshore development as a great way to get quality software at an affordable price.  Since this topic is of interest to both project managers and business leaders I decided to give an overview of my approach in a blog post in the hope that it may be useful to many readers.

Our approach to building the offshore team was to treat it as a partnership. The goal from day one was to have the offshore team become an extension of our US based development team. We had two locations on the east coast and the plan was to have the Ukraine team essentially be a third office and operate as part of the team. We followed Scrum as our development methodology.

We had approximately 15 team members in the US and added about 20 people in Ukraine in the span of about 3 months. We added developers, QA, Business Systems Analysts and Proxy Product Owners. After onboarding and initial ramp up of the new team members we divided the team into 5 separate Scrum teams. The majority of the teams consisted of both US and Ukraine team members. We focused a lot of effort on integrating the teams through the use of skype, video conference rooms and IM. We conducted daily standups with video and had frequent interaction between US and Ukraine team members.

The biggest challenges we faced were at the beginning of the project. These challenges were related more to the fact we brought on so many people in such a short time rather than the offshore aspect of the relationship. We faced challenges with knowledge transfer and ramp up while trying to still deliver code and meet project deadlines. This challenge would have been similar even if we had brought on resources in the US. Most of our team spent their first one or two months on the job in the US working side by side with the US based team. This helped with ramp up and knowledge transfer while establishing relationships with team members which was key to the culture we were trying to establish.

There were a number of challenges that were related to the offshore nature of the relationship. First and foremost was the time difference. It was more of an adjustment for the US team since the Ukraine team was used to this type of working environment. We made a few small adjustments which helped with the time difference. We had all team members add a second timezone to their Outlook calendars so it was clear when scheduling meetings what time it was in Ukraine. We also asked that any meetings with only US team members take place after 1pm in order to maximize availability for working together with the Ukraine team. Communication can be an issue as well. We were involved in the hiring process and conducted a video interview after our outsource partner did the initial screening of candidates. English proficiency was a key requirement for us given how we intended to integrate the teams.

Using Scrum was a goal of the project. The US team had been using an informal version of Scrum and the Ukraine team had various levels of exposure to it. We engaged Agile coaches to help the teams learn the process and understand best practices. We also conducted a sprint where we took a team with representatives from all disciplines (development, qa, business systems analysis) and all locations and worked on defining a Scrum process that worked best for the team and our distributed nature. Using tools such as JIRA and Confluence and other Atlassian products gave us a solid foundation for working in an Agile fashion.

I think the cultural similarities between Ukraine and the US contributed to creating a successful team. In general the team members got along well and there were no significant challenges related to cultural that would have been different in an all US based team. Conflicts did occasionally arise but those were more due to personalities than anything else.

Speaking about the skills, I found the skill level of our Ukraine team to be on par with that of our US based team. We had a team made up of Senior, Mid and Junior level people. I received positive feedback from managers and tech leads regarding the skill sets of the UA team. Prior to engaging with our offshore partner we had tried to hire US based developers and had a hard time finding what we were looking for at acceptable prices. A lot of that had to do with our US locations as well as the competitiveness of the US technology market. It took longer than expected to fill all of our development positions in Ukraine do to market competition there as well. We also had a few team members that didn’t work out but all in all I was very pleased with the level of expertise.

If I had to rank all of our development team, it would be a mixed list with US and UA team members throughout. We were working on older applications with some older technology so in a lot of cases both US and UA team members were unfamiliar and had to come up to speed.

When I’m asked about the recipe for successful cross-border collaboration I usually answer that the key to building a successful offshore/distributed development team is to embrace it as a partnership. Treat the team the same as you would full time onshore employees and seek to build a team that matches your corporate culture. We had a lot of engagement with the offshore team. In my role I regularly met with the Director of Delivery in UA via skype to assess where we were with the team and the projects. My managers oversaw the day to day activities of the offshore team the same as they did the onshore team. That approach enabled the offshore team to really feel they were a part of the team and in turn they showed a high level of engagement and ownership in the project. They put in extra hours as needed without even being asked. The emphasis on communication and the use of video also helped create a more cohesive team. That’s not to say there weren’t issues and everything went smoothly. There definitely were challenges that had to be worked through and overcome. The project itself had numerous challenges. But by focusing on a team approach where everyone was an equal member I feel we mitigated many of the challenges normally associated with using offshore development teams.

Read More