Remembering to keep the F.I.T in your model retrofit
Author: Taryn Townsend is a Certified Master Anaplanner and Senior Manager at Deloitte Consulting.
As technologists and planners, our reflex is to look to the future. We strive to keep up-to-date on the newest and most optimized solutions for our clients and users. This can often lead us to opportunities to give our legacy systems a make-over! I have come across quite a few of these workstreams seeking to either add something new to a system because it was previously unavailable or giving an existing model a tune-up due to business changes (hierarchy updates, anyone? 😊 ). To help guide you along this journey, below I share a few of the simple yet un-skippable tips and lessons I have learned working on these types of implementations.
But first, I hear you asking: “Why don’t we just start over from scratch? Isn’t that easier?” As is tradition for me, I have a consulting answer for you — it depends! You should always perform a pros and cons analysis to confirm that a retrofit workstream is right for you as your step one. Look at your roadmap, review the bones of your model, layout your mockups… if you confirm that a model retrofit effort is right for you, then remember to keep F.I.T.!
F = Focus your goal
It is tempting to open up a retrofit build cycle to include all possible improvements or enhancements that you have been thinking about folding into your existing models. Resist! Crafting your user stories, sprints, and testing cycles with the same focus and rigor you would a new implementation will set you up for success.
I = Interrogate your model map
One of the key advantages of Anaplan is its connectivity. To add to or renovate existing structures, it becomes critical to make sure each intersection point is understood. This includes flows in and out of your model as well as intramodel connections. There is nothing worse than installing a fancy new entertainment system in your car and then realizing the wiring doesn’t support it! Take the time to really trace those connection points to guide your development process.
T = Testing, testing and more testing
While you are applying changes to a model that might already be live or have already gone through extensive UAT, do not underestimate the importance of going back and testing the impacts of your changes to the existing system. Bring the team of your key stakeholders, IT, and model builders back together to review the updates and perform retroactive testing together.
Lastly, enjoy the experience! A retrofit project could appear on paper to be less exciting or innovative compared to a brand new model build but these projects can lead to highly transformative and rewarding results. You are preserving the healthy foundation of your Anaplan ecosystem while setting it up for long term success through continued review and improvement. I think you will find, in the words of a “retro” classic, that is truly ‘The Best of Both Worlds’.
Comments
-
It's definitely a balance - a model we have hadn't been touched in a few years but they wanted to change some of the core calculations were managed. Could have cut out the old modules and replaced with the new module set (broadly same inputs/outputs) but instead decided to start afresh - if nothing else it gave a chance to clean out the less than best practice ways of doing things and also better enabled a transition to UX.
3 -
I think the "I" is Imperative! The decision to retrofit vs. start from scratch is never simple and it is critical that you have an understanding of the overhaul scale needed to achieve the goal. Contemplate how much of the existing modules, actions, lists, etc. are being impacted by the change - how much rewiring are you prepared to complete before you just spring for the new "model" year? hehe.
@andrewtye - I do love the feeling of a new squeaky clean model!
2 -
Nice article and well said @Tiffany.Rice Heavy emphasis on the "I" before making the decision to rewire or start new. Don't forget to understand all "hidden" implications (i.e. what filters are being used, what internal model processes may be critical to the functionality, how much new testing will the team need to take on in either scenario).
2
