There have been several posts recently about business cases and change within an organization1. Building off of that, I’d like to share some thoughts about best practices in change management for large technology projects such as core system replacement.
One fundamental question that an insurer must answer when beginning core system replacement is what to include in the scope of the project. Unfortunately, the answer to this seemingly simple question can become very complicated, very quickly. For example, good core software will encompass global best practices based on the vendor’s experience with its customer base around the world. These processes will inevitably vary from your own processes to some degree. Good core software will also offer the flexibility to configure your processes in an almost infinite number of ways. Do you want to stick to out-of-the-box functionality, or do you want to configure to match the way that you do things today?
The intuitive (but often forgotten) question that should guide you throughout the project is: what are you are trying to accomplish? What are the reasons that you are looking at core system replacement in the first place? More often than not, the goal is not simply to mimic the functionality of your legacy system, but rather to use the implementation as a part of a broader change initiative that introduces new capabilities to support strategic long-term goals. If this is the case, your project should take advantage of not only technology changes, but also the opportunity to re-assess your business processes. Although this might seem obvious to you, the ability to articulate your vision can be a powerful driver of change.
However, simply knowing what you’d like to accomplish is not enough. You also need to communicate and engage with all of the stakeholders who will be affected by the project, from front line workers (who will be using the software) to senior management (who will be approving the budget for the project). If everyone involved understands and feels a part of the underlying strategy, decisions that shape the scope of the implementation will become easier, as you will have clear criteria on which to base your decisions. Conversely, if stakeholders are told the “what” but not the “why,” then your project is likely to face additional challenges. People who don’t understand the reason for a change and don’t see the benefit of it are certainly more likely to fight against it than those who do.
Designing your new business processes a certain way simply because “that’s how we’ve always done it at this company” is probably not the mindset that you want on your project . . . it’s up to you to explain why not!
[1] Let's Tell a Story; The Case for Change; and Building the Business Case for Policy Transformation