Estimating the Cost of a Microsoft Dynamics CRM Implementation

Many government agencies are using Microsoft Dynamics CRM to build line of business solutions using an approach that Microsoft calls xRM. One of the challenges is to calculate the cost of such an implementation.

One of the questions I am asked most frequently by clients is to estimate the cost of a software implementation project. My most common answer, “it depends,” is not satisfying for them or for me, so I am going to explore this topic in depth and offer an approach for estimating implementations of Dynamics CRM, especially the xRM approach which involves using CRM as a development platform for a line of business solution.

There are several approaches to project estimation which can produce results with a high degree of accuracy. In all these approaches, the traditional trade-off triangle among time, cost, and features still applies. If you want more features, the cost will increase.

You can start with the easier items to estimate, the hardware and software. For hardware, many organizations use standard server configurations, so costs are easy to determine. Don’t forget to include all the environments that will be needed. Enterprise solutions usually call for development, test, and production environments (and sometimes a staging environment). Software licensing is driven by the number of server and user licenses which are required for your solution. Microsoft offers external connector licenses for users outside your domain in lieu of user licenses.

If you choose cloud or hosted as your deployment model, the hardware and software licensing is usually included in your monthly hosting fees.

After you nail down the hardware and software, the more challenging part is estimating the cost of professional services.

Approach One: Find a Similar Project

If a similar solution has already been implemented, this can be the shortest path to an estimate. For instance, my company InfoStrat implemented a Dynamics CRM solution called Stimulus360 for about 19 clients, so by the time the third or fourth client approached us, we had a pretty solid idea of the cost elements and the variables in order to estimate the project. The question to ask is whether your requirements will be different from other clients. Ideally, you could examine the features of the solution and map them to your requirements, highlighting gaps where new features would be needed.

Approach Two: Function Point Analysis

A second approach, and perhaps the most classical approach for custom application development, is function point analysis. Detailed requirements are written down, and software developers group them by complexity and ascribe a level of effort for each function. The rub is that these requirements need to be quite detailed indeed. A requirement such as “can integrate with other systems” or “must be user friendly” had no place in function point analysis. At a minimum, you would need to define every data element to be tracked, every form definition, every report, every workflow, and every business rule. Most clients are not willing to provide functional requirements in such detail.

Approach Three: Define the Time and Team

Another approach is to nail down the schedule and define the cost, with the only variable being the functionality to be delivered. For instance, if you have a firm ship date and a team of a project manager, and analyst, two developers and a tester, you can easily calculate the cost. Then the functionality will be determined during the course of the project through prioritization. One or more iterations may be created in order to seek feedback on the design and solidify the requirements.

Approach Four: A la Carte

If you cannot specify the requirements and are not willing to define the schedule and budget, you can tackle an estimate by defining each of the cost areas, with greater or lesser confidence depending on the area and the assumptions.

Here are the key areas we look at for estimating services costs. Note that hourly rates differ depending on the role and qualifications of team members.

1. Requirements Analysis. How many people need to be interviewed? How much time will creating functional requirements take?
2. Design. What design documents need to be created? Do you need graphic design for a web site or will you using an existing style?
3. Implementation. The level of effort for building out the solution cannot be estimated before requirements have been compiled.
4. Testing. Who will test the system? What types of testing will be performed?
5. Project Management. Who will manage the project? How often will status meetings be held?
6. Training. What approach will be taken for training? Train-the-trainer? Classroom training? Training videos? How many sessions will be held? Will training be conducted in-person or online? Do system administrators need training?
7. Support. Who will handle post-implementation issues? Will there be a help desk? What hours of business will be included?

Within these broad approaches to estimating, there are many variables which affect the cost of a project. Hourly rates of all the team members make an obvious difference, but other factors can be just as important. How much support do your users need to be successful? Is onsite support needed? How will the solution evolve after it goes into production? Will enhancements be needed? What will the release schedule for new versions be?

These are some of the considerations that determine the cost of an xRM implementation. By spelling out as much of these factors as possible in a solicitation, more accurate estimates are possible.

For six more installments in this series, see my blog at blogs.infostrat.com