Many of the elements and situations that are blocking improved customer- centricity are often intertwined. Since many of our internal pain points feed each other, there will be changes that must happen before some other problem can be solved. For example:
- You might need to reconfigure departments and hire stronger people onto those teams. But we might have trouble attracting and retaining key CX staff while our processes around CX strategy and tasks are ugly. Candidates might not want to join or stay in that environment. While we are hiring, we will have to fix other things that are interconnected.
- You want to improve relationships between teams and the processes they are using. However, if the KPIs and metrics coming down from the top are customer-peripheric, we could be using new processes but still creating customer-peripheric PSE.
Before you try to create change, break down some walls, and rebuild them, you should map out and consider blockers that could prevent that change from happening. You might be able to predict these, or they might come up as you go. Map these with their appropriate dependencies. I call this a “Change Dependency Map.”
For example, we might imagine that training is the main ingredient needed for change. Let’s send everybody to Debbie’s training so we will all be ready to improve customer-centricity! Sure, but there will still be blockers.
- Do we have enough CX Researchers available to do all of the research that being customer-centric requires? If not, the change could stall or fail. We will first need to hire some people or shift personnel around so that even just one or two teams are ready to try new ways of working.
- Are our teams empowered to break out of how we do things now and try new processes, methods, and approaches? If not, all the training in the world might not produce the desired actions or outcomes.
- Did we plan extra time to try new ways of working? It’ll probably take us longer than our old ways, especially while new processes are experimental.
- Did we estimate this time and update our roadmaps? Did we change our release schedule so that nobody is surprised that the new project is taking longer than usual?
- Forgetting to plan extra time to try new ways of working could block our goal of successfully experimenting with more customer-centric processes. Estimating time, updating roadmaps, and changing the release schedule are dependencies under “planning extra time.” This is why the Change Dependency Map is a tree or hierarchy; fixing one or more problems unblocks a higher-level problem.
- How will we measure if our customer-centricity adventures are starting to work, or where we need to improve?
- Do we have KPIs and OKRs in place? Are we ready to track and measure everything that we need to?
- Does the team believe we are tracking or obsessed with the wrong numbers? Are teams under pressure to deliver customer-peripheric KPIs? We will have to shift or fix these to remove obstacles that can block the change we want.
Some companies bring in expensive trainers assuming that if we train everybody on this topic or method, we can then use this method, which will solve our problems. The example map reminds us that trainers alone rarely solve a problem or create a transformation because we haven’t cleared the blockers and dependencies.
Map anything that will block desired changes and outcomes. What must change before we can create the final or larger change? Work on changes at the lowest level of the hierarchy first so that teams are freed up and empowered. The lowest level of your map might be root causes blocking other changes. Mapping these out visualizes and socializes obstacles so that we can plan to eliminate them.
The sample map above has a broad and high-level goal of being more customer- centric. We can use a Change Dependency Map for a change at any level: project, team, department, or company. Our desired outcome might be very specific or a broader vision.