|
An example of how to make "offshore" work, work.
I had a project to do which needed more developers than we had available. I suggested outsourcing it and - to my amazement - the company agreed. Outsourcing was new to my particular development area but we had just been swallowed by another company who had a history of that kind of project.
The timescales were really short - 4 months. I now had two teams, one local with bags of experience and one elsewhere with no experience of our systems or processes and only half with experience of the target technology. That caused me to scratch my head for a while.
What we did was this. We defined the process that we wanted including technologies, quality thresholds, management interfaces, points of contact etc. We defined the architecture of the work that we wanted to do and specified the high lever design & business rules that needed to be implemented. The local team was re-focussed on QA & design. We packaged up the work and passed it to the offshore team. They worked on it (low level design, code, test cases and test harnesses) and sent it back. The two teams worked hand in hand to refine the working process. The first month was hell for both sides. 90% of all the work was rejected for one reason or another. We took a zero tolerance attitude to errors but - critically - we kept stressing that we were making progress and that the tough reviews were necessary. It is easy to feel that your work is being deliberately blocked, and we had to counter that. After two months the reject rate was still at 50% but suddenly, with about a month to go, it dropped sharply to around 5%. That co-incided with both teams having worked through the entire process.
Because of the speed of setup, we had to use different source control systems. That was a big problem, but because we had defined our interfaces and processes well and had the offshore team write everything, including regression tests and build interfaces, when we 'landed' the final delivery, it integrated almost perfectly with our processes and we hit the deadline.
Subsequently, the error rate on this work has been better than our in-house work.
Downsides ?
* The local team hated being full time reviewers for that first month. So much so that we lost a senior person.
* We lost the offshore developers. They moved to another project and as a result, all of that effort aligning them with our processes was lost.
* I think the remote team felt a bit like a production line at times.
In summary, we made it work. It wasn't pretty and ultimately it cost more than doing it in house, but the point is, it wouldn't have been done at all if we hadn't outsourced it. To date, no one in the local team has been replaced by outsourcing and everyone learned from the experience.
If I was doing this again, I would insist on matching working environments and take a much tougher line on tools. The remote team refused to use one of our development tools which cost us a few weeks. I would also insist on exchanging developers between the sites to kick the project off.
Woodentongue
Monday, March 15, 2004
> it cost more than doing it in house, but the point is, it wouldn't have been done at all if we hadn't outsourced it
This simply does not make sense. If you could not have done it in house then, by definition, it has cost you more to outource it because your in house cost would have been zero.
Monday, March 15, 2004
Out of curiosity, why did they reject one of your devtools? That sounds unusual; did they complain it was badly documented or did not work well for them? Well, if you mean an IDE, I can see that happening.
And the rejected code -- did it have poor style, or just didn't mesh with your conventions? Thanks in advance.
Tayssir John Gabbour
Monday, March 15, 2004
Now now ladies. ;¬]
For any software product, coming up for a new release there are two sets of changes.
* Those that must be done in order to generate or protect revenue which you know has a high probability of arriving.
* Those that would be nice to do which might generate some more revenue.
When you have more work in the first category than you have staff to write the code, then you find another way or loose revenue.
Woodentongue
Monday, March 15, 2004
There was an element of stylistic differences but those were a small proportion. The rejected code (& designs, test harnesses) didn't meet our standards, procedures, guideline documents, interface conventions, etc. We thought that it was critical for integration and future maintenance that our standards were followed. That isn't to say that we refused to accept any local differences, the standards that I refer to are at a fairly high level.
In terms of the tool, it didn't work well in their environment. With time and dedicated effort we could have changed that but we let it go.
Woodentongue
Monday, March 15, 2004
What sort of tool are you talking about? Was it a library, a code generator, or IDE? If it was the latter I hardly see why it would matter.
T. Norman
Monday, March 15, 2004
Wipro and friends have been very busy as of late given the wide number of "How we made outsourcing work!" messages appearing on the various forums.
.
Monday, March 15, 2004
FullNameRequired, you are obviously in the wrong job. Logic is required to produce software and you know none. The sentence was entirely about cost, not whether they should have done it or not.
Monday, March 15, 2004
I just don't get it. Granted, I am an American but how can this be an example of how outsourcing "works"?
>In summary, we made it work. It wasn't pretty >and ultimately it cost more than doing it in >house, but the point is, it wouldn't have been >done at all if we hadn't outsourced it.
I thought that the reason people outsource is to SAVE money?
>The first month was hell for both sides. 90% of >all the work was rejected for one reason or >another.
...
>After two months the reject rate was still at >50% but suddenly, with about a month to go, it >dropped sharply to around 5%.
That is alarming. Most of the work was wasted! I hope it was fixed price! And did the standards change for rejection in the last month? I know that when I worked as a consultant if I would have had that kind of track record I would have been thrown out of the place like D.J. Jazzy Jeff out of Uncle Phil's house.
OK, seriously, is this a troll?
Bill Rushmore
Monday, March 15, 2004
Bill, I think you missed the point. The project was to deliver a coherent peice of work with many components, not a stream of peicework where we needed perfection in the first drop coming out the tap.
It took four months. At the beginning we were reviewing everything and making corrections and improvements. For the first month 90% of the work was not acceptable. That effort wasn't wasted, it was learning, quality improvement, etc. We took a firm line on errors, and a firm line on any suggestion that our remote team was 'poor'. It wasn't poor it was learning.
We gradually raised the quality standard until, by the deadline, all deliveries were within our quality threshold. we delivered on time and on quality.
The cost was higher than it would have been if we had done it in-house, but we couldn't do it in house because we had no free staff and a three to six month recruitment lag. The cost was a little more than the estimate - accounting for outsourcing - but not hugely.
Woodentongue
Monday, March 15, 2004
Brilliant astroturfing Woodentongue. So the moral of the story is that outsourcing is great, and if it seems like you're getting a lot of crap, well that's just learning! Oh, and the price might be more than you're expecting, but don't worry it's all worth it.
.
Monday, March 15, 2004
Woodentongue haven't been astroturfing, do you know the definition of astroturfing?
Li-fan Chen
Monday, March 15, 2004
Woodentongue,
I still don't get it. The more you tell me about this the more it looks like a disaster! So it was only a four month project and you spent all that effort to train the offshore group but lost them anyway along with a senior person. You may have won the battle by getting the project done on time but a few more victories like that and you will loose the war!
>we had no free staff and a three to six month recruitment lag
Now days you can get a whole bunch of contartors in just a few days.
BTW, I am not one of those "all offshore outsourcing is evil" people, just the opposite. I just don't see how this is good example of how it works.
Bill Rushmore
Monday, March 15, 2004
Yeah. This sounds awful. It appears that it took 3 months to adopt you're standards, and in the meantime most work was rejected. And since I expect there is in general a day or so delay in feedback, really entire days and weeks of time were pretty much wasted writing software that was useless to your system. With a local team you have a really tight feedback loop. This improved communication would have had people humming along on the same standards in a few days or a week.
Oren Miller
Monday, March 15, 2004
If success is determined by the completion of a project -- most people for or against outsourcing agree that the remote team can "succeed" by that definition. They'll complete the project, given enough time to do so and sufficient involvement of the local developers/managers.
However, for offshore outsourcing, real success is not just about whether they completed the project, but also whether they did the project cheaper than it could be done in-house, after accounting for the costs of communication delays, management and coordination overheads, learning curves, etc. On that basis, the success is very elusive.
NoName
Monday, March 15, 2004
>but we couldn't do it in house because we had
>no free staff and a three to six month recruitment lag.
That sounds highly wierd. Was this because of an HR
policy that you felt you could not change?
son of parnas
Monday, March 15, 2004
"* The local team hated being full time reviewers for that first month. .
and...
* We lost the offshore developers. ...All of that effort aligning them with our processes was lost."
This illustrates the reason that I've not done any outsourcing (domestic or international) with my sw company:
There are two types of knowlege your sw engineers can have: Technical "solution" knowledge (C++ expertise, Win32 API, whatever) and "problem"knowledge: knoweldge of the problem being solved.
The problem-domain knowledge is much more valuable and rare and has a greater impact on the solution.
Technical knowledge is much more of a commodity. You can find BOOKS and CLASSES on the Win 32 API, but I can't find a book on how to write speech therapy software. If there were a book, the market would be too mature and have no room for another competitor.
When you outsource programming, you lose that knowlege of the problem domain that can make your products unusually good in order to save money on the part that really doesn't add unique value.
This is just a long way to repeat what Joel said: Don't ousource your core competency.
Mr. Analogy (formerly The real Entrepreneur)
Monday, March 15, 2004
Woodentongue,
Nice post about your personal experience! That said, I have to agree with some of the previous posters, your post is NOT a good example of how to successfully do business with an offshore company.
Forget what I just wrote. What I meant to write is this, "I don't agree with your point-of-view, however, I suppose some people will agree with you and believe that the example you provided is a good way of doing business with an offshore company.".
One Programmer's Opinion
Monday, March 15, 2004
A lot of offshoring seems to involve extra or changed work by the local developers to "make it work."
No-one seems to ask why it should be made to work, except the drop kicks who order it to be done, and the salesmen from the offshorers.
Monday, March 15, 2004
This sounds a lot like the outsourcing we are doing. management decided to save money by firing all the programming staff and outsourcing. Two guys were kept as senior design engineers and they would produce the documents required be the offshore body shop. Well, experience soon showed that the only way to get acceptable results was to do a detailed design to give to them. By this I mean, specify all the classes and modules and exactly how they work. If you have ever done this, you know it takes more time than writing the code from scratch. So what we do now is write the code ourselves from scratch, then reverse engineer the detailed design documents from the code, then send it to the offshore shop. They work on it for a few months and return their code, which is always screwed up and fails QA. As w e get reports back from QA, we remove the offshore code and replace it with the code we wrote to produce the detailed design. Oh, did I mention we had to hire two more 'senior design engineers' to keep up with all this high level design work? The good news is that we are making higher salaries than before. The bad news is that the project takes twice as long and costs more than three times as much as it would have to do it with the team we used to have. No matter - management is thrilled with the 'significant cost savings due to outsourcing' - at least that's what they tell the shareholders when justifying their big bonuses.
Toby Brodderick
Monday, March 15, 2004
"So what we do now is write the code ourselves from scratch, then reverse engineer the detailed design documents from the code, then send it to the offshore shop. They work on it for a few months and return their code, which is always screwed up and fails QA. As w e get reports back from QA, we remove the offshore code and replace it with the code we wrote to produce the detailed design."
you are either genuinely stupid, or lying through your teeth about this :)
Id love to know which it is.
FullNameRequired
Monday, March 15, 2004
No lie! And we're not stupid either - we've kept our jobs while it's an outsourcing bloodbath for others. Why do you think that is a stupid thing to do?
Toby Brodderick
Monday, March 15, 2004
"Why do you think that is a stupid thing to do?"
umm...mostly I think its a stupid thing to lie about.
if _2_ of you can write the entire thing then what were all the programmers doing before they were fired? seems to be that if what you are saying is correct then management _should_ have fired them and just hungon to you and your mate who can produce the same amount of code in less time with far fewer bugs.
what was everyone else doing?
There is _no_ way what you have said is true, it defies every reasonable assumption.
OTOH...if it _is_ true then you are writing the application first, then allowing your company to waste a shitload of money getting someone else to rewrite it, then using your code anyway.
Does something about that sound _smart_ to you?
why not just write it, tell your boss "actually we dont need to outsource this bit, we have some working code here" and accept the plaudits (which wil be richly deserved because you will have written more code than the original programming department by yourselves).
You are either a liar, or stupid...OTOH if you were that stupid you wouldn't be able to write all that code, so this leaves only one possible explanation for me.
(sorry)
FullNameRequired
Monday, March 15, 2004
FullName, you clearly do not understand software development. I think that's been said before.
Mr Broderick's comments make complete sense to me. That's exactly the way dumb managements work, and it's also what a lot of the Indian firms are about.
The big Indian outsourcers are characterised by large numbers of developers with just a year or two of experience. They are also characterised by strict hierarchical divisions of labour, and the poor developers get told to shut up and do what the Western customer wants.
Monday, March 15, 2004
"FullName, you clearly do not understand software development."
clearly not :)
"Mr Broderick's comments make complete sense to me."
jolly good. So which do you believe it is? are he and his friend _really_ writing the application first, then getting the remote programmers to rewrite the code anyway?
do you believe that is intelligent behavior on their part?
do you believe that the programmers that were fired were even _needed_, given that he and his friend are able to write the application on their own?
"That's exactly the way dumb managements work, "
ahh...so we are agreed that it is bloody stupid then? the only disagreement you and I have is on how to parcel out responsibility?
"and it's also what a lot of the Indian firms are about. "
interesting. <g> having personally lost work to indian outsourcers I know for a fact that at least one of my clients (I still do certain types of work for them) is extremely happy with the indian programmers.
Still, its not hard to believe that there are incompent indian companies out there, they seem to exist everywhere else so why not in india.
OTOH surely they are not to blame in this case? we have here two programmers who are not telling their management that they are _actually writing the application themselves_
Again..if thats possible then (a) what were the programmers that were fired doing anyway and (b) wtf are they still getting the remote programmers to write the code for anyway?
Howver you slice it poor old toby is either being incompetent or he is making this story up.
"The big Indian outsourcers are characterised by large numbers of developers with just a year or two of experience."
sounds likely given the growth in that industry over the last few years...america was in a similar situation a while back IIRC.
"They are also characterised by strict hierarchical divisions of labour"
sorry..Im not entirely sure how that is relevant to tobys story...Im also not entirely sure that is correct, Ive heard very different ideas on that from...well...dare I say it...indian programmers...
"and the poor developers get told to shut up and do what the Western customer wants."
:) now _that_ I believe, sometimes its the only way to stop programmers from whinging.
FullNameRequired
Monday, March 15, 2004
There are four of us in this department writing code now. There used to be seven here - five were laid off. The two senior developers were kept and promoted. The two new guys are better than the five guys who were laid off.
Do I think it is a stupid inefficient practice to do it this way? Yes, of course.
Why don't I tell management? Um, are you following this? Management is not too bright. If we tell them what is going on, they will not understand it. Probably they will lay us off, understanding only that not all developers are needed, so they'll want to keep the least expensive ones. That's how they think. They are very happy wih their tremendous cost savings from the offshoring. After all, the offshore guys make less per hour than the five guys who were laid off. "You do the math," as management likes to say. It makes sense to them, it makes sense to the board and to the shareholders. And it's the big thing. Everybody knows you save a bundle doing it this way, so that is their reality. There is no talking sense into people going with the lattest fad. I remember telling my uncle "There is no way it is cost efficient for people to buy dog food through the mail." That didn't stop him from sinking his retirement into pets.com and losing it all. Don't try and tell me that people following the latest craze are rational.
Our interest here is preserving our own jobs. That we get to continue being developers, even by stealth, is simply a bonus.
Toby Brodderick
Tuesday, March 16, 2004
"five were laid off. The two senior developers were kept and promoted. The two new guys are better than the five guys who were laid off."
so management were entirely correct to fire the other 5 guys? they were in fact an entire waste of space. So far management is looking good, they realised that they were employing a not-very-useful bunch of programmers and fired the lot of them.
"Why don't I tell management? Um, are you following this?"
extremely well, thank you :)
"Management is not too bright. "
heh
" If we tell them what is going on, they will not understand it. Probably they will lay us off"
Id fire you too at this point, how long have you been wasting their money like this?
Still, it may not be too late. go to them. show them the code you have written for the next bunch of outsourced requirements, explain that its sufficient on its own and that you dont need the outsourcers to write any code at this point and that you will begin writing out the design for the next phase for them to do.
"Our interest here is preserving our own jobs. That we get to continue being developers, even by stealth, is simply a bonus."
you are, clearly, making this all up. you are absolutely full of it.
Im not entirely sure what point you believe making a half-assed story up will prove, but I assure you its not being made.
You are a liar.
FullNameRequired
Tuesday, March 16, 2004
This is an interesting idea: you write the code, they write the code, the best code wins. Double coding is an acceptable practice in some areas, but I expect that here it isn't.
To get back to the topic . . .
I think that the project itself was a success. We delivered the software that we had to deliver, and we delivered a capable offsite team which could just about manage its own work by the end of the project.
We kind of lost the peace by letting that team go, but that's another story.
Ian.
Woodentongue
Tuesday, March 16, 2004
I believe Toby's story because I am going through something similar. There is a project going on to upgrade a system to the next version of the tool & language and to move it from client-server to 3-tier.
The code changes involved are mostly mechanical and repititive. It has been decided that the subjective/complex changes will be done in-house, and the mechanical-repititive parts will be done offshore. Normally that would be a good reason for sending it offshore, except.... I found that the repititive changes are so repititive that they can be automated. In less than a week I could write code to parse and make the changes.
I've been trying to convince them it isn't necessary to go offshore because it can be done so quickly if automated. But they DON'T WANT TO HEAR IT! The way they talked to me, it's almost as if they were threatened by my suggestion and made me feel threatened if I brought it up again. It's not even that they had doubt as to whether I could do it. Half of the >million lines of code in the system are from a code generator I wrote, and I've also written parsers to aid in the code generation and analysis. Plus another guy on my team has experience writing a similar automated code converter (using awk and sed if I remember right) *in the same company and the same language* a few years ago!
Sure, there is additional effort involved; the converted code would have to be inspected and tested. However, whatever goes offshore will be inspected and tested in-house anyway when it comes back.
These managers are gung-ho about offshoring and they don't want anything to jeopardize their ability to show "savings" from offshore. They'll go ahead and spend hundreds of thousands to send the thing offshore, because they think that every man-hour spent offshore is money saved. At least they aren't firing anybody in order to send it offshore - they laid off people last year already.
Normally I'd just write the parser/converter anyway just to show them ... except that I'm too involved in another project to spend the time to do this (whereas if I had management approval I could acceptably delay my involvement on the other project).
However, there is a silver lining. There is about 30% or so of the code base that has a chance of not going offshore, for other reasons. If it stays in-house, I may be put to work on that part of it, in which case I'd have the chance to write the converter to take care of the repetitive aspects.
Like others here have said .... corporations are run by individuals, and individuals will make decisions based on what makes the individuals richer and not what makes the company richer. If some people can get bonuses by showing savings from offshoring, they will do that even if it means losses for the company as a whole.
Names withheld to protect the guilty
Tuesday, March 16, 2004
I think you nailed it early on: fear. There are vested interests and no one wants to admit they were wrong and give you credit for saving $$$.
Woodentongue
Tuesday, March 16, 2004
Names withheld to protect the guilty,
I think that your management probably considered that a test project. In that case they will not go with a big project first. It is good for them that you have the knowledge and experience to "save" things in case offshoring doesn't work well.
I don't think all offshoring fails with certainty. In fact I am pretty sure it pays well enough in the long term. Big companies are doing it for years. If it constantly fails don't you think thay would have abandon it?
One thing to be noted is that many companies "go offshore" when things are going really bad for them. In many such cases it is a failure beforehand. Wise management must anticipate trends earlier and act accordingly.
Best Regards,
doesn't_really_matter
Tuesday, March 16, 2004
Woodentongue,
Since you define this project as a "success", I can only hope you are working for one of my competitors.
Bill Rushmore
Tuesday, March 16, 2004
Bill,
We delivered extra functionality that customers urgently needed, to time and to quality, with minimal post-live defects. Our work drove new sales in a downturn. We preserved our core team. Everyone was happy.
So, I hope I am working for one of your competitors 'cos if you don't think that's a success, then we're coming for your customers . . .
Woodentongue
Tuesday, March 16, 2004
and another thing
The point of outsourcing is not to 'save money'. If you want to save money, just sell your company and open a deposit account with the proceeds.
The point of outsourcing is to reduce the cost of delivering software. In my case we could not deliver software in-house, we were out of capacity. The cost of not delivering the software was millions of dollars in lost revenue. So we added capacity and that capacity cost a little more than usual. I appreciate that this needs some lateral thinking vis-a-vis finance.
An analogy is a website. You run some fansite which gets 100 hits a day and makes $50 a week selling TShirts. Suddenly, you find that the subject of your site hits the bigtime, you have 1M hits a day and orders for 10,000 TShirts. Your web host and will up their charges, and you have to 'outsource' your TShirt printing, but as long as you can sell at a profit, you would be dumb not to cash in, right ?
Woodentongue
Tuesday, March 16, 2004
I think the point was that you said that you guys ended up basically writing the whole code anyway. So you may have saved some money by laying off the other programmers and outsourcing but you could of saved even more by just laying off the programmers - getting the new recruits in and writing the project yourself as you did anyway. If you hadn't said that the majority of the work the outsourcers did was useless then it could of been deemed a bit more of a success - but for me i would say that your company did right by getting rid of the useless programmers and recruiting a few really good ones - but doing outsourcing when you have said you basically had to write the whole spec in so much detail that you were actually doing the code sounds like to me you guys should of said this to the bosses - who should have dropped the outsources and thanked you guys for saving them a whole heap of cash.
Just my 2p
Fothy
Tuesday, March 16, 2004
The five guys laid off were not 'useless'. They were great guys and really good. But the two have been hired since then are better. Much more expensive too ($120) - two of the guys let go didn't have degrees and they were substantially underpaid as a penalty ($35). The other three guys made $50-65.
Toby Brodderick
Tuesday, March 16, 2004
I think you're missing the nuances of business that are going on right now. Us telling management that we are doing all the real coding is not going to go over the way you say where we are congratulated and given hearty raises and promotions and a ticker tape parade. We will most likely be fired for saying the emperor wears no clothes.
Management HAS to offshore development because everybody knows that that's absolutely necessary to be competitive in today's global economy. This is the 'known fact' which may not be questioned. Offshoring MUST occur. If we point out that offshoring is pointless or a waste of money, we will be let go because the offshoring MUST occur. Do you see what I am saying? Offshoring is the constant, the given, the unalterable truth. And it is saving the company millions of dollars. Whether it really does or not is totally beside the point. Offshoring is saving us millions. You do the math. It's the latest thing. Everybody knows the other developers are cheaper and better at this low level machanised code assembly from requirements that management believes, knows to be a fact.
Toby Brodderick
Tuesday, March 16, 2004
Well if the management truely think like that then surely your jacket must be on a loose peg then?
It sounds to me like a place i wouldn't be wanting to work - start looking elsewhere - if management are so blind that they are wasting loads of money on outsourcing when the inhouse guys are doing it themselves anyway.
And by saying the previous guys were useless - then ok they might not have been useless but they weren't up to the job when you let go 5 and brought in 2 more experienced guys - who along with you 2, could do all the job themselves.
Fothy
Wednesday, March 17, 2004
Frothy, I don't know if your comment referred to my contribution. There are two examples here, mine and a 'we wrote it anyway and threw away the offshore deliveries'. I would like to draw a distinction between the two.
Woodentongue
Wednesday, March 17, 2004
Oren said "Yeah. This sounds awful. It appears that it took 3 months to adopt you're standards, and in the meantime most work was rejected."
How long does it take a new recruit to get up to speed ? If you can do it in three months to the point where they can work without close supervision, you've done well.
The point is when we were rejecting work, we were building capability. The work wasn't wasted. In my experience, work can be rejected because 5% of it is not adequate. "Reject" does not mean "Reject and erase" it means "reject and rework".
Woodentongue
Wednesday, March 17, 2004
My reply was to the Tony one just above my post.
It states that offshoring MUST occur and is the way forward etc - i presume that is supposed to be written as the managers opinion - and my point was that if the managment couldn't accept that it didn't really work in this case since the new programming team did it all anyway then they aren't worth working for. Creating the new programming team was a great idea as it sounds like that worked really well - 2@$35 + 3 @$50 = $220 and spending $20 more to get 2 more experienced programmers who helped get the job done (where 5 others could not) was some good management but for them to not be able to accept (if told) that the outsourcing work could have been scrapped and all done in house seems strange to me.
Fothy
Wednesday, March 17, 2004
It seems strange to you, but there are many things that are strange but true. Never underestimate the power and will of managers to fatten their own pockets at the expense of the company. If managers like that didn't exist then Enron and Worldcom wouldn't have happened.
If the in-house programmers did the project in a week with one hand tied behind their backs, it would just be "business as usual" and there would be no big savings to claim for the purpose of getting a bonus. Whereas when the work goes offshore the managers have something to point to demonstrate savings (even if the reality is that it could be done quicker and cheaper in-house) by comparing per-hour rates.
NoName
Wednesday, March 17, 2004
It is true that many people - not just managers - take action that are bad for the company and good for themselves.
Such people are inherently selfish and rarely thrive. The greatest benefit comes from working towards one objective, not conflicting ones. I find a policy of non-co-operation with those people is most effective.
Woodentongue
Thursday, March 18, 2004
 Recent Topics
Fog Creek Home
|
