Fundamental lessons I learned in 2023

Ethan_Rold1 · November 2023

Author: Ethan Rold is a Certified Master Anaplanner and Senior Manager at Grant Thornton LLP.

Winter in the U.S. is basketball season, and it is in full swing. When you attend a high school basketball game, more than likely you will hear the crowds of the student body chant “fun-da-men-tals” in a sing-song style to mock a competitor when they miss a shot or turn over the ball that they shouldn’t.

Fundamentals is a term or theme that has continued to arise throughout 2023 and by retrospectively looking at the year we can hopefully avoid making those mistakes for the next year. Regardless of whether a company is a multi-billion-dollar global enterprise or a startup that is aggressively pursing growth, there are similar “missed shots and turnovers” in software implementation that they all experience that can turn into lessons learned about applying fundamentals. Hopefully, this retrospective will help your turn existing and future Anaplan implementations — no matter how large — into even better successes.

Without further ado – the list of lessons learned presented as FUNDAMENTALS from FY23:

Focus on foundations.
The foundations phase, or detailed scoping, of your engagement is the most critical phase of your project — and will decide if you are successful or not. It is critical to involve all relevant stakeholders, document your alignment and decisions, focus on your MVP and scope so that you don’t let future “nice to haves” chase you off course.

Understand your requirements and have your engagement teams collaborate to align.
Too often project teams “talk across” one another, and both walk away assuming alignment only to find out that it is not, because of all the voices in the room. Assign a champion from the business to collaborate with the assigned model builder and let them decide and document the work. The solution architect and project sponsor are the other voices in the room you need for sign off.

No.
It is a wonderful word that is woefully underutilized in the conference room. Clients and development teams need to be comfortable saying no to changes, enhancements, or feedback in service of the MVP. No is the most powerful tool that your project team must use to protect your project, yes will create problems for you.

Data is one of the four cornerstones of Anaplan for a reason.
Without a complete and validated data set to build on, your project will not be successful. Take the time you need as a project team to confirm the data from the front end, the time you use to “stay on track” to the timeline by taking short cuts with the data will lead to bigger misses at more critical times.

Accept the added responsibilities for your role.
Everyone is busy with their “day jobs” and that takes precedence over participating in Anaplan development, training, and documentation of your new solution. If you do not make the investment early and accept responsibilities as project champions or model builders, the consequences come at the end of the project when the consulting team leaves. The cost of being ill prepared is high.

Model build.
Practice makes perfect. You will hear while selecting Anaplan that if you know Excel you will pick up Anaplan. This is correct, but if you were not good at Excel when you first started, you won’t be good at Anaplan when you start. Embrace the learning curve and practice during your implementation when you can get feedback and help without consequence.

Expectation management across your business.
You will be coached to evangelize the capabilities of what Anaplan you can do during implementation, and this is necessary for the future success as you want your co-workers to be excited. Remain aware of your scope, understand the capabilities that you can deliver, align with your implementation team on message, and temper your expectations. People will still be excited at the capabilities that your Anaplan solution will bring even without the results of waving the “magic wand.”

Nice.
A simple word, a simple concept, requires no effort, and is something that we were hopefully all taught. There WILL be roadblocks, challenges, let downs, disappointments, and changes needed in your implementation — beware of those that say there will not. Be nice to each other when it happens, pointing fingers and playing the blame game helps nobody.

Talent requires investment.
Populating your Center of Excellence with resources that can keep your solution after implementation handoff will mean that you need skilled resources that are familiar with Anaplan and your solution. Make the investment of individual’s time and commit to that investment, as a leader of your solution protect those resources’ time.

Authority to make decisions for the company from the project sponsor.
Don’t federate decisions in an implementation or make your project champion someone that can’t speak for the customer. If you need to have multiple champions based on your use case, that is ok, just don’t make the mistake of having decision makers in the room with different decisions. Trust your leaders to make the right move, and if you need future changes use The Anaplan Way “managing the buckets” method to adjust.

Long view on your implementation.
When you are deploying Anaplan, you will want to fit everything scoped into the first release or consider the implementation a failure. Rest assured, it won’t be, and your business users will receive vast benefits from what you can deploy successfully. Examples of the best implementations that I have seen is when the project leader shows the wisdom to stop, evaluate, and focus on what to do well. If you make the right investments into your talent organization then you will be able to manage the rest as enhancements after the implementation. You are making a long-term investment into your business, don’t risk it by going too deep or too wide unnecessarily.

Stop and simplify.
Anaplan is an immensely powerful modeling tool and can manage the most complex of business cases. However, with great power comes great responsibility and too often we make poor decisions in requirements setting or modeling. We feel the need to embrace Anaplan’s full capability as model builders or business champions and we make our lives much harder than we need. Start simple on your processes and model design; if you find yourself unable to clearly articulate the purpose or decision then stop, think if there is a simpler way, and try again. More bad models exist because people are trying to enhance their model to be “turnkey” or build too many fancy capabilities, simple is best and incrementally improve from there.

Hopefully, these lessons learned can help by your team to improve the fundamentals of your implementations, both now and into the future. Anaplan is an enormously powerful platform and, if you follow these principles, I believe you can use that to create an enormously powerful solution to drive change in your business. Good luck, and happy Anaplanning!