From clutter to clarity: Mastering documentation in Anaplan
Author: Madison Matous is a Certified Master Anaplanner and Solution Architect at Akili Inc.
Though not always the most glamorous task, documentation is critical to overall project success. It serves as a standardized reference for both the development team and end users. Successful adoption of a new Anaplan model is greatly impacted by the level and detail of documentation. I’ve used the following approaches and details in several implementations and tailored it to fit each client’s needs and hope it can do the same for you!
I prefer to first ground myself in the details: who, what, where, why and how. Understanding who the audience is for the documentation, what are we documenting, where should the documentation live, why are we documenting, and how will it be documented helps us lay the proper foundation for the task.
- Who is the documentation for?
Details on how to use a model for an end user compared to a model administrator would and should be different. The audience is an important consideration when creating model documentation. - What is to be documented?
Are we documenting the modeling layer (overall solution design) or the application layer (user guides)? Alignment on the content to be included helps define the task at hand and make the overall process smoother. - Where should the documentation reside?
Typically, model documentation resides either internally as pages with the App or externally as document or hosted on a site. Factors to consider when making this decision are team size, is a Center of Excellence present, and product ownership. - Why is the documentation necessary?
It is helpful to have a standard level of documentation so the model can continue to function year after year. Everyone’s why can be different though — maybe there is a planned transition within the team upcoming and more detailed user guides are necessary or documentation is needed for tracking planned releases. - How will it be documented?
For me, the how is very much related to the where question posed above. How I approach documentation is dependent on where and who.
Model documentation ideally is completed as the implementation phase is occurring. Completing it in parallel helps to ensure that the material is recent in our minds. Though modeling layer documentation will be used by a model admin or model builder, it helps to have a clear approach if others join the team or transition to the role. It is much easier to acclimate to a new model if it is well documented and organized.
- Clean up your clutter! The model is not the junk drawer we all have at home that you hope no guest unknowingly opens looking for the silverware drawer. Delete unused lists, module and actions so there is never a doubt of what is being used by other model components or within the app layer.
- Naming conventions. There are naming convention standards outlined with the Planual which is a great resource if you are not familiar with the idea (see 2.01-01). There is a method to the madness, and it makes it much easier to use when consistent conventions are utilized.
- Notes, notes and more notes. Note fields are available throughout the model from lists, action to modules and line items. I like to take the approach that less is more and quality over quantity. Less notes with a higher quality of detail will serve the model builders and administrators much better for the life of the model.
With the introduction of the user experience layer comes more documentation we need to consider in our implementations. Organization with the app serves the end users more and leads to an overall better experience. I often find myself using the following tools to help document within the application layer.
- Categories: A helpful tool to group or categorize various pages. I’ve used them to help streamline the user’s workflow within the tool or to group similar pages of functionality together. Example categories within FP&A use cases are Revenue, COGS, OpEx or CapEx.
- Numbering: A numbering prefix on pages is key to ordering pages within the Contents or Categories in the intended flow. (See 4.01-01 within the Planual for more details.)
- Administrative pages: I’ve found success by including model administrative pages within the app layer. This type of living documentation helps to keep the user within the tool instead of navigating away to recall details that they will ultimately return to Anaplan to complete. These pages are typically model specific and detail items such as, updating switchover or current period, annual model timescale updates, list maintenance and more.
Documentation is not a one size fits all solution. The first approach you take may not be the final solution and that is normal! It should evolve and change as the business needs do as well. The most important part is not that it’s perfect, but that it exists and you and the organization continue to spend the time to make it useful and effective.
Questions or anything you would add? Leave a comment!