Going through the process of deciding that you need a Customer Relationship Management (CRM) package is a difficult enough process and when going out to the market to research the alternatives there are certainly plenty of software publishers and their representatives on the other side willing to tell you why their packages are superior and how they will satisfy solving your business concerns.

In the traditional process either someone convinces a business owner or manager that they need a solution or they somehow come to that conclusion on their own.  The company then tasks someone with doing the research around alternatives and many of them go to web and start to poke and prod around various web sites and start to put together a list of people to talk to.  At the end of this cycle a number of people are asked to show how their solutions will meet an organizations objectives for putting in a new system.  The one missing element in the process is an understanding of how these various solutions evolved to their current state.

Some people would argue that understanding the history of a particular application stack is an exercise in futility because any given project is about what exists today and how that capability matches up with current needs.  If you use the economic principle that in a free market economy all information is perfect I would agree with that argument.  We live, however, in market that is imperfect and during the process of selecting a system the people providing a solution demonstration often show us exactly what they want us to see and stay away from places that may cause us difficulties in reaching the optimal solution.

Don't get me wrong. I don't think that doing trials or pilot programs to learn everything possible about a particular technology will solve the problem.  There is a happy middle ground that I think can provide you a comfort level when selecting a system.  If you simply ask each vendor to give you a historical context of how the technology was created and how it evolved then you can at least get a baseline to understand where you might have greater concerns or want more information in a particular capability or the publisher's commitment to certain functionality.  This will make you feel comfortable around the future commitment of R&D dollars and how likely you will be successful moving forward.

Here are a number of the areas that I would be concerned about when researching a new technology:

Underlying Technology - When you look at any new system it is valuable to take stock of which technology foundation that technology was originally built upon and where it is today.  An example is a CRM system built as an in house client/server system and then "enabled" for the web but not rebuilt or built natively for today's web capabilities.  There are a number of challenges and customization issues that may arise from this type of offering.

Development Timeline - The first concern here is to understand when a particular system was created and how long it has been proven in the marketplace.  Along with this understanding of how something has been around is the need to understand that publisher's pace at which they come out with new revisions and the technology road map moving forward.  A perfect example is some of the newer systems that have come about in the post-.com era.  Many of these technologies are still playing catch up on features and functions that are valuable to a sales or service team (especially in high transactional environments) and when you pay for a system the price paid should reflect an apples to apples comparison of what you are paying for.  If you couple in the timing on new releases for a vendor to catch up there could be a serious impact on ROI.

Target Audience - When any new application is developed there is a specific target audience or ideal customer for that software publisher.  The impact of knowing the original target helps in understanding how the technology has evolved to its current state.  The most common example that I can think of are the lower end technologies that are focused on primarily contact management or sales force automation and then add some account management or marketing functionalities to try and satisfy customer demand.  Many of these technologies have a lower price point but their existing capabilties for marketing and service may be superficial at best.

Delivery Options - This particular concern is one that has evolved more as the world of Software as a Service (SaaS) options have flooded the market over the past few years.  Many prospective customers need to know if those underlying technologies utlize one large shared instance of the technology or if they are basically renting their own instance of a database out in the cloud.  The impact here is that there are inherently more options to modify and customize an application so that it can meet a particular company's objectives.

Frankenstein Effect - One of the biggest challenges in understanding the history of some applications is to also know how/if some of the capabilities were originally developed by the publisher or if they have "bolted" on products that were build in their tool set and then subsequently purchased and made to be part of the application.  The most obvious challenges are that sometimes the functionality was not part of the original design and creates either performance or customization challenges

While there are other areas to try and understand like integration or mobile capabilities I think you get the gist of this posting.  When you have a baseline of understanding of the technology and the context of how it has evolved this will enable better decision making when making a final selection.  As the saying goes...those who don't know history are bound to repeat it.  And, in the world of technology, nothing could be closer to the truth.