Offshoring – A Cautionary Tale

I keep telling everyone how I’ve been outsourcing a lot of my work to offshore workers.  I usually paint a pretty rosy picture, but it has its ugly side.  This week I managed to learn something from it.

As you know if you’ve been following my blog, I’ve had some issues with my offshore development team.  I won’t go into those details again, except to say that it gets better for a while, and then gets worse for a while.  The fact is I could not have gotten the work done for the price I paid any other way.  The ups and downs come with the territory.

Working with non-technical VAs is a little different, and usually not as volatile.  One of my VAs was this awesome guy I hired last October.  Oddly enough he was from India and not the Philippines… I wonder if that was part of the problem…

He was so cheap I almost couldn’t believe my luck when I realized how good he was.  For a long time I had him doing research on clubs, compiling a list of as many clubs as he could find.  After some initial training he was pretty much on auto-pilot for 20 hours a week.

Then I felt that he was starting to lose interest, his work was still good but he wasn’t putting in the hours.  I figured he was bored and I needed some testing done so I put him on that (he had some experience testing).

The first week was great, he did all the regression testing, learned the Bugzilla interface and entered bugs and all seemed fine.  Then I put him on writing test cases.

And he disappeared.

I didn’t even notice.

I was so lulled by his previous competence I just believed he would continue to do what he was supposed to do and didn’t need babysitting.

WRONG.

Rule number 1.  Your offshore VAs always need babysitting.  ALWAYS!

Here’s the story in a nutshell… a week and a half after I put him on test cases, I happened to be on oDesk doing something unrelated, and I noticed his work log was emtpy.  It was halfway through the week and he had not logged any hours.  I looked at the previous week.  0:50 hours.  Huh?

So I shot off an email to him asking what was going on and he got back to me immediately and apologized and said he had personal issues that had nothing to do with work.

I was so mad I fired him on the spot and ended his assignment and gave him a lukewarm rating and UNshared him from all my Google Doc files he was using.

Now I’m a little upset with myself for letting my anger drive such a bad business decision.  It was my fault.  I never should have put him on a critical task.  If he had still been doing internet research on clubs I would have just let it pass and waited for his personal issues to sort themselves out.  Then he’d come back and pick up where he left off at his ultra cheap rate and all would be well again.

Damn.

So to recap the lessons learned…

1. Don’t assign a part-time, low-level, offshore resource to any task you consider critical to your business.
2. Check in with your VAs once a week at minimum.  If they are doing something important, check with them twice a week.  A 10-minute Skype chat works just fine.
3. When a VA disappoints you, don’t do anything until you’ve given yourself 24 hours to cool off and figure out who’s fault it really was.

* * *

Do you enjoy reading these posts?  Subscribe to the RSS feed of The Making of Grouvia.

You can become a member of Grouvia and create your own group in 5 minutes or less.  Sign up for an account at http://www.grouvia.com.

My new site looks like it’s funded.

I recently decided to bite the bullet and commission a redesign of Grouvia.  The current design, although it’s nice, is too complicated and is causing problems with implementation.

I hired this awesome offshore contractor to do the design and I got a preliminary screenshot today.  I sent it to a colleague and we were talking about it, and to one of her comments I said, “yeah, it looks so much better, cleaner… like we’re funded.”

She laughed.

I can’t put my finger on what that really means, but I feel like it’s true.  The new design makes Grouvia look like the other Web 2.0 sites that have been professionally designed… and those designs probably costs tens of thousands of dollars.  This is costing me about $350.  Of course I have to implement it myself, but that’s ok.  If I wanted to I could probably get that done for a few hundred bucks also.

[Speaking of cheap labor, I said to my Dad the other day, “these people are my staff.”  By this I was referring to the subcontractors I’ve hired from the Phillipines, India, and now Belarus (where they heck is that anyway?).  I’m addicted to offshore staffing.  Need something done quickly for practically no money?  Hire a Filipino!]

Anyway, I’m totally thrilled with this new design – I can’t wait to get it up on the site.  It just feels right.  It feels… funded.

* * *

Do you enjoy reading these posts?  Subscribe to the RSS feed of The Making of Grouvia.

You can become a member of Grouvia and create your own group in 5 minutes or less.  Sign up for an account at http://www.grouvia.com.

Development Issues Delay Launch

I hate to say it but we missed our first launch deadline and won’t be launching for a couple more weeks.

The issue has been development but – as much as I would like to – I can’t place 100% blame on the developers.

Grouvia has a lot of bugs and I refuse to launch a sub-part product. I know I only get one chance with my target audience and the level of quality I want just isn’t there yet.

Grouvia has a lot of bugs and the developers haven’t been able to fix them.  They’ll say it’s fixed, we retest… and it’s not fixed.  Worse, we retest these elusive bug fixes and we find more bugs.

Granted, the vast majority of the bugs are minor.  The major bugs have been fixed, or fixed to the point where the remaining issue is tolerable enough to be downgraded.

But there are still too many bugs for us to launch.

I’ve concluded that the best explanation for the development problems are communications issues compounded by language.  I do believe these developers have the experience and skills to do the work.  However, many things point to communication issues as the main reason we are having the problems we’re having…

• Often the implementation of a particular feature does not meet the requirements.  Actually it’s not often, it’s usually.
• Details are missed.  A feature will be implemented but the nuances and logic details aren’t there.  For example, the private events were implemented without any way to invite participants.  It was in the requirements, but they didn’t put it in.  Details are not just nice-to-have.
• The developers make assumptions instead of asking questions.  If they don’t fully understand something, they will make their own decision about how something should work, instead of asking for clarification.
• The technology is driving the features.  If the developer finds that the technology does not support the feature properly, he will change the feature to match the technology.  For example, the messaging feature was changed to match the abilities of the standard Drupal messaging module. This isn’t what we wanted.

I know that many developers work like this.  I have been in this field long enough to have seen this before, lots of times.  But I’ve always been in a corporate environment where I can call a 2-day-long meeting in a conference room somewhere with American-English speaking developers, analysts, testers, and team leaders and hash out the details.

I don’t have that luxury now.  These developers are halfway across the world and our meetings take place over an unreliable Skype connection at 7:00 in the morning.  We have a daily 2-hour window to work together, sometimes a little more if they agree to work late or if I can get up earlier.

But I’m also paying about a third (maybe less?) of what I would have paid for an American company to do the project.  You get what you pay for.  I knew that going in.

Delaying the Beta launch was disappointing but it was the right thing to do and I know we will have a better product because of the delay. I’ll keep you posted.

* * *

Do you enjoy reading these posts? Why not sign-up to receive Grouvia’s e-newsletter? You’ll get the latest news delivered to your inbox and you can participate in the Grouvia development process. It’s free. Sign up at www.grouvia.com.

Alpha Testing, One Week Later

The first Alpha release of Grouvia.com was launched one week ago today.

It’s not a huge surprise that out of all the people who said they would help test the site, only three actually logged in to the site. One person spent a good amount of time and sent us back some great results. The other two spent a minimal amount of time and sent us no feedback at all.

Disappointing yes, surprising no.

It’s early and there’s not a lot to see right now, so I’m not discouraged. We are doing our own internal testing and the developers are working hard to address the issues we bring up. We ultimately decided to rewrite the entire messaging module because the Drupal module had a queer, confusing interface and did not do everything we wanted it to do. So was modified to the point where it is no longer part of the core framework. Oh well.

My most important Aha moment this week for me was this: the decision to come out with a “pre-alpha” release was both a great idea and a terrible idea.

WHY IT WAS A GREAT IDEA
It was a great idea because it forced us to deal with some very difficult development issues early on instead of waiting until 3/4ths of the code was done. We learned from our mistakes, adjusted some things, and now we go forward with new understanding and purpose.

WHY IT WAS A TERRIBLE IDEA
It was a terrible idea from a publicity perspective because we spent a lot of time and effort pushing for signups, crafting and sending announcements, coming up with test scripts, and biting our nail on edge about what people would think. It was like throwing a party and having only two people show up. I’m not sure what I learned from this exercise… maybe a slightly better understanding of human nature and perhaps also a more realistic set of expectations. Every disappointment should be a lesson.

At any rate, at this point I think we have identified all of the issues that we’re going to and we need to move on to the next phase. It was a tough week with a lot of back and forth with the development team, and I’m ready to move on. Alpha 2 is scheduled for a 10/23 release and that will have all the group features. This is exciting because it means we can start forming real groups and having real members. It will be a giant leap forward.

Next week I’ll tell you about my new Filipino VAs.

* * *

Do you enjoy reading these posts? Why not sign-up to receive Grouvia’s e-newsletter? You’ll get the latest news delivered to your inbox and you can participate in the Grouvia development process. It’s free. Sign up at www.grouvia.com.