By: Rahul Mohta
Editor’s Note: This article is adapted from the authors’ new book, Implementing Microsoft Dynamics 365 for Finance and Operations.
After defining a project charter and a project plan for implementing a Microsoft Dynamics 365 Finance and Operations Enterprise edition system, the next step is to build the foundation of your project by collecting requirements and performing analysis. Key objectives of the requirement gathering and analysis phase of the project typically include identifying the organization’s business process and goals, defining project scope, finding fit gaps, and developing a solution blueprint.
Analysis of requirements
Requirement analysis is supposed to be done by people who already have expertise in the Dynamics 365 solution. The expert could be external advisors/partners or internal team members and should bring in vital experience with solution guiding 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 conference room pilot (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, consider 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 in. Care must be taken not to customize the Dynamics 365 solution beyond 50% of the core functionality. Such a scenario would be similar to a magician who has several balls to juggle at the same time. You should certainly try to avoid such a conundrum.
Classification and the impact of gap
The extent of gaps from a customization perspective should be carefully defined. Some usage examples are simple, medium, and complex. The impact of a gap is essentially twofold: impact to other business processes and requirements, and impact to the overall solution. Both the impacts should be well thought out and documented for solution planning.
Ensure that you capture both the extent and impact, as they are like two sides of the same coin. Both are needed to evaluate the solution options, feasibility, acceptance criteria, and other highly influential elements of a project’s success.
Workaround analysis
Before moving forward with planning any customization, ensure that the solution owner has exhausted all possible workarounds to solving the gap. When possible, look for multiple workarounds, come with a SWOT analysis, and jointly discuss in a project.
The team should also consider supported third party solutions instead of customizations. For example, use Microsoft AppSource to search all solution providers and their capabilities. When customization was the only resort, look for the estimates, extent, and impact of the gap to ascertain if it makes sense to get a ready-made solution addressing all or most of the gaps.
After careful evaluation of all workarounds, when no alternative exists, then planning for customizing the solution should be taken up. Often, when thinking of solutions, there are situations when the solution may not be comprehensive enough. You should capture all risks, issues, and potential side effects along with the customization approach.
It is recommended that you always get the right stakeholder buy in for all the major gaps with their solution propositions.
Ballpark estimates for customization
Preparing estimates for customization could be done at the time of customization envisioning or, subsequently, upon finalizing the customization approach. Estimation techniques are out of the scope here; however, you should always explore the best-recommended estimate techniques applicable to your project.
Build or buy decision for gaps
Based on the estimate, complexity, and the comfort level of the partner solution versus in-house capabilities of customizing the solution, you should be able to make the decision of make or buy. Similar situations may still have a varied effect on decision making, and hence, it is advised that you always evaluate every project undertaken in the Dynamics 365 world.
Having analyzed the gap and with the solution options zeroed in, it is time to build the entire solution proposal from bottom up.