Fit Gap and Solution Blueprint Estimates

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

The Sure Step season seems to have started in its fullest for me – it is the second time this year already that I’m delivering the Sure Step course, this time in Copenhagen, Denmark, and I must say that I truly enjoy it.

Anyway, while discussing the Fit Gap and Solution Blueprint decision accelerator, an important component of the Diagnostic phase, a student asked me an interesting question: why do we need to give effort estimates to meet the requirements at this stage?

And indeed – isn’t it far too early to give or commit to any effort estimates at this early stage, isn’t there a huge risk that the customer might understand these estimates as final project estimates? What’s the true meaning of effort estimates during Fit Gap analysis in diagnostic phase?

Actually, the effort estimates at this stage have nothing to do with the proposal. Yes, they can be a valuable input into budgetary estimates later on, however, this early, and at this point, the idea behind hourly estimates is completely different.

These figures are actually very much related to the Degree of Fit, and are almost as important as the degree of fit itself. (I wrote about the degree of fit two times list year, if you need a short refresher, click here, then here.

The goal of hourly estimates here is to give an order of magnitude assessment of how much time you believe will be needed to cover a set of requirements for decision making purposes only. It is not intended to be a detailed, or scientific estimate, and you should by no means employ some exact estimation technique such as PERT at this stage.

Consider this: you conduct a product agnostic fit gap analysis, and you prepare four different fit gap analysis worksheets for for different Microsoft Dynamics ERP flavors. In the end, you end up with these:


Degree of Fit

Hourly Estimates














While degree of fit in itself is a nice indicator of how risky the project might be, and how difficult it might be to deliver the solution for the customer, the combination of the degree of fit and hourly estimates gives a much better picture.

In the example above, the degree of fit is fairly close for all products. AX is pretty good – with the degree of fit of 85% it would seem the best choice. However, with 300 estimated hours to bridge the gaps, you might want to consider other solutions.

While SL and GP have exactly the same degree of fit, their hourly estimates tell you clearly that SL will require less work to come from the standard solution to the one customized to meet customer’s needs.

Finally, NAV has the lowest degree of fit, but also the lowest hourly estimates.

Provided that all estimates are equally reliable, and that you bill the same hourly rate for all of the products above, you might want to give advantage to that product which will deliver the easiest solution, and that’s the one with least hours spent on customization and configuration.

Degree of fit doesn’t tell you anything about the importance of the requirements, as far as it is concerned, the business critical requirement has as much weight and as much influence onto the degree of fit, as some nice to have feature which has been listed as in-scope for the project. Also, it doesn’t care about whether you spend 10 hours meeting a requirement, or you spend 20 – both requirements have exactly the same effect on the degree of fit. Therefore, it might easily happen that you have a higher degree of fit with AX (as above), because you meet more features with standard AX, however, to bridge those 15% gaps, you need 300 hours. At the same time, you can only meet 78% of the requirements with standard NAV, but to bridge those 22% gaps, you’ll just spend 150 hours.

If the degree of fit difference would be higher, say 85% for AX, but only 65% for NAV, then the decision should definitely go in favor of AX, which would be less risky. But if you have close shots of the degree of fit for two different approaches, the hourly estimates is an invaluable tool to help you reach the decision.

Another good application of hourly estimates at this stage becomes obvious when you have to fine-tune the scope to fit the high-level budget for the project. If you are aware that you cannot meet the project scope within the budget, and you have to trade off features, then hourly estimates can help you reach the most achievable scope for the defined budget. By shifting requirements from Phase 1 to Phase 2, you can fine-tune the degree of fit, and, say, come up several different approaches where you can achieve the same degree of fit with varying effort estimates, focusing on different sets of requirements. If you can manage to deliver 90% of fit with 300 hours with one set of requirements, as opposed to, also 90% with 150 hours with another set of requirements, then you can easily fine-tune the scope and scale it to the available budget.

Again, you wouldn’t take these estimates as the definite and final, and they should by no means be your commitment, they are there just to help you, well, accelerate your decision. That’s what a decision accelerator should be all about, after all.


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