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.
[ Find out when to kill (and when to recover) a failed project and how to avoid the most common project management mistakes. | Get the latest insights by signing up for our CIO newsletter. ]
Speed
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.
Size
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!
Here’s our easy four-step recipe to get your project completely wrapped around the axle:
- Don’t ask about the size of pricelists or orders
- Don’t tell anybody there might be a risk
- Don’t prototype before you choose technology or commit to a budget and deadline
- Do let management mandate that no custom coding is allowed.
[ Beware of dangerous data in your CRM system ]
Systems and data sources
Now let’s start thinking outside the box, and look at the systems and data sources you’ll need to work with. These are so useful in designing failed projects because of the variety of things you won’t know about in advance. Let’s start with something as small as the data in each field. Are numbers represented as numbers, ASCII characters or some weird mixture (depending on the age of the row)? Are there non-printable characters in the text that will fool you into thinking you know what’s there? Did somebody forget to tell you that some of it is UTF-8, and some not? Did somebody else remove accented characters a few years back, but only from some of the rows? These are all a great start!
[ See why with CRM data, more isn't always merrier ]
Going a level deeper, you need to look at the architecture and underlying infrastructure of the systems you’re interfacing with. You’re looking for solid, tried-and-true systems (based on an IBM Silverlake, VAX, or embedded ARM controller) that never contemplated web services. If you can’t find any of those, look for applications that are legendary for their unwillingness to share data. For those apps that do share data, you’re hoping for the ones that have their own internal transaction controller but do not let you determine (or understand) the state of the controller. And if you must deal with an app that has an externally visible state machine, hope that they don’t provide any way of intercepting control, initiating roll-back, or running compensating transactions. To achieve real project failure, you’ll need to avoid enterprise systems buses and serious integration platforms. But take heart, even the most capable web services systems can be mis-applied, allowing the growth of big wads of spaghetti code.
[ Learn how poorly integrated systems quickly make customer service go from bad to worse ]
Project specs
Our project disaster would not be complete without an un-implementable specification. The first approximation is to make sure it’s fixed price, fixed schedule…and that both attributes were mandated before the requirements were investigated. Now let’s refine it with a specification process unencumbered by the thought process: ask the users what they would like to see in a perfect world! Utopianism and lack of constraint work wonders, particularly when they are disguised by flowery prolix and nice formatting from an industry analyst firm whose staff has never actually produced a system based on the required technologies.
While we’re at it, let’s look at administrative complexity. This isn’t just an issue of human factors – sometimes ease-of-use actually contributes to the problem! The best administrative messes come from incompatible administrative models, where two apps have conflicting ways of defining groups and privileges. Yummy. Even in a single system, though, you can define user privileges and controls in such a detailed way that nobody will ever have time to manage it all. Without too much trouble, we found a system with over 1,000,000 Booleans just for the security settings. Every one of them set by mouse clicks! Just think of the fun. One of the best ways to get this multiplication table going is merging multiple CRM instances, particularly when the user communities have disparate goals and nearly-opposing business rules. Check it out.
[ Test your CRM management and administration IQ and learn why CRM security is always complicated ]
Organization issues
One oft-ignored attribute of a failing project is the organization that will be using it. We need to identify character flaws early, to make sure they become critical success blockers. Does the organization have trouble processing the words “no” or “expensive”? We can work with that! Do they say they want a transformative application with breakthrough results? That’s an excellent start, particularly if they are actually not willing to change any business rules, processes, or job descriptions. Is upper management at odds with the worker bees, with different metrics and incentives? Major coolness! The mind reels with the possibilities along the “change management” axis, so use your imagination here.
Technical resources
Finally, let’s look at your technical resources, because they can be part of the most amusing failures. Do you know anything about the people on the team? Do they know the technology cold? Are they intimately familiar with the business, or at least have buddies who are familiar with it? Are they good at asking questions and getting really helpful answers? Do they use the right tools? Are they flexible and have a can-do attitude? Are they willing to stick around for the whole project? You’ll want as many “no” answers here as possible.
I’ve tried my best to design the perfect-storm project for you. If you think you can do better, I feel sorry for you. In any case, you can email failures@saleslogistix.com with your best project-destroying ideas.
More on how to doom a CRM project to failure:
- Top 10 easy ways for consultants to end up in court
- Top 10 ways to have your project end up in court
- Time and Distance Enemies of Agile Project Management
- Why the customer is not always right
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.