Key Considerations in Communicating Process Change
How to use process mapping and workshops to ensure digital transformation is successful

Editor’s note: This is the fourth in a series of blogs that help you help your clients drive more effective change which leads to better user adoption and more successful implementations. Please see posts one, two and three for more insight into why change fails and how to pick the right change strategy for success.
In my last post, I touched on key tactics for getting change to stick after a digital transformation, and I’d like to dive deeper into one key aspect of ensuring change is successful: effective communication. In order to be truly effective, communication around change needs to cover a number of details:
- who needs to change
- what behaviors need to change
- what day-to-day activities will be different
- what organizational or reporting structures have changed
- what physical changes need to happen, and how they will be measured.
Here are a few tips for communicating all of this information successfully.
Use process maps to show changes in operations.
Getting people to change their day to day activities and behave differently is potentially the most complex information to convey and a common language is required. This common language is about operations (doing things) and therefore is best conveyed with process diagrams. That’s why a process map with a simple notation has proven to be a really effective approach for communicating, embedding and reinforcing the changes.
We’re not talking about a huge daunting flowchart, but rather a hierarchical process map where each diagram has only 8–10 activity boxes so that it can be easily understood. Each activity box can drill down to a lower level and so on, for as many levels as needed. The process map could be a hierarchy of 10 or 500 diagrams. And the devil is in the detail.

At the lowest level diagram with the activity boxes link to the supporting information that adds color, context and help to the step. The linked information could include:
- guidance notes
- link to launch the Salesforce screen, report, dashboard or process builder
- Quip documents
- training content or video
- images of screenshots with filled out fields and explanatory notes
- meta data such as KPIs, Lightning ready status or Customer touch points

Some of the changes may appear subtle, but have a huge impact. For example: Contact and qualify lead is the process step. The rules for what determines a “hot lead” may be changed. That is all. And that is change is in the guidance note attached to the activity box called Contact and qualify lead. But also attached might be a short video showing how Salesforce should be updated to reflect the new way of qualifying leads.
Consider adding a workshop.
Most change may be more far reaching. In that case, it may require a workshop with the business users to get agreement into the new operational processes. I say workshop because a workshop is by far the most effective way of starting the change management process. The top-level diagram sets the scope and rapidly gets agreement.
The collective development of the new top-level and lower-level process diagrams drives buy-in and engagement. The workshop delegates are sponsors and cheerleaders when the changes are rolled out because they were the architects of the change.
“But our clients won’t pay for a workshop.”
Not true. Experience from 1000+ projects is that clients love these workshops. Often it is the first time the senior team have collectively seen their business area from an end-to-end process perspective and gotten agreement on handoffs. You can identify “quick wins” out of the workshops which can be implemented without system changes — adding to the project ROI.
The top-level workshop will take no more than half a day. Workshops to develop lower-level are a lot faster as you get into greater levels of detail. You and your clients will be staggered by how fast you can develop the process content when you use this simple notation.
Also keep in mind that it is much quicker than developing Word documents or huge Visio/Lucidchart diagrams if you use an app designed for requirements management and live mapping workshops.
Remember: process documentation drives up agility (yes, really).
You need traceability from requirements through to the release of the app. You can tie together requirements, activity boxes on the process diagrams, users stories and documentation of the configuration. With this, the client has a basis for further change and it makes them more agile.
Poor documentation means the client is very reluctant to make changes to their Org because they don’t know what will be impacted and break. The stifles innovation and your ability to work on follow-on projects. So everyone gains.
Stay tuned for the next blog post in the series, which will help you get from good to great with three simple questions when mapping.
Ian is the CEO of Elements.cloud, an app that helps you clean-up, document and build your Org. Get a view or your Org you never seen before with a 14 day trial on AppExchange

