Monday, December 25, 2006

Are you paying too much for offshore resources?

I was recently in Bangalore and Hyderabad on work as well as vacation and stumbled across something very interesting. While looking through the financials of each of the top 3 offshore providers, Infosys, TCS and Wipro I noticed their incredible margins and revenue growth for '07.

More interesting than their phenomenal revenue growth was their margins. Given all we hear now from offshore teams is that costs are rising and retention is so hard, these companies are showing stronger margins than ever before. Either their billing rates have been going up steadily and/or they are finding ways to reduce or keep their costs steady. Perhaps, they are doing a bit of both.

What is interesting is that there is a large resource pool in the Tier 2 cities or perhaps even the Tier 2 or Tier 3 colleges that is willing to work harder and meet commitments at a much lower cost than what is widely known to most clients. These companies seem to be tapping into this pool quite effectively.

If you are headed down the path of offshoring and have the right connections, you should explore companies that offer resources based out of Tier 2 cities. If you are committed to offshoring, at the end of the day, you will spend tons of time and sleepless nights providing detailed specs, managing offshore projects and spending time and money on QA. Of course, once your team has learnt your product/system and is trained, you will see benefits that will justify all your initial pain. If the pain remains the same, why not maximize your cost savings? This line of reasoning works only if the work entails simple coding typical of business applications and not some complex engineering tasks such as chip design or complex algorithm development.

Bottom line - there is a huge talent pool that is outside the Tier 1 cities in India that is untapped and offers tremendous opportunities to clients and software service providers that will not go unnoticed for long. While I was aware of this in the past, it hit home when I saw it first hand!

Monday, November 06, 2006

Looking for a simple way to evaluate software for your business?

If you work for a company with revenues over a Billion $s a year, you probably want to save yourself some time by ignoring this article. For those that work in IT or a similar organization responsible for business applications, this may be worth your time....

I'm sure most of us that have been involved in evaluating software will agree that its extremely difficult to figure out which among all those offerings from seeming endless number of vendors is the right one for your particular business and more importantly a good fit for the business given the direction its headed. It’s usually the great demo and sales talk combined with a very attractive starter deal that gets most of us. While a great demo may reflect the vendor's knowledge and understanding of the business you are in, it may just be that the vendor has invested more in fine tuning their demos for every vertical.

In fact what is most important are the following:

- Feature/function fit
- License cost
- Hosting cost
- Services cost
- Integration cost
- Training cost
- Compliance/Security cost

Cost must be quantified in terms of what you actually pay the vendor and what you actually spend internally deploying and using it. While this may all seem too obvious, it’s amazing how we get sold on one or the other and completely ignore the overall picture. While a product may have all the bells and whistles, the question really is whether those are features your users need. Integration is often an overlooked area while purchasing software. Simply asking how you do integration is not sufficient. Most software vendors can answer that question. The real question is how much integration you foresee for your business going forward. If you do expect a lot of integration, you may want to have your data as close as possible so that you can have complete control on the data/APIs and make it available to applications that need that data. Integration is always expensive when you change requirements and add functionality in the app that sends the data or receives the data. You may spend almost nothing on the license but if integration costs are high you are probably going down the wrong path.

Feature/function fit is sometimes highly overrated. Again, don't believe what the vendor tells you. They always know that under certain conditions, the feature works but it my not work for all the conditions that are actually important for you. So, nothing beats trying out something and then making that assessment. You not only get to play with the software but you get to see the bugs and caveats which the sales folks conveniently never share with you. Open Source software is perfect if you want to try out something before deciding to buy it. Some of the On-Demand apps that are now available are truly amazing when it comes to value - most of them let you test drive before you sign up.

Last but not the least, be practical. Most of the established products have been around a while and those vendors are unlikely to make major improvements. They have long release cycles. Look at what is out there, try out some of the newer products and make an independent decision on what is best for your business. There is a lot of software/hardware being developed, faster, cheaper and better every day. Do your homework and even better, listen to folks who have used the product or evaluated it in the past.

Finally, if you believe that you should use software only from the established players such as Oracle, SAP or Microsoft, then you better be working for a $1 Billion plus company or one that is rapidly headed in that direction - they are safe bets and probably will do the job if you have deep pockets and resources to spare!

Thursday, April 06, 2006

Enterprise Software Open Source Business Model

For companies looking to break away from the traditional enterprise sales model, open source does provide some interesting and more importantly compelling opportunities. Recently, I had the opportunity to attend a luncheon where an executive from a successful Open Source software company laid out the business model with great clarity. Here is what he had to say...

The traditional enterprise sales model is based on a well-oiled lead generation machinery that feeds a direct sales force. The formula is based on Total Revenue = Quota/salesrep * Number of salesreps. While this maybe an oversimplification, this is what it really boils down to. If you look at the Open Source business model, especially for an enterprise software company, the lead gen source are the downloads. The inside sales and eventually direct sales teams have to take these leads and convert them to sales. The big difference and reason why most of us are excited about Open Source is that for the first time emerging software companies are able to get a large volume of leads from successful Open Source communities. However, the conversion rates are low, perhaps as low as 1% over a reasonable period of time from download to deal close.

So, having said this, there is a play here if one has a very successful Open Source project that has thousands of downloads. If you don't have such a community, believe me, building one is not that easy. You are probably better off buying one if you can. Its an added risk especially for companies switching from a traditional enterprise sales model to an open source model.

For the more established players, this creates a new threat as now start-ups can start to spread virally (in a good way) in their installed base. Given the tens and thousands of customers they currently have, I would think that their strategy should be to emulate the open source model and offer low cost, low friction products and solutions that their customers can try and adopt. Once they are ready they can sign-up for support etc., the way one would do with an Open Source software company. On-Demand apps certainly address some of the issues being addressed by Open Source and a whole lot of issues that are not addressed by Open Source.

I hope this provides clarity to software execs looking for business reasons for adopting an Open Source strategy.

Sunday, January 29, 2006

Attracting "outside developers" to your Open Source project...

During a brief discussion with some folks who work at Actuate, it became apparent that several open source projects in fact have little or no participation from "outside developers". I'm referring to "outside developers" as those who are not employees of the sponsoring organization. An "outside developer" could be an end user, an employee of a customer using that software or someone who just has time on Sunday mornings to exercise his/her programming brain cells for no particular financial gain.

Having said that, it is interesting to note that some projects such as BIRT, which is being sponsored by Actuate, were created to counter open source software such as Jasper's reporting software. However they have been unable to attract adequate open source developers. Given the size of Actuate's customer base, one would have thought otherwise. Just take a look at the their bug list.

From what I can tell, there maybe several reasons for the lack of "outside developers" including the following:

a. First mover advantage - Given that there is a limited pool of independent "outside developers", its likely they have already flocked to the likes of JasperReports. The remaining set of "outside developers" has not developed probably for some of the reasons described below.

b. Complexity - The complexity of the code is an important factor for someone to contribute. For those of us who have been developers, the more complex the code, the harder it gets to make changes to it.

c. Barrier to contributing - If there are a lot of instructions and the time and effort required to start contributing code is high, its very likely to turn off potential "outside developers".

c. Incentive - For someone to contribute code, there has to be reason to do so. If I work for a company that uses some of the open source code and I uncover some bugs, I am clearly incented to contribute the fix. Similarly, open source developers provide enhancements if they feel they will be useful for others in the open source community.

The bottom line is that one has to address the above issues in order to leverage "outside developers". If that does not happen, one needs to invest in the development activity. This does not mean that a project without a large number of "outside developers" is entirely worthless (because there is value for the end users of the software to review bugs, fixes etc. from the project web site) but to put it mildly the value to the promoters of the open source project is marginal in the long run.