Implementation Approach and Resources

After you purchase the software or sign a SaaS subscription agreement, your next step is to actually implement the solution. Depending on the level of complexity you may choose to do this on your own or, more likely, with the help of an implementation team from the vendor or one of their approved business partners. It will be almost impossible for the vendor to provide you with a reliable implementation plan as part of an RFP response. There is simply not enough information available to the vendor without significant discovery and there is rarely time for this discovery during the RFP phase. At a future stage when you are closer to a final selection this may be a more viable option. As a surrogate for a detailed project plan for your own project, you can ask for a project plan for a prior comparable project or possibly a template that will be used to build your project plan. Reviewing this project plan will give you a good indication of the vendors ability to support you in implementing the product. Most vendors will have qualified, or certified, partners that can provide resources for this purpose. Our general preference when working with vendors is to use their own professional services team if available. This provides the benefit of a single point of accountability. We have also found that the vendors own in-house resources have much better access to the support and development staff as well as accurate information on future product releases.

One of the most critical aspects of implementation is the actual project team that will be assigned to your project. Dont be fooled by the big-wigs and industry-leaders that youll meet during the sales cycle they will not be on your project team and in all likelihood you will never hear from them again after the sale. Ensure that the post-sale assigned resources have significant experience implementing the solution. A team of green-beans (new consultants with limited experience) will not be able to guide you through the sometimes complex process with predictable success. In addition to experience with the software solution you are going to implement, ensure the assigned consultants are seasoned professionals that have been involved in enterprise systems projects. They should have experience with subjects such as business process analysis, project management and change management.

Alternative Software Deployment Models

Over the last 5 years the business application software industry has gone through a transition (some claim transformation) moving toward new delivery models based on software as a service. A little history may help here. A traditional or on-premise software deployment involved the purchase of software licenses from the vendor and usually an associated software maintenance plan. At this stage you would ask your IT department to provision or acquire appropriate hardware, make any necessary network connections, ensure the security, availability and disaster recovery requirements were in place and then begin the process of configuring the software for production use. Under this model the purchaser acquires a perpetual license to use the software.

The introduction of software-as-a-service (SaaS) approximately 6 years ago fundamentally changed this model. In essence, instead of buying the software and running it on your own hardware, the SaaS vendors provide the software as a subscription service running on their hardware typically in state-of-the-art data centers. Under this model there is no need to buy hardware or deal with the network connectivity, security and redundancy issues. In many cases, the SaaS solutions can be implemented without the involvement of the IT department a paradigm shift indeed. The SaaS model is not without its own set of unique factors that need to be carefully considered:

* Cost: Typically the service is provided based on a monthly per user cost. This pricing model provides a flat rate, predictable cost for the solution. While the non-SaaS software vendors often respond to the SaaS alternatives with FUD (fear, uncertainty and doubt) and alleged higher total cost of ownership (TCO) over a longer haul, well cited research provided by Sheryl Kingstone of the Yankee Group convincingly illustrates that hosted solutions continue to show lower TCO over a five year period. Reference Appendix V for publicly distributed Yankee group figures or contact the Yankee Group for more detailed information. We highly recommend preparing your own Total Cost of Ownership analysis if you are trying to evaluate the relative costs of hosted and non-hosted solutions.
* Reliability: With a SaaS solution, the provision of an adequate infrastructure is the responsibility of the software vendor. This means that as part of your due diligence you must ensure the vendors data center operation is reliable and secure. The best way of understanding the reliability of the vendors data center is simply to ask for a log of all recorded interruptions, outages or downtime over the last 24 months. This objective measure will provide a real world indicator of the reliability of the vendors data center and ability to deliver SaaS CRM solutions without user interruption.
* Security: Security was initially a big concern when the SaaS model was first introduced. Security however, is integral to the SaaS value proposition and the leading SasS providers such as Salesforce.com, NetSuite and Aplicor provide security infrastructures that generally exceed the capabilities of most of their clients.


Vendor Viability

Having validated the functionality of the solution and determined the preferred deployment model, it is important to ensure that the selected vendor will be around for the long term. As even the largest companies like Enron, WorldCom and Andersen collapse, size or even the reliance on public company status gives us little comfort. We suggest therefore that you focus on the fundamentals: How long has the company been in existence? Is the company profitable? Does the company have a litigious history? Does the company have any litigation pending? Asking for detailed financial information is generally not a particularly revealing question as many privately held companies will not make this information available and for the public companies it may be difficult to understand how your targeted solution fits into their overall financial picture. Perhaps instead asking for certain metrics might yield a better result. Consider for example, customer churn. This metric represents the number of customers that renew service/maintenance agreements over time or for the SaaS vendors how many subscribers continue to renew their subscriptions annually.

Solicitation: Prepare a Request For Proposal (RFP)

Preparing an RFP does not mean you need to abide by the Federal Acquisition Requirements (not fun trust me). It simply means creating a structured communication of your requirements that forms a reference point for vendors to respond and a yard-stick (is it a metre stick in Europe?) against which to objectively compare the many product offerings you will initially consider. The content of your RFP will vary depending on your situation and in many cases any corporate or legal procurement constraints that you may be subject to. We have provided an outline for a typical RFP as Appendix III.

There are several options in how you chose to conduct your RFP process. Larger organizations that have software vendors salivating at the very thought of their business will almost always receive more timely and far more aggressive response than smaller organizations seeking to engage vendors in an RFP exercise. One golden rule prevails though, if you dont get good service in pre-sales, youre never going to get good service in post sales - aka Red flag #1. For an interesting CRM buyer experience, refer to Appendix IV - CRMGuru Article on How Well Do CRM Vendors Sell as an all too common anecdotal experience that is incredibly indicative of continued after-the-sale CRM vendor performance. The quality of any RFP response is indicative of the quality and esteem in which the software vendor holds your business.

It is a good idea to provide the vendors with advanced notice that the RFP will be distributed on a date certain. This will allow vendors to prepare by assembling or allocating resources to thoroughly review your document and put together an appropriate and hopefully thoughtful response. You must ensure that you allow vendors an adequate period in order to provide a high-quality response. Typically a period of 3-4 weeks is normal depending on the scope of the requirements list. We are strong advocates of dictating the format of the RFP response and advising vendors not to veer from this format. This provides you with the opportunity to easily consolidate and then evaluate the responses quickly and effectively. Experienced vendors are conditioned to responding to RFPs in this manner and will not have any objections. A complaining vendor is definitely a tell-tale sign for Red flag #2.

You may choose to include a go/ no-go requirements list. This is a list of the absolute-gotta-have-em-aint -no-question-about-it-couldnt-do-it-without-em functions. It is basically a polite way of saying to your vendor universe, if you cant do these then lets not waste each others time. Use a little caution here and ensure you dont limit your market too soon. Requirements like Integrates to our in-house APGOL5.56 V2R Accounts Receivable System will at best give you confused vendor responses and at worst no responses at all.

5-step CRM Software Selection Guide: A Pragmatists Guide to CRM Software Selections

Selecting an enterprise CRM (Customer Relationship Management) software solution is a significant undertaking that requires careful planning and managed execution. In this white paper we have distilled our experience conducting selection projects for enterprise organizations into a Five-Step Guide to assist you in making the right decision the first time. We begin with the process of analyzing and developing weighted requirements. Second, well help you incorporate these requirements into an overall request for proposal (RFP) that you can issue to a qualified group of CRM software vendors. We provide practical methods to evaluate the RFP responses and compare solutions as part of a structured software demonstration. Finally we address contract negotiation and closing the deal as the final step in the process. Throughout the paper and in the associated appendices we have included examples of actual tools we use during projects. Happy software hunting.
1. Requirements Definition: Requirements First Software Second

Selecting a new CRM software solution is often much like remodeling your house - painful, untimely and expensive - unless you carefully evaluate your requirements before you start. Done correctly, the process can be relatively pain-free and will provide the expected results within a predictable time-frame and budget. It sounds simple enough, know what you want before you start. Yet in business situations with competing resources and limited time, and especially when selecting software solutions, the cart is all too often so far ahead of the horse that the two barely know theyre part of a joint-solution to a common problem. Why is it so hard to clearly define business requirements at the outset? There are many quite common, and equally misguided, responses to this age-old question.

In our experiences, one of the most common and misguided frustration responses is I dont know what I dont know. Having never selected an enterprise CRM or SFA (sales force automation) software solution how can I tell what I want when I have no idea what is available?

The problem with this statement is that it is not what is available that should guide your thinking at this stage (yes this comes later for those of you who enjoy reading ahead). The real question at this early point is what do you need to accomplish your customer relationship management objectives? Approaching this question from the whats available perspective will almost certainly lead to a myopic view of your actual requirements that is driven by the capabilities of the first cotton-candy-wonderland (client quote) vendor that you meet. When software vendor tools and capabilities lead well defined business requirements, users identify fathom or artificial business requirements which displace meaningful user needs and detract from achieving truly strategic customer relationship and business objectives. Do not let a software vendor tell you that that the tool you need is a hammer because thats the tool they have for sale.

Developing a list of weighted requirements to support prioritized business objectives can however be a daunting task. Many project teams struggle to define what a process is for their business. This challenge is not unusual and we have developed a guideline for clients to develop a meaningful requirements list. This example serves as a foundation for developing a customized requirements list for your organization. The functionality-matrix breaks the CRM software solution into its core modules: Sales Force Automation (SFA), Marketing Management and Customer Support. Each core module is then broken down into the major sub-processes. For example, SFA breaks down into Account Management, Contact Management, Activity Management, Opportunity Management and Sales Forecasting.