Software Outsourcing: Pitfalls and Best Practices

Software Outsourcing:Pitfalls and Best Practices
Igor Tsinman
CTO, Sitrus

When to outsource (and when not to)
Typical projects
Key issues with outsourcing
Most common reasons projects fail
Best practices
Questions to ask your potential partner
Agenda

Sitrus / AMC Bridge is a U.S.-based software engineering outsourcing firm, with >100 developers in Ukraine. Over the past decade we have carried out dozens of projects for both established firms and many start-ups (CAD/CAM, SaaS business apps, social network sites).
The observations and recommendations in this talk are based on our and our partners’ experiences in carrying out these projects.
Background

Augment / expand team
With skills that may be hard to find locally, or that are not necessarily part of the long term “picture” for your company
Time to market
Project cost savings
Save money or extend existing budget
Cost savings can be 4:1
There are pros/cons
No free lunch: in many ways, successful projects require many of the same elements as building your own team (communication, organizational knowledge, processes)
Outsourcing is not a “silver” bullet – just another tool in getting things done, taking into account tasks, resources, time and money at hand.
Why outsource?

Support of existing product
Allows local team to concentrate on new breakthrough version / direction
Augment existing team
Help cover an area outside of the team’s core expertise
“Try something new”
high risk, outside of the firm’s core business
One-off (relatively short) project
E.g., needed for a particular customer
[Most of our experience, and thus the observations and recommendations in this PPT, are for projects in category 1-3.]
Typical projects

Several ways that outsourced engineering teams can play a role
Occasional one-off project (e.g., 1-2 engineers for 2 months)
Extension of in-house engineering team (e.g., 5-10 engineers on a more-or-less ongoing basis)
Fully outsourced development
Wide range of scope

What’s delivered is not what’s expected
Bug fixing can be long and cumbersome
After project delivery, lots of time spent bringing it up to the acceptable standards
Excess expenses eat up projected “savings”
Common failure modes

Most common reasons projects fail: Information Mismatch
Business context mismatch
Lack of understanding on the part of development team of the purpose and goals of the developed application
Technical context mismatch
Lack of clarity and coordination on key architectural assumptions/design/approach of overall program
Development Process mismatch
Not integrating the outside team into overall program’s development process
Cultural mismatch
Well-meaning but incorrect approach due to cultural differences (e.g., “The customer is always right” and “We shouldn’t ask WHY” eliminates valuable back-and-forth discussions)

Business mismatch is on of the most important “barriers” to outsourcing especially when it comes to business applications.
For example, if you need to design and build application for performance based compensation in brokerage industry you should understand some basic things about how this industry works, such as:
The difference between gross commissions and net commissions.
What is ticket charge, what is trailer etc.
The gap could be mitigated by a well defined spec, but it may not be enough in all cases.
People work more productively if they understand the “big” picture, and see their work in the context of the overall project
Business context mismatch

Here we are not talking about “basic technologies” like C++ or Java or .Net…
Rather, this is about the architectural assumptions of the project, approaches and ideas that technical leads put into project.
It’s rare that that information is captured in up-to-date documentation – at best one finds “original design documents” which most of the time are very outdated.
Frequently, developers are forced to “research” product architecture by looking into code. For “local” staff, this can be mitigated by ability to ask questions in the real time – for outsource team this is much more difficult.
As a result code submitted by outsource group can often be “contradictory” to the approach taken by the “main group.” It may not follow design guidelines, may be considered “poor” and unusable. At the end of the day quality for the project declines –sometimes to a critical point.
Technical context mismatch

Often, in a rush to get first version, a prototype, or next generation product out the door, the team “cuts corners” in the development process. It’s not good at any time, but could be potentially managed when “all people are in the same room.” But this can be disastrous when outsourcing.
This is especially true for many small companies and start-ups.
Need to think through: project management, communication, code submission process, bug tracking, time management, QA, documentation.
Development process mismatch

This concept is a bit difficult to define, but it is there…Couple examples:
There are culture where “it is impossible” for the boss to we wrong – i.e. if you’ve been told to do this – you should do it, period. Regardless of the quality of the assignment or the fact that you may know how to do it better.
Engineers are chronically afraid to ask a question of their customer’s project leader – fearing that someone (especially their customer – their “boss”) will think that “they’re stupid.” The result is that the boss always hears “OK, everything is good” - while the engineer on the other end searches endlessly for answers to simple questions.
Cultural mismatch

Areas to probe:
Evaluate how familiar outsourcing partner is with business domain, architectural components
References – similar projects
Explore their operations – process, approach, tools, technologies, source control, bug management, etc.
Key questions to ask

Best defense is to avoid dealing with “random” people and organizations
If you have an important project, it should not be outsourced to “moon lighters”
Rather, look for organization who has been in business for some time, and has invested in building a company
They would police their workforce themselves since “IP leak” would spell death for their business;
If company ownership is in the US, this would add additional “protection” – owners could be reached by US legal system, adding pressure on them to build team and process accordingly.
Intellectual Property

Think long-term, build teams, invest in bringing people on board
Choose teams w/domain expertise (rather than focusing on programming language / technology)
Communication – one-to-many; many-to-many
Best practices

Build a team that works for you, rather then approach it project by project.
This helps create the effect of “information accumulation” – once explained, a topic could be clarified later, avoiding the need to revisit it over and over again
Select teams that have worked in the same business area. For example, if they have written applications for financial industry – they most likely know concepts and terms such as Account, Positions, Product, etc. mean.
Select teams that have experience in outsourcing for companies similar in size to yours
Select teams that have built applications similar architecturally to yours– e.g., Client Server, Social Networks, CAD etc.
Choose/build the right team

Spend time to bring engineers on board – both in terms of business as well as technical aspects of the project.
For example: at the beginning of a project, or at an important stage of the project, key members of outsourcing team visit your company for extended period of time, to get “merged” into the thinking around requirements, specification and approaches. (Also helps reduce cultural mismatch!)
On-boarding new members

Have somebody onboard who is “constantly” responsible for communication and management of offshore resources – weekly meetings are a must;
Structure outsourcing team in such a way that while everybody can talk to everybody, there is a point person on the other side for issue resolution as well as issue tracking;
Pay close attention to the process – a well-defined process is essential to making sure that offshore team contributes successfully to a project.
Communication

Case Study:Interactive Supercomputing
MIT spin-off in High Performance Computing recently acquired by Microsoft
Founded 2005; Identified need for outsourcing in 2006
Deployment and installation tools, QA framework, Math libraries developments
Conducted search for outsourcing partner, hired and trained internal manager for the program (~12 months)
Selected outsourcing partner, hired 2 Engineers and invited them onsite for 4 weeks of intense training (early 2007)
Implemented best practices:
Built communication, project procedures etc. for 6 months before hiring more people into the group
Regularly hosts new members for on-site training, sends program manager overseas for group meetings
Expanded group to 10 engineers, testers and system administrators ( 30 -40% of the total development force)
Conducted several research projects by temporarily expanding the team
Acquired by Microsoft – 09/2009: 2out of 3 technologies highlighted by Microsoft tech assessment team were developed with active participation of outsourcing team

Outsourcing can improve time-to-market and save money…
…But there’s no free lunch.
Must be vigilant about key failure modes, and be disciplined about best practices.
Summary

Questions?
Igor Tsinman
itsinman@sitrusllc.com
(617) 842-7470

http://productmanagementtips.com	1510
http://www.sitrusllc.com	355
http://blog.kerslappity.com	133
http://sitrusllc.com	68
http://www.slideshare.net	25
http://translate.googleusercontent.com	5
url_unknown	4
http://www.netvibes.com	3
http://clicks.aweber.com	1
http://www.google.gr	1
http://www.google.com.ph	1

Software Outsourcing: Pitfalls and Best Practices

by SitrusLLC on Mar 03, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

11 Embeds 2,106

Statistics

Software Outsourcing: Pitfalls and Best Practices — Presentation Transcript