Blog

I remember this quote from a doctor while discussing about lenses when my mother was going through cataract operation. When asked which lens to go for, I responded with "the most expensive one" and she replied back with a smile "the best may not necessarily be the most expensive one". And the phrase has since stuck in my mind.

When I was a Microsoft employee (a CRM consultant), sometimes the client would ask about software solutions for certain other needs; for example if they need a website to publish contents and I would be prompt in talking about Microsoft SharePoint (although somewhere in the back of my head, a voice would start arguing "what about Wordpress? It seems to fit exactly with what they need..." and I would "Ssh" it saying "they can easily afford SharePoint").

Since leaving Microsoft I feel a lot relieved by not having to go through such internal debates while recommending software solutions and providing what matches as best for the organization's need.

However I often encounter the same thought process as "the most expensive one" with some CEOs/CTOs and then convince them to go for "the best one" instead.

You see "expensiveness" is a constant or for that matter "price" is a constant, just like many other constants features, support, quality, etc. while "best" is a variable primarily a function of "need" with all other constants. So to determine the "best", you must understand the "need". And that is true for every decision one makes in his life.

Sometimes we also make the mistake of "matching bests", I remember an old marketing quote from SAP "the world’s best company uses SAP" (perhaps referring to Microsoft); now one must understand a process or a solution that is best for Microsoft or IBM can actually be the worst for them, even if not, it certainly is no way to determining the best.

Once I was asked by a developer if he should use enterprise library, when all we needed was log errors in database with no need for any other blocks of enterprise library. And I had to say "you don't need a sledgehammer to put a nail in the wall". Ironically, many of my MS CRM implementations actually required stripping out a whole lot of features from the platform, simply because it was not desired by the client and was more confusing than solving their purpose. Imagine this from the client’s perspective first you pay for a whole lot of things that you don’t need and then you pay again for getting rid of all those things.

While at Microsoft I suggested splitting the sales, services and marketing modules as separate solutions in MS CRM as that would significantly simplify CRM implementation, but I guess it will be a while before implementers feedback would matter. Although do not misinterpret my comment as a bad review about the product itself, it continues to be my favorite for every CRM implementation I do, it certainly solves almost all CRM needs any company can have and a lot more; and sometimes the "lot more" does turn out to be useful.

But coming back to the point it is actually what you "need" that matters more and then what any platform offers. And finally a fit gap analysis before deciding your IT solution. Quite like choosing your partner and like any other relationship there would be bumps and glitches but you continue to appreciate more for what it has than complain for what it does not.

Other Article Inception of Eras PaaS