How Long Will it Take?

This is the most popular question I get about CRM projects, and it's even more popular than another popular question: what does it cost? Like all important questions, how much time is required is not an easy question to answer. The most accurate answer is "It depends." I've personally witnessed a successful one-month project from beginning to go-live date, as well as projects that took close to two years to complete. Unfortunately not every long project was successful, so time spent is not a guarantee for success.

One way to approach the time forecast is to start with the overall complexity of the project. Although a complex project can sometimes be accomplished faster than a straightforward one, given a good team and relentless focus, project complexity is a fairly reliable indicator of how long it will take. Let's start by defining what makes a project complex.

Project Complexity

Project complexity depends on the following eight factors:

• The number of business functions involved . If you are looking for a CRM system for just one function, such as sales, it will be easier to select a tool and faster to implement it than if you are looking for an all-encompassing solution for sales, marketing, and support. Coordination between the departments, finding a proper project sponsor, and finding appropriate technical solutions all are more difficult and time-consuming when multiple functions are involved.

• The scope of the automation . In the same vein as above, the scope that's being automated has a direct effect on complexity. If you simply want to track sales contacts, your task will be a lot easier than if you also want to implement a scheduling package, a product configurator, and a proposal generator.

• The size of the organization , the size of the employee population affected, and, to a lesser extent, the size of the customer base. For starters, it is a simple fact that any project that involves lots of people takes more time to complete (even if it's not a straight line increase). There is also a technical component, as massive numbers of users mean higher performance requirements along with more complex applications, typically requiring extensive configurations and at least some customizations. Finally, very large customer databases create performance and functionality challenges.

• Geographical dispersion of the users and, most important, of their leadership. Having to coordinate with geographically dispersed users means that decisions will take longer. It also creates more pressure on performance tuning and deployment issues.

• Multi-lingual requirements . You can add many more complexity points if the users are speaking different languages. It's not only a matter of translating the screens and messages, but also handling different holidays, time zones, currencies, tax calculations, and potentially processes too. If you must provide multi-lingual screens to internal users, the complexity increases even further.

• The requirements for integrations with other systems . Because integrations are always custom, they necessarily require lots of time to implement. In the future, each time any of the integrated systems changes the integration will have to be revisited and perhaps adapted . This does not mean that integrations should be avoided, simply that they add to the complexity of a project and therefore its ultimate cost. They should always be weighed against the benefits they bring.

• The customization requirements . This criterion may appear unreasonable, since it's pretty difficult to estimate customization requirements when you haven't even started looking for a tool! However, you can make a reasonable guess of the customization requirements by observing ”or mandating ”how open you will be to adapting your process to the one modeled in the tool as opposed to capturing your exact requirements into the tool. If you are using a unique process and you are unwilling to adapt it to match a potential tool, you automatically add to the complexity of the project.

• The target timeline . This again sounds like a chicken-and-egg criterion since we are establishing the complexity index precisely to establish a timeline. What I mean is that, as we know, projects expand to fit the timeline, so if you allocate an overly generous timeline you can be sure that the project will expand to it. To be fair, an overly tight timeline has the potential for explosive failures. Rushed projects often fail to meet their objectives, if not the target deadline itself, and after they fail they need to be redone at great additional cost and with a considerably less enthusiastic staff.

  Be realistic when establishing a target timeline, but don't be afraid to be a little ambitious compared to the targets discussed below. Be on the shorter side rather than the longer side. In the same vein, you should also set deadlines for the important milestones of tool selection and integrator selection to avoid being behind even before you start the implementation.

A low-complexity project targets the main applications for one business function only, for a moderate number of users (no more than a couple hundred). Users are distributed within a single geographical entity (one center, one country, or at the most one continent ) with no multi-lingual requirements. Only a couple of integrations are required, and there is flexibility to process change to match the tool to avoid customizations.

A medium-complexity project may target more than one business function and it provides a pretty full complement of applications for each function. There are hundreds of users who are geographically dispersed. Some customer language adaptation is likely to be required. Several integrations are involved. Because of the size of the project, it's clear that customizations will be required.

A high-complexity project targets multiple business functions, with very complete coverage of the applications for each function. It has thousands of users, they are dispersed, and there are multi-lingual requirements. Many integrations are required.

Let's see what typical timelines look like for various levels of complexity.

Timeline for Simple Projects

Here are timeline estimates for a simple project (that is, one that targets the main applications for one business function, has no more than a couple hundred users, no more than a couple of integrations, and minimal customizations.)

The tool selection could take from one month to three months, depending on the availability of key personnel and their prior knowledge of the CRM field. It can also be helpful to purchase the tool at the end of the vendor's financial quarter (more on this in Chapter 7, "Buying a Tool") so in this instance slower can be better! Simple projects are ideal candidates for accelerated tool searches, as described in Chapter 6, "Shopping for a Tool."

The process of selecting an integrator should be shorter than with the more complex projects because the requirements are simpler, but sometimes it's difficult to find good, reliable integrators for smaller-scope projects. With a simple project, you may consider doing the implementation yourself. It's always a good idea to at least get some guidance from someone who implements that particular tool day in and day out, not just once in a while. Count on one to two months to find an integrator, much of which can be accomplished simultaneously with the tool selection process. For a simple project, the vendor should be able to either provide implementation assistance or point you to an experienced implementation partner.

Implementing the tool is much faster for simple projects and this is where the timeline gets dramatically shorter. Count on anywhere from two to five months, with the higher figure required if integrations are involved. If you follow our recommendation for layered implementations , you should be able to do the first rollout within 90 days, leaving the integrations to a second phase.

Overall, to complete a simple project from selection through implementation, you are looking at a minimum of three months and up through nine months, with the higher figure reflecting both a thorough tool search as well as more complex integration requirements (see Figure 3.1). Again, while faster is not necessarily better, longer timelines tend to breed delays and issues, so if you are considering a simple project it would be best to aim at something like a six-month deliverable , with the tool selection itself happening around the two-month mark.

Figure 3.1. Timeline for Simple Projects

What about very short timeframes? I mentioned earlier I had been a part of a successful one-month project, so it's possible to be successful with ultra -short deadlines. If you are tempted by a near-instantaneous solution, here are some points to consider.

• Don't be obsessed with speed. If there is no real business requirement, you must realize that a super-fast project will deliver a limited solution with no customizations. In particular, if your current tool is performing reasonably well, there is no reason to go for a super-fast project.

• Accept that you will not do an exhaustive search. There is no way to do that and an implementation within a couple of months. You can see demos of lots of different tools, but you cannot perform the kind of in-depth study that would allow you to make a fully informed decision

• Use your network. Because you cannot do an exhaustive search, it's particularly important to get others to help you with the initial winnowing. Why take a chance on a tool no one has heard of? Focus on colleagues with businesses similar to yours and eliminate any solution that requires a long implementation.

• Get a coach. There are consultants , including yours truly, who specialize in helping companies select CRM solutions. These people stay well informed of the market and can provide you with a first-cut selection appropriate to your requirements. Make sure you understand any financial gain the consultant may derive from a particular selection so you are aware of potential conflicts of interest. Select someone who has experience in your specific market because you have no time to spare. For instance, if you are looking for an e-commerce retail solution, someone who has been working exclusively with financial services companies would not be a good fit.

• Dedicate a small cross-functional team (users and IT staffers ) to the project for the duration. We will talk in more detail about how to select the team in the next chapter, but the operative word here is dedication: with a short project, the team cannot be expected to do anything else.

Timeline For Moderately Complex Projects

Here are timeline estimates for a medium-complexity project, that is, one that targets one or two business functions with a full complement of applications, has hundreds of users who are geographically dispersed, and requires some integrations and customizations.

The tool selection could take from two to four months, depending mostly on how well the different functions involved coordinate with each other. Moderately complex projects can be candidates for accelerated tool searches, as described in Chapter 6, "Shopping for a Tool." Reference checking is very important when projects cease to be simple, and onsite, hands-on reference checks, which take time, become very desirable. Try not to spend too much time on the selection process, however, since the real work is still ahead and you should be able to identify the top candidates reasonably quickly.

Selecting an integrator is required for moderate-complexity projects. Although it's always a good idea to have your own staff participate in a hands-on manner, it's very unlikely that you will have the trained resources required to actually pull off the project. Count on one to three months to find an integrator and much of the selection process can be accomplished while you complete the tool selection process. Note that the timeline does not differ much from that of a simple project.

Implementing the tool can take from four to nine months, and even longer if many integrations are required before rollout. With a longer schedule, I strongly recommend using a layered implementation, with regular deliverables every 60-90 days rather than one "big-bang" delivery. One popular approach is to roll out by function. However, this approach can be frustrating for the early users who typically have to wait until the entire rollout is completed before their immediate usability issues can be addressed (and there will be some, no matter what).

Adding it all up, a moderate-complexity project will take from six to twelve months (see Figure 3.2). While it is perfectly possible, if aggressive , to achieve a timeline on the lower end of the range, being successful in less than six months is unlikely with a moderate complexity project. Here are some pointers to achieve a speedy rollout with a moderately complex project.

• Do all you can to ensure that the various functions or groups involved work together harmoniously. Tool selection can be a very tense experience when multiple functions are involved. Single vendors are unlikely to satisfy all parties equally on the one hand, yet going with different vendors means you will need to do some integration work. If you have a terribly tight deadline and you are working with more than one functional group , you most likely will have to mandate using a single vendor, and one or both parties will not get all the functionality they are dreaming of.

• Minimize the complexity of the customizations and integrations involved. This makes for a shorter rollout timeline as well as streamlined maintenance requirements in the future. Remember (and remind the groups involved) that customizations and integrations that are not achieved today can always be added on later, and that a better selection of customizations and integrations may be achieved after the users have had a chance to work with the system.

• Get skilled project management. Even the shorter project timelines are long enough to afford plenty of opportunities to miss something or forget a dependency. If the project manager comes from the system integrator, as is often the case, you will need to carefully evaluate the individual who will work with you.

Figure 3.2. Timeline for Moderately-Complex Projects

Timeline For Complex Projects

Here are timeline estimates for a high-complexity project, one that targets multiple applications for multiple functions, with thousands of dispersed users, multi-lingual requirements, and many integrations.

The tool selection could take from three to six months and will require good coordination among the functional groups and IT. Make sure that everyone buys into the decision, as you're sure to hit some problems later on. It's not unusual for a group to break ranks or attempt to sabotage the project because they were not part of the initial decision. At the same time, don't oversell the project because you don't want participants to have an overly rosy expectation. Without an appropriate-level executive sponsor, success in this phase alone is unlikely. All this is true of any project but it becomes particularly important for complex projects since the likelihood of problems is much higher.

Selecting an integrator is an absolute requirement for complex projects. The good news is that a project of this size should be highly attractive to potential integrators. The bad news is that few integrators have the required resources and experience to bring complex projects to a positive conclusion, so spend plenty of time checking references, both for recently-completed projects and projects that are still in progress. Because you will be working with large integrators, you can never be sure exactly who will work on your project, which is too bad since it makes such a big difference. Ask the references who worked on their project and who was especially valuable .

Count on two to three months to find an integrator. Some of the process can be accomplished simultaneously with the tool selection process. For a large project the integrator may need some time to assemble the team that you need so there may be some waiting time involved.

Implementing a complex project can take years! Focusing on the initial rollout, we will use a range of six to eighteen months, although six months would be particularly quick (and desirable!) while eighteen months would be dangerously long for the first step in the rollout.

It's essential to use a layered implementation strategy so that you get regular deliverables that allow you to test the system as you go. Nevertheless, the first deliverable may not happen for six months or so since you will probably need to customize the data model and the basic screens. Data migration (moving data from existing systems to the new system) is always an issue with larger projects and it also adds to the timeline.

Adding it all up, a complex project will take 10 to 24 months or more (see Figure 3.3). This is huge and perhaps you would like to aim for something a little shorter. If so, try these strategies.

• Dare to do an accelerated tool search as described in Chapter 6, "Shopping for a CRM Tool." Usually large projects are conducted with traditional RFP methods that are thorough but time-consuming, but if you are in a hurry you may want to be bold.

• Seriously consider a suite tool. Having some level of pre-integration should save you significant time during the implementation.

• If you do select different tools for different functions, work out the integration strategy early on, ideally before making the final decision on the tool selection.

• Once the tool selection is completed, work on a joint data model, then proceed with parallel implementations by business function. This method will allow you to 1) meet urgent needs first; 2) work around the scheduling constraints of various groups, for instance avoid deploying a new SFA tool in the last fiscal quarter of the year; and 3) spread out the integrator staffing requirements better, which may allow you to increase the quality of the staff

Figure 3.3. Timeline for Complex Projects

Why Timelines Cannot Be Compressed Easily

We discussed various ways to keep the timelines to a minimum and those techniques will help. But does it have to take so long? Yes, because there is a fair amount of waiting time. For instance, when we talk about tool selection, it will take some time to arrange for a vendor demo. It will take some time to assemble your evaluation team, not to mention scheduling around the team members ' requirements (this is one of the reasons why smaller companies and smaller teams move so much faster). It will take time for the reference checks, which is certainly not the place to cut corners. Negotiating the purchasing contract is another area where some patience will be amply rewarded. Even if you know what you want, it's unlikely you can complete the selection step in less than a few weeks without paying close to list price, which is definitely not a good outcome for CRM purchases. Much the same is true of integrator selection. Here, the additional issue is scheduling. The best people tend to be busy, and there can be a real advantage to waiting for the particular individual you want to become available for the project.

Interestingly, the implementation phase is one that can often be compressed, although not all activities within the implementation phase are good candidates for compressing. We'll discuss this at length in Chapter 9, "Implementing Your CRM Tool." For now, suffice it to say that any activity related to customization or integration can potentially be shortened , cut out altogether, or scheduled for future phases. Other areas are not amenable to compression, including planning and testing. Planning is essential to make the right decisions on what should or should not be done. We will see how to conduct an effective planning session in Chapter 9. As for testing, many otherwise lovely CRM applications cease to function properly under high load conditions, so don't skimp on testing if you want to be successful.

Why Vendors Substantially Underestimate Timelines

Ask almost any CRM vendor how long it takes to implement their solution and you're likely to hear "under 60 days" or, if they are really hedging, "We have several customers who have gone live in less than 60 days." The reality is that most customers take months to implement CRM solutions. What's going on here?

• Some customers do go live in very short order. They typically have a burning business need and are willing to sacrifice customizations and a perfect fit to get to their goal. Most of the time, the super-fast rollouts are followed by more or less extensive re-implementation efforts, sometimes starting immediately after the initial rollouts, to handle all the customization issues that could not be addressed the first time around.

• Customers with low-complexity projects can roll out much more quickly, as described earlier in this section. Even without a pressing business need, simple projects go faster. If your requirements are complex you simply won't be able to achieve the same results.

• Even customers who complete their rollouts within reasonably long timeframes may bring the tool up quickly, perhaps to a small pilot group, before they work on the customizations and integrations they need. They do implement, in a fashion, in 60 days, but it's not a full and complete rollout as most people would define a rollout.

• On the other hand, a sizable number of customers suffer protracted implementation schedules because of political issues, project management weaknesses, or lack of technical resources completely unrelated to the underlying tool. Understandably, vendors don't wish to include such experiences in their records.

• Vendors know very well that customers are afraid of long implementations, therefore it is in their best interest to minimize the time required to go live.

What should you do to get a better picture of typical implementation times for tools you are considering?

• Ask a friend . Your network is the best resource for unbiased information about implementation requirements.

• Keep informed . Trade magazines and web sites are full of "war stories" about CRM implementation (Chapter 12 lists many such resources). Although you need to use your usual caution about overly fawning or, on the other hand, gloom and doom articles, you should be able to get more reasonable estimates from these sources. Be sure to consider projects that are similar to yours in complexity. What took Giant Company 36 months to achieve may have little bearing on what you are doing.

• Ask the references supplied by the vendor . Clearly, the vendor will not give you negative references (and, if they do, run!) but you should be able to get realistic assessments through simple questions. We'll come back to this in Chapter 7, "Buying a CRM Tool."

• Ask for details . When the vendor says 60 days, ask for a written commitment. Ask for the names of a few customers who rolled out in that period of time, then ask if you can talk to them. Ask what modules they deployed, and how many users they had. Ask who the integrator was. Good investigators know that plenty of congruent details indicate that the underlying stories are true.

  If the vendor will provide the implementation services, don't sign the license agreement without a detailed statement of work for the implementation piece, including a schedule and a resource estimate.

• Multiply vendor estimates by two or three . This crude method yields surprisingly accurate results, and it's certainly faster than any of the techniques above.

What if the vendor makes some outrageous claim, such as implementing in a week? Using our handy-dandy multiplication rule above, you know that it really means a month, but still, a month is a really short time. What's going on? It could well be that you have stumbled upon one of the new-wave vendors who offer simple but powerful applications. Assuming you can verify the claim, you can be sure that the tool will be very easy to implement, maybe not in a week, but within weeks, not months, and also that you will be limited in the amount of customization you will be able to do. If that meshes with your requirements, you will be rewarded with a quick rollout, and an inexpensive one too! Just don't hope to make extensive integrations and customizations, either now or later, with such a tool.

Layered Implementations

Layered implementations, whereby features and customizations are delivered through repeated, relatively short- term deliverables, are an excellent strategy to counter-balance long implementation timelines required for complex projects. They are the practical application of the small steps prescribed under the "think small, dream big" principle described in the section about success factors.

It's somewhat difficult to define layered implementations in terms of what they are. So let's see what they are not .

• They are not feasibility studies . Although there may be changes to the tool and its customization as a result of a deliverable, each deliverable is a step towards the goal, not a test of whether to proceed with the project.

• They are not pilots . They are part of a formally approved program on a formally adopted tool.

• They are not testing vehicles . Each deliverable is a fully- tested whole, although it will often be used as a test environment to determine what enhancements are most important.

• They are not cop-outs from more grandiose plans. You know the story: it's two weeks before rollout and three major features just are not working. In addition, there's no way that screens can be customized to fit the new color scheme. So the features are cut, the screens left as-is, and code is rolled out on the target date, although it's code that bears little resemblance to the plan. This scenario is not a small step; it is a partial and incomplete deliverable. Not necessarily a bad thing under the circumstances, but it lacks the planned aspect of a layered strategy.

Most implementations benefit from a strategy of layered implementation. Layered implementations allow you to build on success while minimizing failures (and making it easier to recover from failures).