4 strategies for a favorable Degree of Fit

  • Post category:Sure Step
  • Post comments:1 Comment
  • Reading time:8 mins read

If your Degree of Fit is just not there, or the balance between it and the budgetary estimate is not favorable, the risk that project will exceed the budget or not meet the requirements is high, but you might still decide to go on. In fact, most consultants often do, choosing to fight the odds. According to field reports, this approach often fails.

There are four things you can do to ensure the customer satisfaction while keeping the project in budget and still reducing the risks by increasing the degree of fit.

Let’s see what they are.

Jumping into a low degree of fit project often means many customizations, and customizations are extremely difficult to estimate. Show a specification to four developers and you’ll get four different time estimates. And statistically, all four have 93% likelihood to exceed their own estimates.

Pair that with the fact that budgets are often unrealistically low (again, field reports find that consistently and clearly), and you have a perfect recipe for disaster.

Fit Gap Analysis is a wonderful tool you can use to avoid project failure, and prepare a customer for a better project, however consultants often miss this important early opportunity to communicate to the customer why and how it is risky to undertake costly customizations, and just avoid any discussion about possible alternatives.

If you have a low degree of fit, and are tight on budget, you must either have all internal and external influencing factors totally in your favor, or you must be extremely lucky, or both. Statistically, chances to get your ERP implementation project in budget, on schedule and fulfill the scope are about 1%. In all the likelihood—you will fail.

There are, however, four things you can do to prevent the failure, and whenever I encounter a low degree of fit paired with a tight budget, I try discussing, in the order presented, the following alternatives.

1. Discuss possible alternative approaches to requirements

Customization is a nice tool, and when reading Microsoft’s marketing materials it’s just a magic wand especially when it’s about NAV, and it can turn your NAV into almost anything imaginable. But.

That’s not what you should do. There is the reverse side of the medal, and it’s not that shiny at all.

Customizations not only come at a cost (and customers are sometimes willing to pay the costs) but they also bring risks. Short term risks include poor estimates, issues at testing, issues at acceptance, poor understanding of customer’s business and requirements (far too frequent to be just ignored). Long term risks include increased costs of maintenance, support, upgrade and generally ownership of the solution, and well—unhappy customer.

In fact, I could never stop warning about avoiding customizations, and in my opinion, customizations should be presumed a wrong approach until proven otherwise.

Instead, you can try turn a gap into a fit by slightly modifying a process. By giving up on some tiny non-critical aspect of a business critical requirement, a functional gap can easily be met by standard functionality.

Sometimes you can decide not to do everything through the system, and have people still use phones, pen and paper. Not everything has to be recorded in the ERP, and trying to squeeze every single bit of generated business information into the ERP, you will make it slower, less responsive and less reliable, and will fight the customizations for months or years. And your customer will pay for that dearly.

You can even suggest a general change of a process. Sometimes if you find a huge functional gap, and the goals of the process could be sufficiently met by changing the way how the whole process works, maybe it’s the time for the old process to go. Just remember—many companies implement ERP specifically to achieve exactly that. Which makes me believe that most of companies, with a grain of open-mindedness and good will, can in fact do that as well. Yes, specific and unique business processes are every company’s assets and a source of competitive edge—or so I’ve heard—but if you can’t conclusively prove it with facts, you should presume it’s not the case. Far more often it’s not the case.

Doing any of these has tremendous potential of reducing the budget and increasing the degree of fit, both of which will contribute to a happier and more satisfied customer.

2. Discuss the increase on budget

If it’s their way or the highway, and you can’t touch the requirements and just have to deliver customizations, then don’t be afraid to explain that increase in budget is necessary. The customer will find that out eventually, and the sooner they do, the more satisfied they will be.

Consultants often refrain from asking the customer to increase the budget—and for reason. There are often competitors price-shopping around, and customers will sometimes just play along. Just mentioning a budget increase in these circumstances can be a total deal-breaker. And yet, taking on a project with high customization risk and unrealistic or very tight budget will be your demise. Yes, it can be your opportunity cost. Yes, it might be your investment. And yes, it can ricochet big time. And yes, it so often just does.

I’ve found that customers who are made aware that the budget is too tight, and who really understand the risks of trying to execute a customizations-heavy project on tight budget, are willing to discuss the budget increase. At least this kind of discussion will make them aware that they can’t have their cake and eat it, and that there are going to be compromises. Either requirements have to go, or the money does, and unfortunately that’s it.

3. Give up on some important requirements

If the budget can’t be touched, and in big corporations which often plan their expenses early this is exactly going to be the case, you have to take important functionality out, unless you and your customer are really passionate about gambling.

Taking an important feature out doesn’t necessarily mean it’s gone for good. You can postpone it, and implement it next year, when you will again have budget available.

Skipping some important functionality can easily have many other benefits. First, you get your customer used to the new solution gradually. Folks in finances get to use it first. Then you include sales and purchases. Then you add inventory. Then warehouse .Then manufacturing. This is not always feasible, but when it is, it can really turn your implementation from a disaster-bound pile of risk into a big success.

Again, if the customer is unwilling to give up on something important, and there is not enough budget, and degree of fit is low, it’s your final chance to warn them just about how risky their implementation will be. If they are still not convinced and want to proceed, than you can still choose to gamble (which I can’t and don’t recommend), or you can simply do the final step, which is

4. Walk away

Indeed. If your customer doesn’t want to understand that they can’t get the solution they require with the amount of money they have available (and you do understand that), then nothing else really makes much sense.

Walking away might seem like a no-no, and I have seen dozens of consultants jumping into similar projects just because they didn’t want to turn the business
down. Know what? Every single one of those projects failed. It can’t work. And it doesn’t work.

Walking away can have an immediate bad effect, especially if you badly need some boost to your cash-flow. Then you might just decide to enter such a project and worry about consequences later.

However, if you walk away, this sends your customer a very strong message: I am an expert in my field, and I am confident in my judgment, this project is impossible and I am absolutely not willing to discuss anything impossible. If your competitors are any competent, they will walk away from that project too, and your customer will have to consider the alternatives above. If a competitor takes the project though, you already know the outcome—and that customer might just come back to you later after they meet the failure, because remember—you are competent, confident and an expert and understood from the beginning what would happen—this can increase your customer’s trust in you.

Oh my—all this just from a Fit Gap Analysis? Well, isn’t it a mighty tool?


Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has One Comment

Leave a Reply