Categorize business requirements and perform gap fit analysis
Fit gap analysis is simply a process to help you identify what needs to be done and to help size and prioritize. Some projects and methodologies explicitly perform a fit gap analysis and call out the issues, whereas others accomplish the same results with different steps that might not be called fit gap. In fact, as a solution architect, you'll likely catch yourself performing a fit gap analysis in your head as you mentally evaluate a requirement to determine how you would solve it.
Fit gap analysis makes sense when you're starting with some level of existing functionality. For business applications like Dynamics 365 that might have many built-in functionalities, a fit gap analysis is important because whenever a "fit" occurs (meaning, the analysis already solves the requirement), you need to identify it and ensure that it’s not recreated by building a custom-developed feature. Additionally, the person who performs the fit gap analysis should have a good understanding of the app's out-of-the-box features.
The mechanics of performing the fit gap analysis can vary greatly from figuring out the solution in your head for a small project, to using a Microsoft Excel template, or perhaps by using Azure DevOps work items and then capturing the solution online. The tool that you use should help the process and not make it more difficult; the real value is in the output from the analysis.
To perform a fit gap analysis, you should look at each requirement/user story and note at least the following factors for each:
Severity of the gap or category - Categorizes each item as either being a fit, configured, custom, or other. The exact categories are up to your own descriptions. The goal is to broadly examine how many out-of-the-box features you're using versus how much you have to customize.
Level of effort - Sizes the amount of work for the item, which could be low, medium, high, or could be a rating between 1-10. Some teams use commonly known items like t-shirt sizes or playing cards. The important takeaway for this scenario is to be consistent.
Priority - Often, priority comes from the business, but the solution architect frequently needs to have some work prioritized higher to help the architecture foundation be put in place.
Implementation notes - This feature describes the work that it takes to close the identified gap and backs up the assumptions that you made in the other fields. For example, "Add a N:1 relationship to contact" might be enough to indicate that it's a configure category and that the envisioned work needs to happen. These notes aren't detailed design specifications, but more like high-level backups for the fit gap analysis results.