Trying everyday to get a little better

Here’s another one for the outsourcing horror story collection

My friend Matt often complains about some of the outsourced staff he gets stuck with on his consulting projects.  He sent me this IM conversation that really illustrates his point:
  • Matthew/Chicago/: Srini I’m in a room filled with 20 very concerned UAW workers trying to run their new line financial pareto reports for the US financial accounts. This is one of the BTO transition items I have to get setup for the client ASAP.
  • Srinivasanu/India: Yes Matt this is Srini.
  • Matthew/Chicago: Yes Srini I know. I am inside of the report we are stuck on the case number selection field which has been searching for results for approximately 5 minutes without a result.
  • Srinivasanu/India: Yes Matt. Are you connected into the internet?
  • Matthew/Chicago: Srini yes I am connected to the internet. There are no values showing up in the prompt selection. The report is failing. People are not happy I’m in a room filled with upset union workers. I’m wasting their time.
  • Srinivasanu/India: Matt can you see if you can get to the Google.
  • Matthew/Chicago: Srini I’m connected to the internet I’m speaking to you on the internet.
  • Srinivasanu/India: Yes Matt internet is not issue.
  • Matthew/Chicago: You and the team marked this as a passed item in your SIT testing according to the client. Note the test cases all mentioned a specific value to search on 12501 for example case number 2 does not work. The users are trying to do the same it is not working.
  • Srinivasanu/India: Matt yes I test the field and when the field didn’t return value I skip it.
  • Matthew/Chicago: Srini did you skip everything that was not working and just mark it passed?
  • Srinivasanu/India: Yes Matt.
  • Matthew/Chicago: So you have no idea what you’re doing? Is this a correct assumption?
  • Srinivasanu/India: Yes Matt.
  • Matthew/Chicago: I think I’m in the Twilight Zone.
  • Srinivasanu/India: I not get message Matt.
  • Matthew/Chicago: Get up now walk over to Prasad and let him know you are no longer on my project. Tell him to get the entire team in a conference room in 10 minutes and to dial in my line. You’re not invited. Do you understand this?
  • Srinivasanu/India: Yes Matt I think there is a problem.

August 31, 2010 Posted by | Development Management, Project Management | 14 Comments

Benefits and Tips for Offering a Third-Party API Program

Partner programs that offer an API (application programming interface) for 3rd party developers can be a great way to:

  • Acquire users inexpensively.  Ultimately, users of the third party application will learn your brand and make their way back to the mother ship.
  • Cheaply increase your development efforts by incenting third party developers to build interesting applications on top of your API or include your API exposed services as a complement to their core application.
  • Ultimately, increase your revenue.

When designing your API program, consider the following.

  • Start off small, offering a small set of core services.  If this proves popular, then selectively increase the API offering.
  • If you also offer a client application, you may not want to offer every single feature so that users eventually end up migrating to your own application client.  You may also want to disallow competing applications, only allowing your API to be used as a complementary piece of content in third party apps that do not directly compete with your business.
  • Set a minimum split amount that a developer’s third party app must produce in business before they get paid commissions.  This will save time and money in micro-payments.
  • Publish the split, and avoid any negotiation.  It takes too much time.
  • Standard contract ready to go.
  • Good documentation, forum, sandbox development environment, and make sure to budget time for a developer to monitor the forum.
  • PR for your API.  Development groups and local programming meetup’s make a great spot to spread the word.
  • Use simple API technologies, like RESTFull services or simple HTTP XML or JSON services if you can. Avoid complex SOAP services if you can help it because not everyone can do SOAP easily (ahem… Ruby).

So get going on your API program, and get on to the internal arguments of what services to expose!

August 10, 2010 Posted by | Business Strategy, Product Management | 1 Comment



Get every new post delivered to your Inbox.