Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by Jarrod Roberson, tdammers, ChrisF Mar 1 '12 at 23:28

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

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 1 '12 at 20:42
add comment

6 Answers 6

up vote 12 down vote accepted

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.

share|improve this answer
2  
You forgot phase 3 and phase 4: ??? and Profit :-) –  Ramhound Mar 1 '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 1 '12 at 18:04
1  
@maple_Shaft Good point, Requirements gathering is part of the Phase 1. I'll update my answer. –  Morons Mar 1 '12 at 18:21
1  
-1 for the outdated Waterfall dogma crap –  Jarrod Roberson Mar 1 '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 1 '12 at 18:55
show 4 more comments

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).

share|improve this answer
add comment

Waterfall fixed price projects always fail! Neither side will be happy and one or both sides will feel taken advantage of or cheated. You will never get quality this way, you will get a rushed incomplete job as you have discovered. No exceptions!

They should have never agreed to a price blindly, you should have never agreed to pay for a deliverable blindly.

This has nothing to do with "off shoring", and everything to do with mis-management. They could have been on the other side of the building, and if things were managed this way they would have turned out exactly the same.

This is where what the software development mavens call Agile; shines. For success:

  1. Be prepared to pay for incremental results.

  2. Collaboratively plan a week or two weeks worth of work, never more, you tell them what is important and what you want first, they tell you how much of that they can reasonably get done in the week/two week time frame. They have to commit to the deliverable, you can't dictate what it is. This is a mini-contract.

  3. Get the deliverable at the end of the week(s), pay when they meet what the committed to and demo it to you, no sooner. Be prepared to not pay them until they meet their commitment.

  4. Be prepared to fire them at the first sign of incompetence. You should not pay for training them to learn something they said they already were skilled at.

  5. Be prepared to drop requirements if they don't fit into your budget.

  6. Be prepared to pay more than what you thought it would cost for a feature, because you were probably wrong.

This will be cheaper in the long run than a waterfall fixed price agreement, you will get what you want and expect, they will get what they want and expect.

You will have a greater chance of calling the project a success with this approach.


This is a proven approach in every industry outside the Software industry

This is how every true engineering project works.

For Example: Do you think custom houses get built without constant review and feedback ( iterations ) from the people contracting the builders?

I know when I built my custom home, I went and reviewed what was being done at least twice a week. We met with the building contractor every week and talked to their on-site person every couple of days.

Yes, we had detailed architectural plans and specifications, but there were still mis-understandings and mistakes and some plain old change requests because of things we didn't think of or forgot or changed our minds.

They told us what was going to be done the next week or two so we could think about it and make sure we were getting what we wanted and we would know what to be looking for when we walked the job site.

We caught them as they happened and didn't have to deal with them after the fact when it was either to costly or just impossible to fix.

Software development methodologies call this "Agile", everyone else calls it common sense. It isn't a fan-boy process, it is what reasonable successful companies do in other industries and have been doing forever.

share|improve this answer
1  
Waterfall fixed price projects always fail! Only Joel Spolsky can get away with making broad generalizations like this. It would be better to say almost always :) –  maple_shaft Mar 1 '12 at 18:15
2  
Well, you can, but then you have Apollo which landed a dozen people on the moon in 8 years or so at the cost of a "zillion" dollars. That they accomplished the goal with a ridiculous budget and killed people along the way doesn't make it the poster child for success. –  Jarrod Roberson Mar 1 '12 at 20:06
1  
@Pierre303 But if you think about it, there were 10 rather quick sprints, the first one being a complete disaster. If it was Waterfall, it was done iteratively ;) –  maple_shaft Mar 1 '12 at 20:13
1  
-1 for projecting your own incompetence upon others' abilities. Waterfall-like processes work very successfully for many companies. If it didn't then it wouldn't be used, and widely used at that. Also, I would never hire your company because I want to know exactly what my money is going to give me before I hire you to build a product. Your building me 50% of an application, like building only 50% of a house (because that's when the money ran out) doesn't do me any good as a customer. –  Dunk Mar 1 '12 at 21:20
1  
@Dunk Your lack of comprehension is showing, if you tell me what to build by what is important to you then 50% of features you asked for complete, tested, working is better ( and customers get what they expected ) than 100% of features 50% complete, un-tested and not working ( not what they asked for or expected )! That is what the entire history of software development done and waterfall has been, it well documented, there are many books written about it. There is a reason that the software industry failure is not only accepted but expected. No other industry tolerates that as an outcome! –  Jarrod Roberson Mar 1 '12 at 21:30
show 7 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
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 1 '12 at 18:12
add comment

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.

share|improve this answer
2  
I disagree with "If you want it properly done, don't out source it". –  Morons Mar 1 '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 1 '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" –  Jarrod Roberson Mar 1 '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. –  user2567 Mar 1 '12 at 19:25
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.