Blog

Sometimes the Degree of Fit might seem like comparing apples and oranges. With 90 extremely detailed fits, and 10 high-level gaps, the degree of fit seems high, but it isn’t. 90 extremely detailed gaps, and 10 high-level fits, make the degree of fit seem low. In either case the degree of fit is unreliable and it doesn’t tell you anything at all.

For a degree of fit to be reliable, all the requirements should be specified roughly on the same level of detailedness. If they aren’t, you might have an extremely risky project before you, and you just don’t see it. Or you might have a slam dunk, and you stand scared to death by the non-existent risks you see all over.

In situations such as these you have to level the requirements to get a more meaningful figure, otherwise your Fit Gap Analysis doesn’t serve its purpose.

But how exactly do you tell apples from oranges in a requirements list?

In fact, the answer is not too straightforward, just because of the fact you have two rounds of Fit Gap Analysis: one through the Fit Gap & Solution Blueprint decision accelerator in the Diagnostic phase, and one through the Analysis phase.

In Diagnostic, you should keep the requirements at a fairly high level, and not go into too many details. For example, a customer might want to have access to the NAV solution through Web Services. Listing fifteen specific requirements such as “Customers should be accessible through web services”, and then the same for vendors, items, G/L accounts, etc. serves no purpose. It’s enough to just specify one single requirement which asks for the Web Services access to various parts of the solution.

In Analysis phase, though, you have to dive deep down, and specify and quantify every single requirement in such detail that you can’t divide it further. In example above, you should in fact specify each of the areas, documents, master data records, etc. which should be accessible through Web Services.

This is the first thing to ensure a realistic, reliable and meaningful Degree of Fit which provides valuable information to the customer.

However, sometimes it’s not that simple. Take these two requirements:

a) When a sales quote is created and the customer’s quote to order conversion ratio is less than a configurable minimum ratio for the customer group, all prices are increased by a configurable percentage.

b) Sales people can calculate the customized product price at the point of contact based on generic bills of materials and routings which include configurable parameters and formulas.

Obviously, both of the requirements are gaps and call for customizations, and both may seem to be roughly equal in detail, but obviously the first one is fairly simple, while the second one might be a time-bomb if you declare it a gap and just proceed.

The problem is – the first requirement could result in a day of work. The second one might easily take weeks or months. Having such an order-of-magnitude difference in requirement estimates can really distort your degree of fit to a level of being totally useless.

If this is the case, then my approach is to break the requirements that have huge time estimates into smaller packages of comparable duration. If you do that, the degree of fit is simply going to be more reliable and will tell you more about the project risks.

If you don’t immediately see why, imagine a) and b) cases above as being a part of two separate projects, each of which has 9 more fit requirements, each of which is estimated at a day of work. Both projects would have a 90% degree of fit, but project a) will have 10% of gap work, while project b) might have (depending on the estimate) about 80% of gap work. An equal 10% degree of fit just doesn’t do the second project right.

So, beware the degree of fit, and make sure the requirements are leveled and comparable. Otherwise, you could just skip the whole analysis and save your customer some budget.