Change is hard. At least, that’s what we’ve been told. But sometimes change is easy; Way too easy!
This is part 2 of our discussion on Model Governance. If you missed the first one, check it out here.
Model Change Management can be a tough topic for many people. Model change management programs exist across a varying spectrum between flexibility and control. At one end, you have change control that is so rigid, that making changes is onerous and slow. In this kind of environment, the model users will often develop side processes or ‘hacks’ that let them achieve their desired goals.
At the other end is a little like the wild west; changes occur every time you turn around and no one is really sure what has happened. This kind of environment can be really nice for testing a lot of different types of business processes, assumptions, and other modifications, as long as everything is working well. But as soon as something goes wrong, it can be extraordinarily difficult to track down the cause. It is also hard to tell when there might be errors occurring that you don’t even know about.
A properly implemented change management program will find the right balance of these. It should provide an efficient avenue for changes to be made in a timely manner, but ensure that those changes are understood in the greater context of the model and properly tested to ensure there are no unintended consequences. The process should be straightforward and easy to execute so there is no fumbling through it.
There are many good resources available on change management processes, particularly for software development, that can be easily adapted for modeling applications.
Migration Management & Deployment
Migration Management refers to the process through which a new model becomes “official” and is ready for use by the modelers. This can take on varying levels of difficulty depending on the modeling system and how company systems and resources are distributed. Ideally, there should be a centralized, controlled location where the “official” version of models reside. And all model users should know to always use it.
It is important to have a system in place for how you track different versions of the models so you don’t end up with names such as “Production_Model-Final-Final_v7”. That does not count as version control.
Documentation? You mean that stuff you write down a few weeks after you finish doing the real work of building a model that no one ever reads…?
Unfortunately, documentation often becomes an after-thought in the development process. When deadlines are looming and bugs are being reported, model developers will get into crunch mode. They are focused so heavily on rolling out new features, improvements to the models, and fixes for errors that are occurring that little time is left to properly document the model and any changes that are occurring.
Proper resource and development planning can help to alleviate this. A certain amount time must be allotted to allow for proper documentation of changes as they are occurring. Documentation is better when it is written in a timely manner because everything is still fresh in the mind of the person writing it. As time passes, people will inevitably forget details that they knew only a short time before when they were heads down on a particular element. And when the inevitable memory drain does occur, you have documentation to refer to that will help you remember.
Bugs? I thought model change management was supposed to prevent all bugs?! Well, no. The reality is that bugs will happen. No matter how good your development team is and how careful they are, it is not realistic that they can prevent a bug from ever happening. Development and testing teams are a limited resource. And once your model is released and available for others to use, someone, somewhere will do something with the model that you never imagined; and it will break. But that’s OK. Part of model change management is recognizing that this will occur and putting in place the right processes for handling and resolving them when they do.
Leave a comment below with your thoughts on this subject. If you’re liking the series, sign up for email updates. And stay tuned for our next post where we’ll discuss input data management for models.