The value of Degree of Fit: understanding risks

image The degree of fit is an important indicator of your project’s alignment with the standard functionality.

After you determine the degree of fit, and understand what it means for the project, do you just passively accept the findings, or do you do something to make them more favorable?

The degree of fit and project risk

Personally, I like to regard the degree of fit as the risk factor, or reverse risk factor. The higher the degree of fit, the less risky the project is, and vice versa.

When you have a fit, there is no risk, because you are certain that the requirement will be met with standard features. (Therefore, be absolutely sure before declaring something a fit – if you are not, try dissolving the big requirement into several smaller ones.)

However, with gaps, there is always uncertainty—and uncertainty equals risk. In my opinion, the degree of fit explains how much risk there is that your project won’t succeed (in the means of meeting its scope). For example, the degree of fit of 72,4% means that there is 27,6% risk that the project won’t meet its scope.

When you look at the degree of fit from this angle, it is an important figure for both the consultant and the customer, because it tells how wise it is to proceed with the implementation. If there are 20 fit requirements and 40 gap requirements, it would give you a degree of fit of 33,3%.

What does this figure tell you?

To me, it says that you have about 33,3% chances of project success, or 66,7% risk of project failure. How comfortable are you with this? What figure would make you comfortable?

Regardless of whether you are a Microsoft Dynamics consultancy or a prospect customer, you should set your limits about how low you are ready to go. The theoretical limit for a sound degree of fit is obviously 50% and at this level it is already extremely risky—you face as much chances of failure as you do of success. Degrees of fit below 50% mean that your projects are more likely to fail, than to succeed, and you should do some extensive risk response planning if you decide to proceed.

Personally, I’d set safe limit at about 66%, anything below indicating a high risk project. You might feel comfortable with lower degrees of fit, but smooth execution of these projects requires high levels of project maturity of both consultancy and customer organizations.

Beating the odds

Not only does the degree of fit map nicely to the understanding of the risk factor of the project, you can also apply some risk management techniques to make it more favorable than it initially is.

A low degree of fit doesn’t necessarily mean you need to cancel the project and part your ways with the customer—it merely alerts you that you might need to rethink the scope. While every requirement is equal in the terms of relative weight it adds to the total degree of fit, not every requirement is equally important. There are critical requirements, there are nice-to-haves, and there may be several shades in between.

With a lot of nice-to-haves contributing massively to a low degree of fit, your actual degree of fit is blurred. You can easily drop some of these nice-to-haves from the project scope, and get a more favorable degree of fit. This would be equal to avoiding the risk, from the risk management perspective.

There are also ways to mitigate the risk. When there are a lot of critical gaps, those that you can’t simply avoid by excluding them from scope, maybe you should think about third party add-ons. Instead of engaging in a high-risk development, you could turn a lot of gaps into fits by choosing the right add-on solution for your customer, thus shifting the degree of fit towards higher, more acceptable ranges.

All that said, the degree of fit is an important metric that tells you a lot about your project and helps you steer the wheel long before you commence the actual implementation work. It is a useful tool in deciding whether a Microsoft Dynamics product is a good solution for the customer, but also in determining the project scope by balancing the non-critical requirements with the critical ones.

In one of the next posts I’ll explain why gaps are risky and why low degrees of fit make for high risk and high cost projects, in short and long runs alike.


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.

Leave a Reply