Best practices in logging key decisions in your implementation project in Microsoft Dynamics 365 Finance and Operations one version D365FO

Best practices in logging key decisions in your implementation project in Microsoft Dynamics 365 Finance and Operations one version D365FO

Based on my experience, one of the top reasons that causes a lot of issues in project delivery is the availability and usage of a key decision log. This is one binding matrix that can streamline communications and expectations, and bring in a lot of delivery efficiency.

Once the solution blueprint and the solution design document are prepared, people seldom go back to the original requirement, that is, the Business Requirement Document (BRD), situation, use cases, and exceptions to understand, or people seldom recall what had happened and triggered a particular approach. Hence, it is crucial to always maintain a key decision log that is easily accessible to all the relevant project stakeholders.

Any decision that could alter the course of the project and impact its objectives must be documented. Also, the circumstances of taking the decision should also be noted, as this would complete the entire story for the decision. A decision may impact one or more requirements, and hence, all the impacted processes must be mentioned in the key decision as well. This will enable the various owners of the project to participate in the impact analysis and, hence, the decision making process.

Sharing some recommendations in managing requirements and key decision log:

• A business transformation initiative is not a destination; it is rather a journey that must constantly evolve. Hence, one must always keep the requirements up to date. This includes key decisions made in a process/requirement, and it should be easily available in RTM.
• Always capture the requirements in a SMART format. It should not have abstract details.
• Never assume any requirement; always get it validated. Validation is the best when documented and signed off.
• Requirements change over time and how you handle such changes decides the fate of the project. Scope management and change request should be the key levers for a project manager/CRP lead.
• Requirement collection and documentation is a zero-sum game; both the parties (on the business and solution sides) should participate well and the RTM should be a living document that is easily accessible, simple to understand, and that can be leveraged throughout the lifespan of project.

If you can tell and trace the life of a requirement, then it is a strong foundation for success. This traceability can subsequently be referenced in all business documents, and it empowers the change management initiative and, ultimately, project success.