11

I had been tasked with managing a project which was outsourced to some Ukrainian developers.

The company hired them through Elance at a fixed price. At that point my boss left me alone to handle them and get the work done. I created a detailed specification of the complete thing that needed to be done.

The project involved dealing with such things as XMPP, RabbitMQ, and Database. In my first meeting with them (always IM) I explained thoroughly what they needed to do. They seemed to understand it -- and they were very confident that it would be done easily.

So far so good. But after one week, when we met again, they were full of misunderstandings about what needed to be done. When I asked one of the developers if he knew XMPP, he said he was working with it for the first time. At our first meeting I'd very specifically mentioned the complexity of the project and the technologies involved. Plus, I had repeatedly asked them to write a functional specification of exactly HOW they would do it. But they said NO, and insisted that they would rather write the code. I said OK.

The project completed after 3 weeks and they delivered what was needed. At that point I started to review the code. It was okay for the most part, but there ware some important problems:

  • they hard-coded some of the things that needed to be separated out into a config file
  • there were multiple config files that I needed to be consolidated in one
  • they wrote absolutely NO documentation
  • some other minor changes

I asked them to make these changes (except documentation) -- And, we had an argument.

They said, since the price was fixed, I was being unfair in asking them to make any changes once they completed the working code. That they had worked for unreasonable amount of time on the project and now it was completely wrong to ask for anything.

Finally now they have made the changes, and the project is over. But it leaves some questions in my mind...

  • They did what was needed but I needed it properly done, and hence the changes. was I really unfair?

  • Why did I agree on letting them code without having a functional specification?

  • Why did I not make sure that they understood everything the first time?

Does anyone find themself in the same position? Do you think there is a better way to manage outsourced projects?

-- UPDATE --

Thanks for all the opinions -- after reflecting upon entire experience, I can conclude...

  • Although I wasn't vague in the specifications from my side, I certainly didn't make them ironclad as suggested. So the take away is: always be as much specific as possible -- read your specs from their perspective too and see if you missed something. Repeat it at least three times.

  • Just specifying what the code should do it not enough. You must specify what the code is supposed to look like. What the directory structure will be; even the file names if possible. This will save you from lot of annoyance later. Strictly specify the coding guidelines, variable naming conventions, internal documentation format, etc. See to it that they abide by those guidelines, and if not, scream.

  • Demand a functional specification from their side -- insist that it be written before any code. This will get a lot of confusions and misunderstandings out of the way.

  • Review the code as it is being developed so that you identify the anomalies earlier and get them corrected. Talk to them at least once every other day.

  • Lastly, try to make a good rapport with them. Make them feel that you appreciate their work. Don't push them exaggeratedly to fit your guidelines -- instead request them to do so and tell them that it would make maintaining the code so much easier for you once they complete the project.

treecoder
  • 9,475
  • 10
  • 47
  • 84
  • 1
    I have never seen an offshore project go that well. I thought I was in for a war story when I started reading this. – smp7d Mar 01 '12 at 20:42

5 Answers5

17

I needed it properly done

Then don't outsource it, or if you do then make sure they work in your project team and that you participate in code reviews at the time.

The project completed after 3 weeks and they delivered what was needed. At that point I started to review the code.

Again, you should have been reviewing code during the project, not after.

They said, since the price was fixed, I was being unfair in asking them to make any changes once they completed the working code.

You paid them fixed price for working code. Oops. That isn't their fault, its yours. Pay for their time to participate in sprints that you control and you won't run into this problem. You should pay them for the time and accepted user stories, not for code.

In my first meeting with them (always IM) I explained thoroughly what they needed to do. They seemed to understand it -- and they were very confident that it would be done easily.

When dealing with a completely outsourced project, you need to make sure your specifications are ironclad. If you have to explain anything that takes longer than a few sentences, then your spec is not complete. This is why they veered from the spec.

When I asked one of the developers if he knew XMPP, he said he was working with it for the first time.

It is common when outsourcing to popular low cost offshoring countries for developers to overinflate their resumes and skills just to land the job. They often don't worry about their abilities until they land it, becuase many of them are just resume building to land the gig that actually pays a comfortable living wage.

Why did I agree on letting them code without having a functional specification?

Only you can answer this for yourself, but take it as a learning experience for next time.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 2
    I disagree with "If you want it properly done, don't out source it". – Morons Mar 01 '12 at 18:23
  • 1
    @Morons Your right of course, that was a lazy thing to say. I just default to that frame of mind because the companies most attracted to the prospect of offshoring are the very ones who most lack the discipline to do it correctly. If they solved their internal problems to where they could do it correctly, then they would probably have less need to even offshore in the first place. – maple_shaft Mar 01 '12 at 18:29
  • 3
    It should say *"If you want it properly done, don't expect quality from the lowest bidder"*, a friend that is a freelancer photographer says *"The cheapest customers, have the most unrealistic expections"* –  Mar 01 '12 at 18:54
  • 1
    I also disagree with that statement, you can have the exact same problem with internal teams or local development shop. –  Mar 01 '12 at 19:25
13

First off this is not an issue of off shoring, it’s a vendor management issue

Yes, you made ALOT of mistakes…

They did what was needed but I needed it properly done, and hence the changes. was I really unfair?

Yes, it is fair, If you wanted it done a certain way you should have said that before the price was agreed to, so they can bid accordingly.

Why did I agree on letting them code without having a functional specification? Because you didn’t want to PAY for the spec! Documentation is time consuming and expensive, should they just do it for free?

Why did I not make sure that they understood everything the first time?

They did understand. But on your fist meeting AFTER the contract was signed (and the fixed price agreed to) is when you EXPAINED IT! So the needed to cut cost (hours) where every they could.. Basically by only holding one meeting a week, not giving any confutation options.

Here is how to do this next time… In Two phases…

Phase 1: Have them Gather the requirements, perform the systems analysis and write the Technical Design and\or functional Spec (Or write it yourself). Agree on a price for this Phase. Be sure to explain there is no commitment on your part to give them the development phase. Be sure to include time for meeting in the price.

Phase 2: Have them bid on the developed based on the spec now that they (and you) have, and really know the effort is involved. Again be sure to include time for meetings in the price. Because to include a small optional budget for changes.


Edit: I want to add an additional point.. The vendor is also at fault here, part of there job is too help guide you with the project management, and let you know where there are short coming in the process.

Morons
  • 14,674
  • 4
  • 37
  • 73
  • 2
    You forgot phase 3 and phase 4: **???** and **Profit** :-) – Ramhound Mar 01 '12 at 17:20
  • 3
    How can you ask an outside entity to write your functional spec? The functional spec **are the requirements** of the very project that you want them to work on. Otherwise you are giving them money and telling them, "Solve a problem, ... I don't know, figure out what the software should do, I can't be bothered." – maple_shaft Mar 01 '12 at 18:04
  • 1
    @maple_Shaft Good point, Requirements gathering is part of the Phase 1. I'll update my answer. – Morons Mar 01 '12 at 18:21
  • 1
    -1 for the outdated Waterfall dogma crap –  Mar 01 '12 at 18:51
  • 3
    @JarrodRoberson I'm not a fan boy of any particular methodology. Each has it's merits, but say they failed simply because they didn't use Agile is wrong. – Morons Mar 01 '12 at 18:55
  • @Ramhound phase 3, 4, 5, N are do it all again, because the expectation that you get the spec correct the first time is a false one. –  Mar 01 '12 at 19:01
  • @Morons I didn't say that, Read for comprehension. I said they failed because of mis-management. That mis-management in this case was following a black box waterfall model. I proposed an alternative to be successful. Re-read my updated answer and then tell me that every other custom building industry has been getting it wrong forever. –  Mar 01 '12 at 19:03
  • @JarrodRoberson Every other custom building industry used waterfall. (I'm not saying it for IT Projects but just that it is the case) Any BLACK BOX methodology is wrong... – Morons Mar 01 '12 at 19:08
  • We can take this to chat if you want to discuss it further.. – Morons Mar 01 '12 at 19:08
7

The company hired them through Elance at a fixed price. At that point my boss left me alone to handle them and get the work done. I created a detailed specification of the complete thing that needed to be done.

So the two of you first made a contract and then they let you write a spec, and they accepted that spec to become part of your contract? If that's how it was, then it is not your fault, that's a fault of your contractor. You could have easily written a spec giving them 3 months of work instead of 3 weeks - all for the same price.

It was okay for the most part, but there ware some important problems:

  • they hard-coded some of the things that needed to be separated out into a config file
  • there were multiple config files that I needed to be consolidated in one
  • they wrote absolutely NO documentation
  • some other minor changes

Were these things part of your spec? If they were, it is their fault. If not, it is yours. If it was not really clear if these things are contained in the spec, then it is also your fault, since you wrote the document. Try to write a better spec next time.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
3

I did a presentation a while ago about offshoring. It was called "Global Outsourcing, 10 tips to empower your business". Here is a summary of the 10 tips (this comes from up to 400 outsourced projects):

A. Choice

  1. Avoid the lowest and highest bidders. This is just obvious, you don't want to take risks with lower bidders and highest bidders tend to be less valuable (value/price) than the median.

  2. Check ratings (or references). I always check references & ratings.

  3. Prioritize motivation. At equal price, I pick the bid that was motivated. For example having the bidder talk about your project right is a very good sign.

B. Supervision

  1. Protect your intellectual property. This is one of the biggest mistake. Usually handled by the platform you use (such as vworker or elance).

  2. Refuse custom frameworks. Or you risk to be tied to it, or more specifically to the developer that wrote it ;)

  3. Impose standards. Related to previous tip. Using standard increases the value of your source code as it is understandable by a larger amount of developers.

  4. Review early, review frequently. Most problem can be "adjusted" if you review the source code after the first week or work.

C. Strategy

  1. Test providers with small projects. Before I give a big project to a provider, I test it with one or two smaller projects.

  2. Accept multiple bidders to reduce risk. For critical project, I select two or three bidders then I take the best implementation. Work best with small projects (under $5000).

  3. Assemble components. Another strategy is to outsource components that you assemble later. One advantage is that you can easily switch between providers and none really get access to the whole thing (reduce intellectual property risks).

1

I entirely agree with maple_shaft's answer.

You accepted the code and I assume wrote the check, then reviewed the code, you sort of did everything backwards.

Why did I agree on letting them code without having a functional specification?

Because you didn't write it into the contract. Since you wanted the work done, you accepted their reasons, even though its the very thing that got you into trouble.

Why did I not make sure that they understood everything the first time?

You should have provided them a design you felt would have worked. Then it wouldn't really matter if they didn't understand fully. I mean you didn't pay them to do it so who is going to do it? How is this code going to be maintained without any documentation and design specificiations. The answer it likely won't be.

They said, since the price was fixed, I was being unfair in asking them to make any changes once they completed the working code.

You are lucky they made the changes you wanted. They could have said: tough luck

Does anyone find themself in the same position? Do you think there is a better way to manage outsourced projects?

Of course other people are in your position otherwise, the entire "outsource" industry wouldn't be hurting, many companies are starting to realize having to pay ( or wait ) to do it 3 and 4 times is more expensive then doing it right once.

At least by doing it yourself you can check the status of the project daily. If you are behind there are things you can do to control the damage, at least in theory.

Ramhound
  • 871
  • 8
  • 12
  • 1
    `companies are starting to realize having to pay ... to do it 3 and 4 times is more expensive then doing it right once.` It is more than this, I just think that the industry honeymoon phase with offshoring software development is coming to an end and more companies are starting to realize that it isn't the golden calf that they thought it would be (*or were told it would be by consultants*). Most management sucks and they have no idea why, so they look for the silver bullet du jour to solve all their problems. Offshoring is great if you do it right, but most don't have that kind of discipline. – maple_shaft Mar 01 '12 at 18:12