Model building checklist
Author: Nicole Johnson, Senior Anaplan Model Builder at Autodesk.
I love a good checklist. Naturally, that passion comes through when I plan and build enhancements for an Anaplan model. I've created a model building checklist that I use to think through and document changes I need to make to a model, and I'm sharing my checklist with the Community today. I am able to minimize context switching while planning changes because I have space to note questions, ideas, and to-dos in one place so I can get the information out of my head and continue with planning. Another big win is that it helps me remember details like adding end user permissions to new artifacts (modules, actions, etc).
When I initially created the template, I was less experienced with model building but found that if I could get my hands on a good mockup from stakeholders, I could use the checklist to guide me through what the development process would need to be.
My initial inspiration for the checklist was a project template I found in a model available to all of us: "Agile Implementation - The Anaplan Way 2020." The sections of the checklist are listed below with a short description. Not all sections are applicable to all model enhancements, so I disregard them when necessary.
Research/Questions for Stakeholders
I use this area for two purposes:
- Questions I want to answer at the onset of my development planning, which require me to do some digging in the model.
- Questions that come up for stakeholders that aren't blockers for all of the development tasks. I note them in this section of the checklist so I can come back to them later and get back to planning or building.
Note new lists or changes to lists.
Modules, Logic, Saved Views
Note new modules or changes to modules. Include details such as dimensions, formulas, or any other information relevant to the build.
Snapshots (if applicable to model)
If making changes to an existing module, consider if they will have an impact on snapshots.
If creating a new module, consider if it needs to be added to a snapshot module (and the corresponding snapshot action/process).
Actions & Processes
Note new actions/processes or changes to existing ones.
Note new dashboards/pages or changes to existing ones.
This is something that is so easy to overlook as you wrap up a model fix or enhancement. With all the excitement to get completed changes to end users, it is easy to forget to grant them permissions to do what you created for them.
To make role access easier to maintain, I like to make a note next to each new artifact (List, module, action, etc). That way, when I get to this part of the checklist, I can refer to the items marked "*NEW*" in the list.
Does the fix/enhancement work? For ALM models, perform internal UAT in a deployed test model to ensure everything is working as expected. Even better, if possible create a non-WSA test account so you can review changes in the exact way end users will see them.
- Make note of key items to test internally before handing over to end users for review.
- Review changes.
- Run critical processes (ex: does your Snapshot process still work?). Sometimes it is easy to overlook a development change that might impact processes with numerous actions. Running big processes (even if you think they aren't impacted) to confirm they still perform as expected can mitigate end users finding errors.
- Review output reporting before & after the changes are made. Do the changes make sense based on the fix/enhancements made?
Production Data Reminders
For ALM models, if a fix/enhancement requires a new end user selection or input, note it in this section so that when you push changes you can remember to populate necessary production data.
Model Documentation Updates
As you build, you might think of updates you want to make to model documentation. Note them here, so then at the end of development you'll have a nice checklist of items to add.
If you identify issues or improvements out of the scope of the current fix/enhancement, note them here so you can come back to them at a later time and get them logged in the appropriate ticket or separate to-do list.
Not much of list maker? If writing out your planned development steps isn't aligned with your workstyle, you can modify the template to use as a short list of items you want to make sure are covered whenever enhancements are made to a model.
What does your process look like? Would you add anything to this list? Leave a comment!