Change Management: The Achilles Heel of Progress

jasnyder1973

Overview

The scope of the solution is aligned among the project sponsor, key stakeholders, and the architect. The solution addresses all the concerns of the current business process and will drive the expected results once implemented. The project rests on a “Big ****” implementation: a swap out of tools and processes that will re-engineer the entire business process. The only obstacle is the team that owns this function is not ready.

Can vs. Should

Ambitions outpacing the ability to realize them…sound familiar? This is not as uncommon as we would like to think and the question rests on a balance of can vs. should. Can we deploy advanced forecasting using statistical algorithms, Plan IQ, machine learning, etc.? Yes.  Should we? Is another question altogether. This rests solely on how much change this represents within the organization. Putting it another way, most people can drive a car, but if you drop them behind the wheel of a Formula One race car you cannot expect operational excellence immediately.

Navigating Need vs. Want

I have had the opportunity to work with many organizations to determine how to approach their objectives with new planning tools. As I engage in projects, I assess the maturity of the organization by determining what they are doing today vs. where they would like to be. An example of this would be today our organization is planning everything in excel, but we would like to move to statistical algorithms to forecast demand and determine inventory needs. This seems straightforward, but you need to weigh this against the context of the current state. 

The current process may be lacking sophistication but is well understood. What is being asked for may represent a great leap in sophistication vs. the current approach. If you swap out the current process with a statistical approach that is not fully understood, you may be headed for trouble. Fast-forward to a plan review with executive management and an executive asks the question ‘How did you arrive at this forecast?’ and the answer is roughly, ‘This is what the forecast algorithm told me!’ That outcome would be disastrous. While that may sound far-fetched, ask yourself if you are headed to that outcome.

Getting back to need vs. want—the objective is we need to get better outcomes out of our forecasts, and we want to move to more advanced forecasting methods. Separating these items will allow you to see what the progression should be in migrating processes and tools. Ultimately this should lead you to a roadmap to roll out the change.

Crawl, Walk, Run

With Anaplan you have a lot of flexibility to quickly move crawl to run. One of the most important things I realized early on with Anaplan is that at a certain point you can model faster than an organization can absorb change. This is a very powerful differentiator and should be wielded through the prism of can vs. should. 

As you work through your roadmap focus on the end goal of moving to more advanced forecasting methods while introducing key milestones (or phases) in that path. While Anaplan projects are structured in terms of sprints, the migration of large processes should be approached in similar terms. For example, as part of the migration to advance forecasting methods you may consider the following milestones:

• Deploy forecasting on Anaplan Platform with enhancements to the current process
• Build advanced forecasting into a model for comparison to the current process
• Evaluate advanced forecasting vs. current process
• Adjust the forecasting approach based on evaluations and feedback
• Sunset old (formerly current process) and cut over to advanced forecasting
• Continuously evaluate and improve on your advanced forecasting approach

The key takeaway here is that one should not only consider a metering change to enable the organization but that one can also use the Anaplan platform to facilitate change management. The ability to use Anaplan to pace an organization in its quest to change is a key differentiator and typically missed opportunity. Anaplan has the flexibility to quickly adapt to changing business processes and should be factored in as you build out a broader roadmap. Furthermore, each milestone must unlock value for the organization either by improving outputs or moving the organization toward its goal.

Conclusion

By no means should you advocate to change the objective based on organizational readiness, but you should advocate the path to take. Taking a step back and assessing what we have gone over above you can use the below framework:

1. Determine what the organization wants.
2. Identify what the need is.
3. Assess what the current approach vs. the want.
4. Construct a path with milestones to meter the change the organization will absorb.

As a starting point to chart that path. To be clear though, the approach needs to work through in concert with all stakeholders. Some may elect to move faster than seems possible. That is their prerogative, but having candid conversations helps to prepare everyone for the path ahead. Let us know what you think in the comments below. 

andrewtye

Absolutely. Often the underlying process is generally fairly "sound" it's the technology being used that isn't either it's too complex to understand the results or it's so slow and cumbersome that a result is barely achieved.

Should be take the existing process and make it more efficient, easier to maintain, faster analytics, potentially a bit more granular before adding on bells and whistles.

After all no point in wasting time and effort on something that won't add value to the end user particularly if there are other areas that can be improved.