Skip to main content

5 Pitfalls in Choosing Cloud Business Software Such as CRM


Choosing a business software package such as Microsoft Dynamics, Salesforce, SAP or Oracle is a daunting task, and the process can lead you astray in making the best decision for your organization.

There is no shortcut to finding the right product.  Choosing the best selling or fastest growing software product does not guarantee you will be successful in your company with that product.

Software categories are complex, and many products are geared toward specific industries or to companies of a certain size.  If a small company tried to implement a product such as SAP enterprise resource planning which is successful with large global companies, it could easily find itself overwhelmed and the implementation price could exceed annual company revenue.  On the other hand, a large company with global subsidiaries, complex tax rules, and high number of users and transactions would not likely be successful with QuickBooks.

One of the approaches to choosing software is to create a list of desired features and send solicitations to vendors in order to find the ones that best fit the business need.

My company InfoStrat participates in many product evaluations, and these are the top pitfalls that I have witnessed:

  1. Vendor feature lists are rigged to make that vendor look good. They are created by marketing staff, and no vendor will include features that they lack on a feature checklist.  As a bidder, if I see a solicitation that contains a feature list taken directly from vendor literature, I know that a product has already been selected.
  2. Asking vendors to rate themselves on features results in optimistic ratings.  Vendors know what customers want to see, and it is tempting to answer Yes to everything unless it is clearly not supported.  The more vague the requirement or feature, the easier it is to justify answering Yes. You could mitigate this problem by asking third parties such as resellers to answer as well.  This will not likely result in consistent results, but could point you to features that need further elaboration or examination. 
  3. Features are an arbitrary black hole.  Defining what is a feature is arbitrary, and you can come up with a large number of features for any product.  More features do not necessarily make products better.  I prefer to carry a Swiss army knife with only 5 features because it is lighter and more comfortable in my pocket than the largest model. Software can become bloated as well, to the detriment of usability. Some features are redundant or overlapping, and can lead you astray when you favor the sheer number of supported features.  For instance, for an automobile you could ask whether it contains cup holders (1 feature) or break this into driver cup holder, passenger cup holder, left rear seat, right rear, middle seat and third row cup holders.  Next thing you know, you end up driving a minivan.
  4. Counting features without weighting them distorts the evaluation.  This is closely related to the previous point but surprisingly common.  If you count positive and negative answers to a features list without applying weights to the more important criteria, you are weighting them equally.  This can lead to poor decisions.  Consider the hundreds of criteria you could apply to purchasing a vehicle and ask yourself whether you should equally weight criteria such as safety, affordability and capacity with side mirror defrosting or the interior mood lighting. 
  5. Favoring objective over subjective criteria.  It is tempting to reduce a decision to what seem to be objective criteria, removing subjective criteria or reducing their importance.  The problem is that for business software user adoption is key, and adoption is heavily influenced by criteria that resist being reduced to feature check boxes.   We see evaluation matrices with criteria such as "intuitive" or "seamlessly integrated".  These may be good aspirations, but they are impossible to evaluate objectively.  
If a feature list is arbitrary, rigged, and easily distorted, what is a better way to choose enterprise software? Our most successful customers have used requirements and features to narrow their choices, and then conducted a proof of concept or pilot to allow their users to get hands on experience with the products.  This approach allows you to factor in subjective criteria and determine the fit of software with your organization, from both a technical and a business perspective. 

Cloud software is much easier to experience in a pilot than on premises software because it doesn't require you to configure servers or your network to start using it. Many vendors offer free trials for 30, 60 or 90 days and they will usually extend a trial if you need more time to make a decision. 





Popular posts from this blog

Key Concepts for Microsoft Dynamics 365: Tenant, Instance, App and Solution

Updated 8/15/2022 To understand Microsoft Dynamics 365 (formerly Dynamics CRM) and Power Apps, you need to learn some new terms and concepts that may be a bit different from what you know from databases and solutions that are hosted on premises.  These concepts also apply to Power Apps.  The main difference is that with Power Apps you are not starting with a Microsoft app but more of a blank canvas for your custom apps.  This post introduces some key terms and how these concepts are important for planning your implementation. While Dynamics 365 is still available on premises, it is most commonly deployed on the Microsoft cloud.  This blog post discusses only cloud implementations. Microsoft has multiple clouds such as commercial and government community clouds in several countries. We start with a Microsoft tenant .  A tenant is the account you create in the Microsoft Online Services environment (such as Office 365) when you sign up for a subscription. A tenant contains uni

Understanding Dynamics 365 and Office 365 Admin Roles

Managing Dynamics 365 instances If you run Microsoft Dynamics 365 (formerly Dynamics CRM) in the Microsoft cloud, you need to understand how your Dynamics instances relate to Office 365 and choose which of your administrators receives which roles and permissions to manage Dynamics 365. In on premises deployments, your network administrator would create and delete user accounts.  The Dynamics 365 admin would then assign permissions to users in Dynamics 365. This post explains three administrator roles: Office 365 Global Administrator Dynamics 365 System Administrator Dynamics 365 Service Administrator You may think that the Dynamics 365 system administrator would have power to do all the actions needed to manage Dynamics 365, but this is not the case. What's different in Microsoft cloud deployments is that licenses and user accounts are managed in Office 365 by an Office 365 Global Administrator.  This role is analogous to a network administrator for an on premises

My Favorite Microsoft Power Apps Bloggers and their Blogs

  by James Townsend Updated 7/5/2022 Microsoft Power Apps is one of my favorite subjects, and I enjoy reading blog posts from members of this thriving technical community.  Here are some of my favorite bloggers and their blogs: The Official Microsoft Power Apps Blog   I have to start with the official Microsoft Power Apps blog.  It has many contributors, largely Microsoft program manager, including frequent posters Denise Moran ,  Greg Lindhorst , Kartik Kanakasabesan , and  Adrian Orth .  This is the place to go for product announcements, updates and technical how-to for a broad range of Power Apps topics.  April Dunnam April Dunnam was formerly focused on SharePoint and now devoting herself to Power Platform.  April offers highly understandable explanations of Power Platform, Dataverse and other top Power Apps topics. She joined Microsoft in late 2019 and has a thriving YouTube channel .  Carl De Souza Power Apps Blog and eBook This is one of the most extensive and best organized blo