How much do Microsoft Business Central implementations really cost?

To accurately estimate the implementation of a business software is a very tricky task.  The consulting industry often estimates about one to one of software cost and service.  Which basically means that you end up spending the same amount on service as you will on the software to go live. 

I have found that in reality implementations are drastically different from one to another.  There are many factors that are at play which are extremely hard to anticipate.  In this post I am going to try to highlight some of the major factors and my take on the traditional and modern ways.

Traditionally...

Traditionally, fit/gap documents would be written up.  A consultant would write the business requirement, then list the features that the software had to meet and finally the features that would have to be customized to get to the final goal. 

It is, of course, very important to have a clear vision of what’s required, but in my opinion the fit/gap document is often a waste of time.

Why? Because a solid business software like Microsoft Dynamics 365 Business Central will have most of the standard features required by a business.  There is no need to write about those. 

It makes more sense to schedule run throughs of the business process in the software and identify where the user gets stopped.  It’s essentially the same thing, except with a lot less writing and a lot more understanding.

Fit/gap documents are often written based on the existing software in place.  Chances are that you would not want to replicate the existing system.  There is a reason why you want to change systems.  In order to adopt a new system, people and business processes have to adapt.  No consultant is going to know exactly what is going to happen before the project starts.  That is as hard as predicting the future and the actions of everyone around us.

You are probably thinking that this isn’t that hard and a solid document can be written that everyone follows with proper management.  This is of course possible but it requires a tremendous amount of effort.  If you were implementing 10 companies, exactly the same, it would make sense.  But you’re only doing one and it’s different than similar companies even in the same industry. 

Business Software projects differ vastly from traditional building projects.  When you need to move the location of a door in a house after it’s been built, that’s a hassle.  Metaphorically speaking, if you wanted to move that door in the software, it might take 10 minutes.  You want to take advantage of this power, which brings me to how modern software projects should be estimated and run.

The Modern way…

Agile implementation methodologies are becoming more accepted as the way to run software projects.  As the term agile implies, the focus is on being flexible throughout the implementation process.  You have a starting point and an end goal, but you only have a draft on how you are going to get there. 

As you embark on the journey, the options on which path to take at each milestone reveal themselves.  A competent team then makes the decision on how to proceed depending on the information gathered to that point.  This maximizes the likelihood of the best path being followed in the project. 

The project becomes like a chess game.  The ultimate goal is to win the game (successfully launch the ERP).  You have a strategy you start out with.  As each move is played you have to reevaluate your strategy, assess your position and make a countermove. 

Interestingly, when evaluating moves in chess, sometimes the best move is to go backwards, retreating the piece you just moved back to it’s former position.  This is uncommon, but it does happen.  It’s very hard, even for strong chess players, to consider this an option.  We naturally do not want to go backwards.  In an agile environment, that option is usually revealed before we have gone too far in the wrong direction.

Estimating Agile Implementation Costs

So let’s assume we all agree that being agile and flexible is the way to go.  How do we then estimate how much time and cost will go into an implementation?  

If we don’t know the exact path or even an approximate path, how do we plan our costs? My advice when it comes to this is to pick the shortest path to launch. 

When a company considers buying a new system, they dream of all the possibilities a new system will bring.  Some even demand that the system should have all the glory imaginable when it is turned on.  This is a mistake.  You want to get the system up and running as quickly as possible. 

In order to accomplish that, you need to identify the smallest set of features you can operate on and make those the launch objective.  This path is probably not going to be as costly as including all the features and it is going to be easier to estimate.

Once the system is running, do not consider the implementation finished.  In my mind, it just got started.  Many companies go into a post implementation slumber where they have implemented a new system and basically think they are done.  This is an illogical thought.  We are comparing the business software again to some item we purchase, like a car.  We will just drive the car until it breaks down and then we buy a new one.  Sophisticated modern software is not built to be behave like that.  It is built to constantly advance the company.  It waits for your team to unleash the power it brings to the table.

With the traditional way, we would document the supposed fit/gap between current and new system, draw a path to the end goal and estimate the work and cost to get us there.  This worked well in the sales cycle, but once the project got started the endless tug of war between reality and the fit/gap estimate started. 

A lot of effort would go into arguing over points in the document that seemed very reasonable at the project start, but then became illogical and still got implemented because the customer signed off on it!  Needless to say, it’s a recipe for budget overruns and endless change orders.  Not to mention the management headache.

With the modern way, we are saying that we do not have a solid budget, but we are evaluating every step of the way.  It does not mean that the project is going to cost as much as a SpaceX rocket launch. 

In my experience the cost of getting a company live can be anywhere from 1 to 3 times the software retail price.  It does not mean that company A which spent 1 times, is luckier, a better negotiator or smarter than company B, which spent 3 times as much.  It usually means that company A saw less things to improve during the implementation than company B.  Given company A and B being in same industry and of same size, company B might have found a competitive advantage to leverage and thus spent more. 

With that said, I obviously recommend working in the modern fashion.  Don’t look at the money spent on a software implementation in a negative light.  Rather, make sure you have a good team and that you are creating value at each step.  Adapt a thought process where you are constantly trying to find ways to elevate your workforce.  Embrace new technology in many quick and coordinated small steps.