Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to plan a CRM project that's guaranteed to fail

David Taber | Oct. 6, 2017
We all want our CRM projects to succeed, and one way of making a winner is avoiding the characteristics of failed projects. Think of this article as a recipe for disaster and follow none of the advice herein.

Nearly every cloud CRM project has attributes of winners and losers, and the project manager’s job is to get the best outcome possible given the resources and requirements.  But there are some project characteristics that almost guarantee a crummy outcome – in some cases irrespective of platform and the finesse of the project manager. 

So in a modern day rendition of Gomez Addams, let’s try to create the technical pre-conditions for the perfect train-wreck cloud CRM project, focusing on software technology issues.



Let’s start with speed, which in the cloud can be translated into responsiveness. In the immortal words of Nathan Myrvold, “bandwidth, we can buy; latency comes directly from god.”  Given the distances involved, the speed of the cloud is amazing.  But it can never feel as fast as thick-client software’s local processing. 

So, for a perfect pre-condition of failure, make sure the project will be judged against a native Windows or Mac app banging on a local disk’s database.  Pay no attention at all to requirements about type-ahead, in-form field validation, and other items implying sub-second response time.  Start the project with gusto, and leave in responsiveness requirements below 2 seconds.  While you’re at it, make sure there are big penalties for the occasional multi-second screen refresh!

But wait, there’s more when it comes to speed.  While AWS, Heroku, Azure and Google offer almost unlimited computational power, most cloud applications’ APIs throttle performance pretty effectively.  Need to do a recursive calculation, validate a license key, or get correct results with 18-digit numbers (you’ll need it if you want to do national debt calculations on this page)?  Can’t be done in your cloud app – you’ll need to get to a cloud platform giving you full access to Python, Java, or C++ libraries.  So when it comes to computational performance, make sure you completely ignore requirements for serious math.



We keep hearing that size doesn’t matter, but in some areas cloud apps just don’t measure up.  Let’s start with something as simple as the number of records in your database.  Have two million leads?  Your marketing automation ought to have fun with that!  How about your activity history…those can grow into the millions in a hurry, which means query timeouts galore!  And let’s just hope you’ve got a big, complicated pricelist, catalog, or SKU data set.  The first layer of fun is just the data set size:  the simplest searches and sorting might work OK with 100,000 SKUs, but almost any off-the-shelf configure-price-quote software will choke trying to process orders with that catalog.  The next layer for fun is order size and line-item complexity.  Need to place orders with 1000 line items?  Nice!  Have line items with tons of miniscule variations and incompatibilities?  Just imagine the combinatorial explosion there! 


1  2  3  Next Page 

Sign up for MIS Asia eNewsletters.