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.
Background
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.
First Steps
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.
- Documentation – I worked to document everything. As a new system administrator in the organization this was a great way for me to learn about the implementation I was working on. There were several ways I went about this:
- 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.
Long Term Changes
After understanding the system and business more, it was time to modify the state of the releases to make them more manageable for development and release. The timeline we agreed on was monthly releases. We would “require” all changes to be finalized in our Development environment a week prior to the release. This would allow time for testing in our Test environment and time to work on any communication or procedure updates.
This change did not happen overnight. It was a major shift for the business and end users who were accustomed to asking for changes and having them made in just a week or two. The users needed to understand the benefits of this change to get behind it.
These benefits include giving the team more time to focus on higher level changes, lower risk of issues with less frequent changes, more stable system, etc.
This is still a battle that I face as priorities shift quickly and changes are needed right away. We have worked to ensure when this does occur that it is documented so those making the decisions understand the full impact of these types of changes or interruptions.
Goal State
The goal state of our change management transformation consisted of a few things:
- 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.
Note I said this was a “goal” state. I am definitely not saying we got it all perfect all the time! This is still very much a work in progress each day!
Communication
Communication was an area of our change management strategy that went through many iterations. Originally we thought it was important for the full organization to know about every release but only impacted managers to know about specific changes. Then we wanted all managers (even non-users) to know about all changes as a way to promote the team and show value of changes. Finally we have settled on just informing our feedback (stakeholders) group of all changes. This team is responsible for ensuring these changes look good in Development and are properly communicated to their teams. We work to get this communication out as soon as we can so any issues or potential conflicts are brought to light early.
We have also stopped notifying all end users when we have minor releases. This prevents issues that “started with the changes last week” and allows the team to more effectively troubleshoot problems objectively.
The main lessons learned from our different variations was to give ownership of training and communication to the leaders of each department. This allowed the CRM/D365 team to step away from those responsibilities to work on making the system more effective.
After the release, we work with the stakeholders to capture successes and time saved. With large releases or changes we want to ensure teams monitor the before and after behavior so we can report these successes to the larger group.
Still Learning
Our system is still far from perfect. There are always other priorities that need to push items out of the way. There are always other distractions or issues that prevent dedicated work time. This will continue to be a work in progress. As the business changes, we need to change our processes to fit with new priorities.
The most important piece to change management is making sure you (as the system owner) fully understand your system and the way it fits into the overall organization. This will allow you to make the hard decisions, set priorities and plan releases so it is effective in your case. It is necessary to have someone with that ownership who can ensure valuable changes are being made to the system.
That’s where I have come so far. Still more to go and always more to learn. You can also learn more on this Release Cycles Panel Webinar from a few weeks ago.
What else has worked in your organization? Any change management goals for 2019?