Skip to main content

Estimating the Cost of a Dynamics CRM Implementation -- Part 1

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 many of these factors as possible in a solicitation, more accurate estimates are possible.

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