Analysis of requirements

Requirement analysis is supposed to be done by experts of the Dynamics 365 solution. This expert could be an external advisor/partner or an internal team member and should bring in their much-needed experience alongside solution guidance options.

Customers must push their advisors/partners/consultants to seek solution options, both in the form of workarounds and in the form of customizations or extensions when a requirement can't be met with out of the box capabilities. Even when requirements are envisioned to be met out of the box, their mapping must be documented and should be validated during the learning/prototyping phase in the CRP approach.

When a requirement can't be achieved with out-of-the-box capabilities in a Dynamics 365 solution, then the solution analysis stage starts. Poor analysis will add more time, effort, and cost to the project. Every time you get a requirement that needs customization, try to think about how the other Dynamics 365 customers are using it. Ask why Microsoft (the principal) did not build the feature, and you will find pointers to push back.

When a requirement is a must-have and is legitimate enough to break a process, then the customization route should be taken. Care must be taken not to customize the Dynamics 365 solution beyond 50% of the core functionality as it would be similar to the situation of a magician who has several balls to juggle at the same time. You should certainly try to avoid such a conundrum.

We recommend that you do the following when analyzing the requirements as well as gaps from solution fitment:

Having analyzed the gap and with the solution options discovered, it's time to build the entire solution proposal from the bottom up.