• Cathal Doyle

The Anaplan Way

This is a philosophy and methodology that we at Bedford were captured by back in 2011 and have been adopting with our clients ever since. Undoubtedly aided by an agile and flexible platform, the Anaplan Way is a measured and definable approach to optimizing customer success which has now been embraced across 600+ customers worldwide.

The Anaplan Way is a juxtaposed style to that of the Waterfall methodology. We think in short, focused releases, each release building on the others rather than trying to pack as much content into a single release and without that final ta-da moment which inevitably disappoints. People tend to get bored and unfocused with long drawn-out implementations, and by the time the release comes, the business requirements have already moved on. Anaplan is as much about the journey as it is the destination. Keep your first release focused and short, know what you want to achieve and when you want to achieve it, ensure buy in from the executives, keep it simple, focus on immediate pain and that quick win, solve the problems you know you can now rather than attempting to right every wrong in one fell swoop.

One of the first and often forgotten steps on the Anaplan journey before project planning, is the Application Manifesto. This is a short paragraph derived by the key stakeholders outlining in a very focused and concise manner the overall goal of the project. Upon Go-Live you should be able to read your manifesto and say yes, the model we built aligns completely with the manifesto, but it is also serves as a constant reminder during the project to stay on course.

Remember that Anaplan supports very rapid build times. It is not the model build that becomes labor intensive but rather the processes supporting the platform, and hence the implementation and deployment needs to be planned carefully in order to be executed well. During the pre-planning process we focus on the Four Cornerstones which form the foundation for the implementation of the platform: 1. Model - The design, build and testing of the Anaplan model; 2. Data & Metadata - All the data components needed for the model: master, meta and transactional data; 3. Process - The wider business process that the Anaplan model supports; Deployment - Ensuring that the Anaplan model and the new business process is adapted in the organization.

The Anaplan Way process is based upon the Agile methodology called Scrum. Prior to project kick-off we will be gathering requirements, outlining the model design, defining the user stories and planning the sprint schedule. The User Story definitions (requirements gathering) is typically seen as the most critical part of the entire project. This is where the business subject matter experts (SME) sit down with the entire Scrum team to layout the business requirements. Next, you’ll plan the number of sprints and user stories that fit into each sprint. The number of user stories per sprint and timings of sprints will vary by customer, and each will be given priority weighting.

The Scrum Team on the client side will typically be made up of an Anaplanner, a scrum master (project manager), subject matter experts (SMEs) and an executive sponsor. This team should be assembled for the pre-planning phase and then for Sprint Reviews which are typically only held at the end of each sprint where the team demonstrates a working product increment to the Project or Business Sponsor. Daily stand-ups will take place at the start of each day outlining what was done yesterday, what will be done today and any risks or blocking actions stopping that days tasks. In keeping with the four cornerstones, one of the important deliverables is to ensure customer training on the Platform. This is the very first focus of an implementation and getting a customer ready for Anaplan is key to a collaborative and successful project. We normally enforce completion of the training by at least the proposed Anaplanner (model builder) prior to commencement of the project.

A Sprint should almost be a self-contained project in itself, covering design, build, integrate, test and demo phases. Although the user stories will have been clearly defined in the pre-planning phase this approach allows itself to be iterative and flexible to changing landscapes. If it is possible to consume a change or requirement not previously included we will normally do so, this may or may not lead to re-balancing of the buckets within that sprint or a subsequent sprint based on associated effort, something which the scrum master will generally make a call on. At the end of each Sprint we hold a Sprint Retrospective the purpose of which to reflect on the process and adapt the process for future sprints if necessary. It may also be necessary to re-balance the buckets of subsequent sprints based on additions to the previous sprints, or even estimation errors in sprint planning. In all honesty, it can happen, but again is not something to be overly worried about given the iterative nature of this methodology.

The goal of UAT is to make sure that system supports the day-to-day business scenarios and we normally rely closely on the client to draft UAT scripts depending on requirements, and support with tracking of the feedback into a triage: Must fix and include in release, Must have by end of UAT, Desirable to have. Depending on the size and complexity of a model, load & performance testing can also be facilitated by Anaplan where necessary. The Go/No Go decision is always a nervous time for all concerned but by following the Anaplan Way you should have mitigated any risks well in advance of this date.

The key objectives of the Deployment phase are to get buy in from the end users, ensure the new Anaplan process lands successfully into the organization, and secure a return on investment for the customer. As a natural by-product of the project approach you should be well on your way to delivering on these goals however there are still some remaining tasks to aid in the deployment phase: develop a communication plan for the end-users, develop a training plan for end users and subsequent model builders, model maintenance and process documentation is key and gathering user feedback during the initial Go-Live for subsequent releases. The eventual goal of the project is to ensure the customer is fully self-sufficient so that they can truly champion and expand the platform largely by themselves or with minimal aid. We will normally work with the client to form a Center of Excellence which depending on the size of the customer and implementation may range from a single person to a handful of people as the use cases increase. The Anaplan community (Anapedia) is also a hot-bed of advice, training material, peer-to-peer consultation and user groups which are invaluable in the evolution of customer ownership.

As part of our continued blog series, we will be drilling into some of the key concepts of The Anaplan Way covered above so stay tuned.