The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
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
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.
Business Applications communities