In Part 1 of this two-part series, we looked at what change management is, why it’s important and how to create a change request form in Salesforce.
In Part 2, we look at how to overcome the challenges associated with a process change, why you should consider creating a scheduled release and how to use the new admin request metrics to drive conversations with stakeholders.
Opposition to Change
First, I wanted to take a moment and say that when implementing this or any other process that pushes people out of their comfort zone or routine, you will face opposition.
From my personal experience, users find changes in process to be frustrating. To this date, I still have users who loathe entering an Admin Request. They would rather send an email or come to my desk to vocalize their request.
It’s important that with any change you’re implementing, you don’t take the pressure off. People need to know that you are serious about the change and there is no going back.
In Spencer Johnson’s classic book Who Moved My Cheese?, Johnson says “If people perceive that you are not serious about doing things the new way, they will go back to the old way. Sometimes this will be in the open and sometimes it will be covert. The leader must remind people that there is a new course and the new course will remain.”
Remember, regardless of the size and impact of the change you’re implementing, you are the leader. You are the change agent. Stick to your guns and don’t back down.
Scheduled Release Cycles
Everyone knows that scheduled releases are part of any change management process. We see this at least three times a year when Salesforce releases their major updates.
At this point you’r probably saying “Brent, I am a solo admin. I don’t have time to schedule a release and try to manage a release cycle.” Trust me. I understand. I was a Solo Admin for 4 years. I get it. There are just not enough hours in the day to get everything done.
I want to be clear that creating a scheduled release cycle should not happen at the same time you are pushing users toward your new change request forms. At ReadyTalk, we played with this change request form for a year before feeling confident that we were capturing all of the information we needed from users and getting users to adopt the form. We have just recently started deploying changes on a release cycle.
However, to plead my case, I want to outline the pros and cons of a scheduled release cycle.
Pros of a Release Cycle
- You’ll utilize your time better knowing that there is a deadline to work towards.
- Get your users used to a change cadence. This will help those users who are change adverse to cope a little bit better.
- Allows for better communication to team members.
- Proper planning can go into scheduling of your time to properly release the changes.
Cons of a Release Cycle
Can be difficult to start. They are too complex. People are going to be upset. I won’t have time to make all of the changes in the allotted time.
I’ve crossed out all of the cons because these are not cons. They are excuses. This is not a difficult or complex process to implement. That being said, with any new process, there will be some bumps and unforeseen obstacles that you’ll need to get around but your organization will be better off for it.
Implementing a Release Schedule
Start simple. At ReadyTalk, we’ve started with a weekly release schedule. Here’s how it works:
- Tuesday – My team meets for a status meeting to share what we’re working on and any obstacles that are preventing us from completing a request. This is the meeting that we talk about the items that will be a part of the upcoming release. During the remainder of the week, we collaborate on our release notes and get them ready for publishing.
- Monday – Release notes are sent to all of our Salesforce users. These release notes include tips and tricks and general news in addition to release specifics.
- Friday – Changes are made in production. This allows us to deploy changes over the weekend if the need arises.
We use Confluence to document all of our system processes so this is the natural place for our release notes to live. However, there are many other options. Find out what other departments are using for documentation and leverage what is already available. No need to reinvent the wheel here.
Remember, this is what I do but it does not mean that this exact schedule is what you should do. Use my process as a template for what works in your organization.
Measure & Share
Now that the admin request are flowing, reporting against the data is important. You’ll start to see trends in the data that will help you to understand if additional training is needed around specific topics.
One of the nice benefits to reporting on these requests is providing the organization with visibility to the workload and open tasks and projects. If I know anything, it’s that most of my internal customers don’t know everything that me and my team do. This puts context around our work and the number of tasks we are working at any point in time.
Every three weeks, my team has a meeting with all department heads to review open items, upcoming projects timelines and more. We leverage this dashboard to help us communicate to this team how and why certain priorities are given and it provides a great snapshot of where and how our work load is distributed.
While this second part of the change management process may seem straight forward, there is a lot of organizational change involved. As a result, these pieces of the change management process may not be implemented right away.
Take some time to first figure out what information is important to you and your organization and track that in the requests. Fine tune the process as you go and be sure to communicate the changes clearly to all end users and stakeholders so that everyone is on the same page and there are no surprises.
Have you implemented a change management process in your organization? What did you do differently? What other advise would you suggest to an admin trying to create a change management process for their organization?
Share your knowledge and suggestions by leaving a comment below.
5 thoughts on “ Creating a Change Management Process: Part 2 ”
Brent – This is a good topic. While a Change Management process can be challenging for a team of 1, it is important if you need to scale up. We put a process in place five years ago and it has made life easier as we moved from supporting 10 business groups to 20.
I think the other important piece was our SDLC. We moved from Ad Hoc (lots of black tabbing) to Scrum (Agile) the first year. This helped to lay the ground work for a more formal Change Management process.
Scaling quickly is a great reason to have a change management and deployment process. While I don’t know a whole lot about Agile, I know enough to see the elements of the methodology in the process I’ve outlined here. Being that this is what Salesforce uses as well to deliver three releases a year, this is probably a good methodology to sync up with! Thanks for the comment!
Hey Brent! Finally got to read the rest of the Chagne Management series.
Id like to add that creating extra objects (even creating a new app) will greatly maximize and focus your effort. Have you ever thought of using Visual Workflow for a change request?
Thank you for another great article 🙂
Hi Jose! That focused effort is one of the main reasons we haven’t switched from our custom object to Cases. Folks have a clear understanding of where to go to create a request. Using Visual Workflow would be really interesting and may provide some good value. I’ll have to think through that!