Change management tips for redesigning processes in Anaplan

Author: Arun Thakar, Certified Master Anaplanner and Vice President in the banking industry.

As an organization embarks on its Anaplan journey there may be a lot of questions from the business on what Anaplan is, and what the final product will look like. User reactions to process change can be varied, ranging from uncertainty to resistance to eagerness. It is important for a project leader or solution architect to align the vision of the product with key stakeholders. Here are a few tips to set expectations and win over your organization:

1. Use process flows with swim lanes to show how different user roles interact with one another. It’s important that the personas of the planners are defined early in the project and can help with requirements gathering. If the process design is going to be a big change from the previous process, level setting with the key stakeholders early on will be a positive impact on the success of the project.
2. Design workshops can be fun and drive design decisions. Running a workshop doesn’t have to be cut and dry; it can be a good time for business planners to vent about their current process, which can be somewhat therapeutic for them! It’s a good idea to capture their pain points, and let them know what the capabilities of the platform are. It’s a good idea to have rules of the road for the workshop and set expectations on what are the key outcomes and objectives.
3. Start socializing the platform early by leveraging mockups in Anaplan as early as the first sprint review. It won’t be the final solution, but this is a valuable exercise for both the development team and the end user. For the end user, they get to see the solution come to life. It’s good to take notes on their reactions and assure them that this is an illustration with dummy data that will be refined as the build effort continues. For the development team, these wireframe dashboards will help understand what components of the model are going to take the most time to build and can help with the sprint and product backlogs.
4. Provide specific data templates and have them handy when speaking to data owners. Every model needs data. If it is unclear what data is needed, and where it lives, these templates will facilitate that conversation and can be useful in developing the data hub and integrations for the solution.
5. Collaboration is critical for success. Whether the business and development teams are siloed or co-creating together, having regular review sessions with key users, leaders, and champions from the business can make the final product better received.
6. Don’t be afraid to rearchitect. It’s easier said than done, but it also happens more often than we expect. A situation where the model architecture is constrained by some technicality and needs significant rebuilding can be a part of the process, and it’s the role of the solution architect to make that call and spearhead the revision.
7. Socialize the documentation efforts and hold knowledge transfer sessions. Towards the end of each phase, it may be required to provide documentation of the model. Whether the documentation lives in the model itself as notes in blueprints, or if there is an external document, admins need to know how the model is working and it's critical to spend time with them to review the logic and data flow.

Keep in mind that the success of the implementation is based on how users perceive the solution and whether the solution met the requirements of those users. The more enjoyable the journey, the better adoption by the organization and the more willingness to tackle future use cases. Aiming for adoption should be a top priority for solution architects and project leaders.

What tips would you add to this list? Leave a comment!