Author: Tiffany Rice is a Certified Master Anaplanner and Senior Supply Chain Applications Builder/Developer at Anaplan.
There are many different scenarios where leaders or project sponsors may request some “proof” before we make the “pudding”. This is common in instances where teams are exploring new functionality, transforming processes with large numbers of stakeholders or considering multiple options which may yield different outcomes. Before you begin building a prototype or proof of concept in Anaplan, let me offer you a few points to consider in your “recipe”.
Prototype recipe quick card:
- Define a clear problem statement or learning objective
- Gather inventory of resources
- Reign in the Scope
- Execute efficiently
- Document assumptions, learnings, and recommendations
- Wow stakeholders with your keen insights!
The first step should always be to clarify on objectives and align on the definition of success before investing time and effort which may be deployed more impactfully. It can be so tempting to start building with the presumption that the value will naturally reveal itself. However, without understanding what you want to learn or decisions you hope to compel, you may find yourself with a souffle that falls flat. By spending a little extra time before you start cooking, you will ensure you have a delicious dish that has been prepared to delight consumers with the least amount of chaos in the kitchen.
Now that you have a clear understanding of why we are considering firing up the kitchen, let’s consider what we may cook up. Will it be a full meal or will a single dish be enough to satisfy the appetite. Efficiency is a major part of the recipe for success, as they say time is money, so invest time with care.
You should consider if there are readily available resources to meet the needs without requiring lots of investment. These resources may be in the form of the Anaplan Modeling Showcase or models that you have built to address similar needs (close enough can sometimes be good enough), content in the Anaplan community (for example the 'How I Built It' series is tremendous to show feasibility), or webinars where other customers/partners have demonstrated a similar concepts. Don’t be afraid to reach out to your Anaplan Customer Success partner, they are exceptional at creating connections to resources that you may not have otherwise known about.
Next, let’s think about how we need to cook this. Focus on expediencies and levers that can allow you to demonstrate a minimum viable product with the least amount of technical debt. Unless integrations are a key objective, forgo automation and systematic connections in favor of manual data integrations. Data should generally be representative but not real, meaning there is some freedom to make it up but use caution not to get stuck in the data creation game. Consider how much is needed to “give a taste” so stakeholders can appropriately plan for their big meal. Narrowing the scope will allow you to deliver more quickly while ensuring the pudding does indeed provide the requisite proof. Define the testing protocol which will allow you to demonstrate the objective, this should ensure the prototype is working as designed and captures the evidence needed to formulate recommendations.
Ok, time to fire up the oven. Build out the model with the minimum functionality and then create App pages to mockup the end user process (if applicable). Highlight the functionality and use dummy or text cards fill in any gaps that may be out of scope or not fully functional. Run testing simulations and notate any observations and findings. Insights that can be impactful include elements that didn’t work and if/how you rebuilt to address, action run time or general model performance and any nuances you observed that may inform options and limitations.
As the prototype takes shape, consider if feedback is needed to ensure you are on track. An external perspective can often be helpful to validate if the concept is being effectively illustrated and provide suggestions on how you might be more successful. Friendly reminder, too many cooks in the kitchen can spoil the dish. Be selective in your feedback loop, by identifying a limited number of partners to ensure you don’t get caught in a continual refinement loop. Set a clear expectation for the number of feedback sessions that will be executed. I recommend no more than three, one to get initial reactions and recommendations, one to demonstrate how you applied the feedback, and if needed a final session to debrief on learnings. It can also be helpful to timebox the effort level for refinements, if a suggestion will require more than an hour to develop/build perhaps it should be forgone.
Finally, the cool down! Now that the oven is off, let’s clean up the kitchen and get ready to serve. Reflect on what you built, the testing process, and the feedback you received. Consider how you might best document the findings. You may use a board page in the App to provide an overview of the prototype, links to external resources, an inventory of the prototype pages, and next steps or recommendations. The key in this step is articulation, aligning users of the prototype on its purpose and what it demonstrates (or conversely what it does not demonstrate). You may have different audiences to consider; a senior executive may require a more succinct synopsis so consider if more targeted communication or supplemental materials may be needful.
Wow, that was one tasty snack! Now that the prototype has whetted the appetite of stakeholders, they will be hungry for more!
