началоstart ~ софтуерът-и-азsoftware-and-i ~ биографияcv/resume ~ библиотекаlibrary ~ снимкиphotos ~ детскиkids' ~     english

Outsourcing, offshoring, global software development, custom software subcontracting

All these are about taking out and distributing work, geographically or not. Some ways are more separated and independent, others are more intertwinned - one team is part of the other. The major problem in any such undertaking is the communication between the teams (written spec is _also communication). There are 3 main obstacles - cultural, language and time -differences. IMO the cultural one has the biggest impact. It may happen even if all are in same town, but following different cultures/ way of thinking/work. And it is hardest to overcome - mentality is not easily changed, and not everyone is able to walk in other people's shoes. That's my experience after several years in a global development project with 4 teams of diff.cultures. It also goes around general way of thinking, learning, and all related.

See Testing Experience magazine 1/2009 with plenty of articles about outsourcing/offshoring - including general topics like economy of outsourcing.

Below are some questions and answers around the topic. i use Linkedin as cloud-interviewer, for not having anything better... That is, various (unknown) people there ask various questions and i answer some that are interesting to me and i feel i have what to say. There might be some overlap in the answers, repeating some things...

Tina Lau:

Why software development is so complicated?

because software is just a way to store knowledge (about what we think of reality), and communicate (it), a very twisted and odd way.

and we humans don't know much about ourselves, let alone reality...

Karen Smiley:

What specific aspects of Global Software Development are having the biggest impact on your teams?

The literature on global software development (GSD), sometimes called global software engineering (GSE), identifies temporal factors, culture differences, and language barriers as the key factors which exacerbate the challenges facing all distributed teams (coordination over distance, trust, and communication).

In your experience with GSD, what aspect do you believe has had the biggest impact, why, and what approaches have you tried using to mitigate this impact?

i've worked on a project (stc - Singapore Turf Club) with 4 teams all of diff.cultures - bulgaria, germany, singapore x2. The most impact was cultural differences AND when they where chained having opposite directions and eventualy dimensions. i.e. end customer was .sg state company; their direct vendor is multiunational in .sg; their sw subvendor was same multinational but in germany - then me/us in bulgaria as last link (well it ended us doing most of the thing). In some sense .bg are closer as culture to asia than germans for some things so some batteries were chained with opposing polarity :-) In other senses (corporational) .bg is simply out of sync with germany/sg; .sg-state-company has very diff. (chinese) way of work than multinationals/europeans; etc... societies are also very different... There wasn't a single important concept that all teams would have same idea about. Regardless if they were at same place and language or completely different.

All this caused 3+ months delay in getting the proper info flow - dead time which we spend inventing/reworking lowlevel architectures without much idea of what it should become on top.

The (only) thing that worked was a-leader-and-someone-else-per-team face2face all in same place @ customer for some time. Everyone to see what things are about and who is who. It was not without some quarrels but at least something was going on! Apart of that, as we had to go onsite after 3 months anyway i had to see for myself what the heck it is about (culture, mentality, place, climate...) and how/if we can survive there.

Result: The first day after that trip the amount of exchanged mails exceeded the total of previous 4 months. Of course there were other ups and downs later but nothing that major as the initial stuck.

that is my experience -- too many clocks to syncronise can be very difficult, and only face2face and lots of patience and wish to understand others can help.

second in the list comes language - the common language was english which is not native to neither! 3 different schools of teaching english met together:-) Add singlish to the equation and the mess might get interesting. But one can repeat and ask if understood and repeat again - so this io not that bad as not having communication at all.

Irina Semenova:

Let's speak about projects demanding to look for the balance between strict predefined requirements and flexible requirements modification. How to make such projects safe for the both sides (outsourcing the work and offshore software development company)?

Working for more than 7 years in the area of offshore software development we have established the rule: to start new project only after preparation and signing of Project Proposal consisting the complete detailed description of technical and functional requirements, all possible risks, software development plan, test plan, etc. As our experience shows such approach permits to guarantee the project success.

However if we consider R/D projects such approach is unacceptable.

Moreover, some projects (being not R/D ones) demand rather flexible management. You know... some times customer's requirements are changing directly in the process of project fulfillment...

So, what is your opinion: how to make such projects (demanding "flexible" approach) safe for the both sides?

i have lead in a project where we were the "offshore" (ehm the "onshore" was .sg -:), and first, the requirements came late, second, they changed drasticaly on the run... final spec was written just after the running sw. So i say - it is possible, but needs very flexible and wide big-picture architecture, and perfect communication, that means much more as understanding (language, culture, thinking, everything) than as just link, and very good analysts on both ends.

The shorter the iteration the better (~week); noone on any side should wait for the other to also find same issue - any issue (technical or requrement or else) has to be resolved or escalated to other side as fast as possible.

There was some story by was it I.Asimov (or maybe other), where humans have to talk with some other civilisation with a delay of years... and the solution was to keep talking/thinking aloud on both sides in paralel. Something like this has to happen here...

Irina Semenova:

Lets discuss the beginning of relationship between offshore software development team and company that outsource the work... Which project to start with?

Perhaps, it's the axiom in today world that long-term relationship between offshore software development team and company that outsources the work (vendor or integrator) is the right key for stable successful co-operation in fulfillment of projects of any type and size.

However long-term relations are the result of the first, second, etc. successful joint projects...

So... let me ask you a question related to the beginning of relationship: If you are going to outsource some work to offshore software development company engaged in development of complex bespoke enterprise-level applications in Java and .Net, which type of work will you prefer to start with: a) fulfillment of large Java or .Net project with complicated architecture; b) fulfillment of relatively small Java or .Net project; c) development of some part (for example, some modules) of large project? Why?

it depends on which side you are, and what u want to achieve. e.g. how much in/dependency u want to get or give.

complicated architecture does not really matter, large and complicated user-workflow and user-data-worklow, as well as misty applicational field does. the closer to human, the harder.

your b) is best by starting with small independent project that is not of sheer importance - i.e. there is already another old such thing and this is a new replacement. it can measure dev's out-of-the-box thinking, analisys, big-picture-seeing etc - and how the customer reacts - to questions, ideas, failures, whatever. Mind u, if both parties know this is trial thing that noone cares about, u may not get the devotion and result u want.

your c) would prove that the devs can follow guidelines, architectures, timelines, style etc.. play as (spare) team - and that customer can actualy feed them with proper info and has regular reactiveness - play as team also. This might be easier for non-expert or non-self-dependent devs.

large project should come 3rd or 4th, although it's more matter of time than number. 3-4-5 months depending on density of communication and mutual cultural knowledge/ties.

But then, if there is a choice, ... best might be a b) that is sort of prototyping / exploration on a). At least in some directions. So the built trust and comm.channels (software itself IS a way of communication too) are reused max.

some face2face is a must, with almost half of it outside-office relaxed athmosphere. in the beginning u dont care if the other side can type 500 LOC or 10 requirements per hour, but whether it's worth dealing/working with such people at all. Any sign of boredom means no.

more to the face2face, if there will be mutual work and not just "do these for me thanks bye", there should be sort-of exchange of "ambassadors", so both sides know how the other looks and lives, in first-hand experience. This might not be needed if there's looong face2face of one side into the other.

Irina Semenova:

One more question related to the beginning of relationship between offshore software development team and company that outsources the work: How do you prove that you are really interested in fulfillment of the project that you suggest to offshore team?

I mean - you give the offshore team some task (for example half-ready technical proposal) and wait for exact estimations prepared by senior technical specialists of this team. They need essentially more than one hour to fulfill this work (to explore your requirements, to suggest the plan of work, to calculate all possible risks, etc.). However you can refuse from this project any time you like (before the documents subscription). So how do you usually "show" that a) you are really interested in this project? b) your intentions to work with this particular team are serious? (How the offshore team can "feel" that fulfillment of the preliminary work is not the waste of time?)

One hour? it might be 5 minutes but give a day. (in the mean time do your own rough estimations, ask 3rd party if need be).

Try to be as open / informal as possible and even suggest them asking questions. The more the better. if there are no questions asked / replied, not worth working... i mean after 20y softwaring i'm yet to see a spec that has everything in it. By the quality of questions and knowing the spec u sent, u measure them. and vice versa, by the quality of spec and (involvement in) replies they measure you.

U know, refusing/throwing out some piece of work might happen any time. we had once 5manmonths of work that the customer wanted initialy but then decided to cancel and ignore (and not pay).

Not to say that this is a good thing, it burns and kills enthusiasm, but life is life. One may say it's the equivalent of paying and investing time for some work and getting nothing in result.

Irina Semenova:

Is the experience in collaboration with other vendors a strong or weak side of offshore software development team? What IPR protection measures are sufficient if you know that offshore team continues working with other vendors?

Not long time ago I was talking with CTO of one European vendor who said that he never works with offshore software development team that collaborates with other vendors, so far as he is afraid for his "know-how"... Our company provides IPR protection measures including legal provisions (NDA agreements between companies, Confidentiality clauses in employment agreements, etc.), technical provisions (restricted physical access to servers, limited access to project's artifacts, etc.), organizational provisions (such as separate office for the particular project and limited usage of means of communication, restricted file copy and transfer opportunities), cultural provisions, process provisions. However I felt that it is not enough for him!

So my questions are: 1) will you outsource work to offshore software development team that successfully co-operates with other vendors? 2) what IPR protection measures are sufficient if you know that offshore team continues working with other vendors? why?

U have to cut a project into parts/notions.

Some parts are considered non-interesting enough and can be outsourced, or open-sourced, all the same - put out. the rest u keep for yourself.

The more layered the architecture of a project, the more parts can be dis-connected and pushed out... and more complex it becomes. i don't talk just sw-dev here. requirements, documentation, reallife rules that is distilled stored in the system...

But your question is not only about outsourcing. it applies to any work that involves visiting several "patients", that is, customers.

Long time ago i was installing my accounting sw to a customer, effectively playing a consultant putting their business rules into the system's languages... and they kept asking if their knowhow will be safe... i told them: if u want it to be completely safe, learn the language/tool yourself and code it, so noone else sees it... Would u go to a doctor who claims he never sees other patients, and learns from them?

Well, they did not buy the system. They got something else, much more primitive, and they kept the business rules out of software. Not that i would share accounting "knowhow"... i could not care less. Many other customers did not care _that_ much, and bought the system. Some still use it - 10y later.

So it depends. some people do not want to be helped.

Irina Semenova:

Which differences between vendor and offshore software development company (sub-contractor) fulfilling the outsourced work are the most important (undesirable) for vendor? for sub-contractor?

Range please:

a) difference between time zones (it can cause difficulties in communication with sub-contractor);

b) cultural differences (for the same reason);

c) different approaches to PM and QM;

d) different horizontal experience;

e) different vertical experience;

f) different attitude to necessity of providing strict IPR measures;

g) different attitude to necessity to provide project visibility???

i'll order them this way, most important to less important:

- b) cultural differences - here culture has many other meanings than just "country" - i.e. corporate vs tiny-company; state-owned vs private, burocratical-waterfall vs on-the-run-agile; 9-to-5 vs work-when-there's-work... These put context and hence influence everything else

- ? requirements gathering/analisys/management / Questions and Answers Exchange / smooth info flow - this isn't in your list... It might be taken for granted but not everyone knows what it means - i.e. anything unclear has to be requestioned until cleared. Else the result might not be what is expected. For example, (cultural) here-there women might not question men - or men might not answer women; (approach) a requrement might or might not be disassembled to tiniest details; (managerial) certain projection of the requirements is deemed imporant and all other views are ignored... etc

- c2) different understanding of Quality - all tests pass vs the thing is usable - problems here might happen to come from requirements/business-analisys omissions at big picture level

- c1) different understanding of Management - be it visibility, deadlines etc. Decision making process on _both_ sides is important here; it may also come from culture - e.g. whether all internal negotiations and ups and downs on some topic are visible or only the final decision is visible when ready - on one extreme this may induce extra work that is later deemed redundant, or on other end leave a long idle gap and then (surprise) demand something huge for tomorrow.

- a) time-zones - usualy one person per team is most affected, and may shift worktime to be able to overlap all zones

- all the rest; but IP policy + experience has to be checked beforehand - it might be too late once in

Note that u probably assume there's one vendor and one subcontractor. While i have experience with 4+ teams in a chain/mesh and that changed things alot - e.g. the _order_ of communication and direct or not access to each other started to matter.

Ah u also asked whether vendor and subcontractor would range above differently... IMO the process is mutual and they better align the priorities upfront. if one cares mostly about money while other cares mostly about end-customer-satisfied... (culture again) this will influence just about everything - they'll be talking in diffferent languages and not hearing each other.

Mark Bouch:
Do you have specific examples where remote teams work really effectively?

In a number of cases remote teams work really effectively. These include product development (e.g. software development) and some field-based sales teams.

If you have examples of sustained high performance in remote teams I would be interested in a brief synopsis including the team's purpose and outcome, what differentiated this team and identifying the reasons why it was so effective.

off my humble experience... combined with software architectural and organisation patterns, a remote team works effectively if all of it is I/O links are well defined and satisifed (think of a hw device). By input/output i mean in the broad sense - requirements/spec (anything that says what and why), direct or indirect customers (anyone using some output is a customer), and "servers" (to which the team is customer, like office, infrastructure, pay etc).

Optimization can happen by shortening communication paths/patterns, in some case by moving some of the external "hops" within the team, so the interaction is direct. (or moving the team to them if thats easier)

But make sure they share the same culture or a "wall" may form in between, and that is worse face2face than remote. And make sure there is someone there really devoted to the thing, ambassador fo sorts.

my example: terminal/kiosk sw for SingaporeTurfClub betting, us being the "remote" team. pre-history: The forming of the linuxteam started as outsourcing, in a place/office separate from main company, with own servers/network etc. i/we communicated to the customers (WN.konstanz) directly, and have little to do with the rest of the company. Once i got the STC project, getting new people and shaping the proper agile culture of trust was only matter of time. Being independent really helped as i had to communicate to two diff. time zones and about diff.matters - and we ended having much better network connectivity than main office, let alone culture. Initialy there was really bad communication because we were treated as 3rd level link (so stuff went from STC to WN-sg to WN-kz to us), and the "broken phone" game was no fun at all. And it was wrongly "wired" - STC (end customer) - WN-sg (field-team) - WN-kz (?) - us (dev) - WN-kz (support) : most of the dev was with us and we were customers to WN-kz and not vice-virsa. After some quarrels we did get direct link to WN-sg, and things went better (eh, with 3 months of info ~lost). We were under big pressure even without that delay... The thing was at impossible stake. But the culture in the team helped here - 10-12-18hrs sat/sun/... it was matter of honour. Then at some time we went to end-customer for a month... the way that happened was another pre-optimization: being in oz and around i saw what .sg is about (from .bg point of view) and decided the team will not survive (5% chance) if not with families and all in one house (not hotels and not apartment/s) - so we can bring some local "spirit" with us and not submerge completely into foreign water. Having "negotiated" that (eh, it was either that way or we quit :) we went there for 2 months then back... and things went smoother after that. Mind u, in 3+ years working around that project we spend about half an year there. And, just last year, when i went there for last time to handover technical training/knowledge, a real human contact with end-customer people happened. Before it was like a... opponents? But better later than never.

what could be done better? that absolutely lost miscommunication in the beginning, absolute cultural block of sorts (singaporeans-to-singaporeans-to-bulgarian/oz via germans), and the overall req.gathering process was poor. The sw base from WN.konstanz we had to use wasn't much suited for the app-dynamics and i had to rewrite quite some parts, but that software, it's fixable/replaceable - just needs time and skills.

People relations are not that easily makeble nor mendable.

So make sure your people and relations are ok. Technical stuff is solvable.

Ah yes, later, that same team, working non-remotely, on internal-company project couldnot make that traction anymore. The company had completely different culture, very weak req/analysis etc environment, i had to define and then "stub" quite a few things - although the business analyst / product/support-manager was now in the team, neither the req.input nor the end-user "wires" were satisifed. And results weren't that good as before. And the firewall - me - got overloaded -- it was easier being remote, much less things to filter.

Denis Romanovski:

How do you differentiate software development outsourcing and custom software development services?

What is the main difference in the service proposition, customer relations, software development processes, resource management and produced value?

Is custom software development currently declines in face of popularity of outsourcing? May be because of the recession the custom software development will be more popular again?

It would be nice to read thoughts of professionals.

Architecture-wise, IMO outsourcing is when a part of otherwise nondividable whole is given to be worked outside, while custom development is when a (better-defined) dividable part is commissioned to someone else. Say u outsource company's accounting but u subcontract some product.

It seems like a play upon words but is more "topological" distinction, like horz vs vert splitting.

Of course recently they are very well used interchangingly and blend.

Brian Curtis:

Has the community of outsourcing companies become desperate?

Hardly a day goes by on LinkedIn that someone associated with an outsourcing company doesn't post a "If it can be outsourcing it can be offshored!!!" or "Outsourcing produces a better product, you must agree" type questions. Personally, I don't care where companies allocate resources for projects. What I do find interesting is these acts or desperation on the part of service providers. I can't imagine that these postings under the guise of questions are productive for their business. They come across as completely unprofessional to me. I'm not a marketing professional, I'm just one of many US software engineers, so I could be wrong. What do you think? Are you more likely to work with these people/businesses after encountering such "questions?"

i dont think it's just offshoring.

the marketing of all sorts is getting desperate.

there's way too much marketing per day recent years, IMO much higher than what people can take/afford. And it has to go away.

all the adver-questions here are just top of the iceberg.

Clifford Adams:

How often are you given adequate Software Requirements during development?

As the economy crunches further, companies may be tempted to throw requirements and planning out the door in favor of getting things done fast and cheap. This creates a risk, in that they rely on their developers to be analysts as well. So that means the salary the developers signed up for with the expectation of performing one job (development), just became the salary for two jobs.

How often are you given adequate requirements which contribute to the success of your project?

2 times in 20 years, for small things..

for big things i had always become the BA as well - which might be good for keeping info in just one head but is awfully reducing the sleep hours.

One good thing i see in agile methodologies is that their thin layer immeidately shows up all the defficiencies in the organisation around the project, eventualy propping to fix them (bad requirements/BA thinking being one of these). The bad is that... all these defects are automaticaly ascribed to the methodology/process/ team ("it was fine before!"). And all repeats same.

Software Development has progressed and specialized too much without pulling accordingly the input link to reality - that being the requirements producers... whoever they are. So u may get a spec about the how but noone knows the why.

Rupak Anto:

What are Best practices do you follow / recommend for IT projects when you have tight deadlines, addition in scope of requirements and demanding cusomter ?

mmh, i call it direct-drive mode. Be sincere, flexible and firm? removing _any obstacles (or buffers or loopholes) in communication - that may mean far more trust than entities can handle... These Both towards customer AND towards team and yourself. Put some corners and make sure they're kept - e.g. to customer, the trio of functionality-time-budget, and to team, the we-do-it-or-die commitment. Note the _we_ in the last one.

see links to my site for some real +/- experiences:



Andrew Calvert:

How do you unlearn?

... "The illiterate will be those who cannot learn, unlearn and relearn."

here's a story.

someone was living in a village amongst big hills. nice family, kids, etc.

the "statusquo" there was "there's nothing higher that those hills"...

one day he - by chance, or by intent - went up those hills, saw the much larger ones in the far away, and went for them. after some long time, being here, there and everything, he went back.. they were waiting for him.

- are there really no bigger hills than ours?

- mmh. yes and no. there are bigger hills. but they are theirs. not ours.

- - -

unlearning.. is couple of ways. one is finding another alternative, parallel/excluding your current one. lets call that extensive. another one is like seeing your house from outer space, a new perspective/context, not really alternative. call that intensive. and yet another is getting back AND still being able to be what u've been, laugh and cry with others, keeping that outerspace perspective at bay, applicable only if needed. call that ... what? growing up? getting wiser?

Javed Bashir:

Is progress in any field greater in an ideologically driven society than a non-ideologically driven society?

it depends.

IF lots of devotion, and eventualy, money (which arent same thing), is poured into something, it will grow. no matter what.

ideology doesn't matter here. it'll mostly delay, or may, in some cases, push further the happening. but, this wont/cant be seen or understand from outside. coz there's another ideology out there.

Gilmore's Law:

"The net regards censorship as a failure, and routes around it."

the human network: http://blog.futurestreetconsulting.com/?p=39

писалка на тефтер | ballpen on notebook

Детски нещаKids' things

направи самdo it yourself


'2008-2016 ~ началоstart ~ софтуерът-и-азsoftware-and-i ~ биографияcv/resume ~ библиотекаlibrary ~ снимкиphotos ~ детскиkids' ~   az()svilendobrev _ com