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.

Advertisements

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.

Release 0.01 – Four Things Grouvia Just Did

We had four really big accomplishments this past week.

1. Grouvia Has a New Development Team

Yup, I pulled the trigger. I hired what I thought was the best development team of the bunch and now I can’t look back. I have to trust that I did the right thing and plunge onwards. I did choose a company from India, in a small industrial town near Utter Pradesh. The company’s name is “SmartData Enterprises” and I found them on oDesk.com. I had also invited a handful of firms via guru.com, but I do like the oDesk development features better. I won’t write about those details here, you can check out the sites if you’re interested. (And if you’re doing that don’t forget to look at elance.com as well.)

Hopefully we will sign the contract this week, so I can engage the developers and walk through the requirements with them. The functional requirements are very good, but they’re not super-tight. I could tweak these requirements until kingdom come and still not be happy with them. So now that the train is on the tracks and moving out of the station, I have little time to dicker around with the documentation, and hope the developers will ask the right questions to get it done the way I envision it.

There is something very satisfying as well as terrifying about this. It’s satisfying because we are taking a major step forward (and I’m a big believer in getting things done quickly). It’s terrifying, well… just being in business for yourself can be terrifying so it comes with the territory.

2. Got the Public Web Site (Mostly) Up and Running
This is not a big deal really, but it was time consuming. Fortunately I have HTML/CSS skills and was able to code it myself. Could I have used my time better? Sure, but I also could be $500 poorer if I got someone else to do it, besides not being certain it would be good code and then not having time or inclination to go fix it. At least now I know it’s good, and I practically did it in my sleep.

Having the web site up allowed me to get the next two items accomplished as well…

3. The Users Are Starting to Gather ‘Round
Another cool thing I did this week was to create a Google AdWords campaign. I developed three different ad groups for different personas: 1) Outdoors Types with an existing club; 2) people who are looking for tips on How to Start a Club; and 3) people who just want a new Club Web Site for Free. (The links go to the different landing pages.)

After four days of watching results, my ads in the #2 group are outpacing the others by a mile. Funny thing is I have no idea why. My “Entrepreneur Magazine’s Ultimate Guide to Google AdWords” book states that you should do “split testing” where you always have two ads up at the same time. Whichever one doesn’t do well gets dropped, then you replace the dropped one with a new one and repeat the process over and over. It sounds a little tedious but I can now see why they say that – because you have no idea what people will respond to, you can only guess and test. I am now a believer in the importance of testing your advertising.

Another thing that’s interesting in all this is the signups. We have received 13 signups so far and need to figure out if that’s a good conversion rate or not. Here are the early numbers:

  • 5,210 Impressions
  • 211 Click-Throughs
  • 13 Signups

That’s an overall CTR (Click Through Rate) of 4.05% and a Conversion rate of 6.2%. That doesn’t sound too bad, does it? The bill so far is about $64 so it’s costing about $5 per signup. It doesn’t sound so great when you put it that way. It’s actually not even that good because I know some of the signups did not come from the ads. On the other hand, I also know that the CTR is getting better as I continue to tweak the ads. For example the current best performing ad is averaging a respectable CTR of 4.59%. What this tells me is that I need to improve my conversions by re-writing my landing pages. Test and tweak.

4. Grouvia Issued its First Press Release and Got Its First Article
Last week, we issued a press release announcing the pre-release alpha site. We also reached out to a number of reporters to start to develop relationships as we move forward. Bill Freehling, a reporter at the Fredericksburg Free Lance-Star, liked the story and contacted me. He even wrote an article, which was in Tuesday’s edition of the paper and can be seen on the paper’s web site at fredericksburg.com.

There are signup numbers associated with the press release and the article, but I’ll report on those next week.

I said it was a busy week, didn’t I? And that doesn’t even cover the 349 other little things I was working on.

Happy Labor Day!

* * *

Choosing My Million Dollar Development Team

This past week was spent collecting proposals for the grouvia.com project, in response to the RFP I sent out last week. I had about a dozen early candidates and two dropped because they didn’t feel they could respond within the very short timeframe I required.

I suppose if I had to do it again (you’d have to put a gun to my head) I’d change my RFP to request that each company put their proposal in a specific format. One of the biggest challenges I found was having to “re-frame” each proposal into a common format so I could put them into kind of a mental comparison matrix. I don’t know if I succeeded that well, and I think when it came down to it I went with my gut feeling about which proposals would ultimately rise to the top of the list. But I believe strongly that gut feelings are generally based in some fact. So after reading each proposal carefully, I had a good sense of what kind of company this was, and whether I felt strongly about them one way or the other.

The three that have made it to the short list are quite different from each other. They each suggested different technologies, they have different approaches, and different personalities. The longest proposal (of the three) is 40 pages long and came with 10 supplemental documents. Another one was seven pages long and I had to go back and ask for some missing information. How am I supposed to interpret that?

BTW I didn’t hold it against any of them for missing information. My turnaround time was very short and they did their best I’m sure. I merely asked for it and they gave it to me.

So here I am with a decision due tomorrow and feeling a little paralyzed by indecisiveness about three major factors:

  1. Drupal vs. Symfony (I know, I know, they’re not the same type of thing!)
  2. Eastern Europe vs. India
  3. Hourly vs. fixed price – there’s more to this but it’s too much to go into here.

Did I mention that none of the US companies I asked to participate responded? The overwhelming majority of the firms are from India. One was from Sweden (they dropped) and one from Ukraine. All their english skills are good, they all offer US based phone numbers, they all work late hours to compensate for the time zone issue. None of the offshore issues are really issues, to me at least. And the prices are all very close, and all within my budgeted range.

So I guess I’ll have to keep you in suspense until next week. If you have any thoughts or commments I’d love to hear them!

* * *