As we enter the new year it is always a good time to evaluate where you are and where you want to go. This is also a good time to evaluate how far you have come. I have been reflecting on the change management progress I made at my organization. Let’s talk through what that looked like, steps taken and next steps for the future.
I started as the first subject mater expert for Dynamics CRM (this is back when it was still CRM not D365). The organization had migrated to CRM 4.0 and then upgraded to 2011. So there had been a lot of fairly rapid changes all being managed by a team that had other non-CRM priorities.
This resulted in frequent releases, possibly multiple times per week. The solutions were built the night of or changes were manually made in each environment. Testing was on the fly and based on anecdotal system knowledge.
The team had done a great job on their CRM system and had developed their release process to fit the business. As the system and team matured, there was a need to adjust the process to fit the complexity of the implementation.
The change management revolution started with a few small steps.
- Building the solution first – whenever working on changes for a release the solution needed to be built first. This allows you to add items as you work on them and ensure nothing is missed. This ensured that on release night the solution was ready with all required components.
- Enforce the use of all environments – all changes needed to be done in all environments. We had a Development, Test/QA, and Live environment. It was important that all changes were made in Development in a solution (step 1), moved to Test as a mechanism for testing the solution, and then imported into production.
- This is important so your environments can stay as closely in sync as possible. We had a case where there was an option set with 50+ values. As the new system administrator, I added a value in Development and then moved the solution to Live. Then we found out that another team member had been creation options in Live that were not in Development. This meant the Live-only options were no longer visible or potentially overwritten by the Development options. Thankfully this was able to be resolved with no data loss due to the use of these records but that might not have been true in many other cases.
- Testing – I worked with the team to build a comprehensive list of test cases for core system performance. This was broken down into full regression test items and release night core items. Depending on the size of the release we could evaluate the level of testing needed and assign from a set list of test cases.
- Workflows – Automated processes are a huge part of this implementation but there was limited documentation on what these processes did or how they interacted. It was essential for me to have a deep understanding of these. I created a list of all workflows with high level details and then also created flow charts for the more complex items. Learn more in my post on Keeping Track of your Processes.
- High level CRM/D365 Roadmap set by the team of important changes. This is specifically for large projects or items that may not be known to the business. This could include business priorities such as a new integration that is expected to take a fair amount of work and potentially multiple dedicated releases. This also included system Upgrades. These are not necessarily business-driven but are important to minimize future risk.
- Prioritized backlog of all items waiting for work by the team. Priorities set by the team and users to ensure the best items are handled first. Reviewed consistently so old items can be removed or upcoming items refined.
- Feedback meetings to gather requirements and discuss changes with stakeholders. We were able to implement some cross-functional feedback groups to assist with the backlog management. This gave users the opportunity to share their needs with the team and gave other users the opportunity to discuss. This was very important to ensure changes for one area of the business did not negatively impact another aspect.