Agile Implementation for Anaplan – a Smart Approach

Anaplan implementation for EPM Use Cases offers a unique scenario. An accelerated implementation that allows the flexibility of Agile mirroring a waterfall implementation of ERPs or a standalone implementation with integrations. How does one marry parallel implementations? How does one take advantage of Agile implementation for early releases for business planning?

There is no one-size-fits-all approach for Anaplan implementations. The Anaplan Way (TAW) provides a framework, while often customers have mature customized in-house hybrid Agile models and SI Partners themselves model an approach that is best suited to a customer business situation. Which one to go with?

Anaplan, a Cloud based SaaS product allows ease of configuration, customizations, integration with external systems, interactive Dashboards and Reporting.  There is no rigidity of tightly coupled out-of-the box functionalities that makes slicing of business processes and Sprint releases thereof difficult on account of a product workflow that cannot be broken. On the contrary there is the flexibility of build “as-you-want-to” approach allowing Sprint releases over the project lifecycle.

A diagrammatic representation of a recommended approach is given below. For this document we have assumed a Financial Planning & Analysis (FP&A) Use Case where the monthly actuals are integrated into Anaplan from multiple source systems and together with historical data, simulations are carried out for budgets, forecast and scenario planning.  For illustrative purposes the planning details are required to be provided monthly and quarterly for

1.       Sales Volume by Segment

2.       Sales Revenues

3.       Income Statement

4.       Cost of Goods Sold

5.       SG&A

6.       EBITDA

7.       Capital Expenditure Plans

1.       Requirements Gathering: While a departure from the truest form of Agile, in this approach a Requirements Phase is in the beginning. This allows a holistic understanding of the business process.  A traditional approach is to document AS IS and TO BE processes, but an accelerated approach would be to document a concise future state Requirements Register. A signed off document would form basis for User Stories & Sprint Planning

2.       Design:

a.       User Stories: User Stories flow from the Requirements Register

b.       Sprint Planning: At this stage replan the Sprints. Replan? Yes, as the customer SoW would have a certain Sprint detail laid out, but with the level of detail now available, replan the Sprints

c.       Technical Architecture & Application Design

3.       Build & Deploy:

Execute build, complete Unit Test and have the UAT & Deployment executed by each Sprint. This way each set of functionalities that is grouped by a Sprint is available for use in production environment.

In our example

Once Sprint 1 & 2 are built out, Data Hub with Integrations & Planning on Sales Volumes and Revenue can be carried out in production without waiting for the Build of all Sprints

After Sprint 3 Income Statement, COGS & SG&A and EBITDA are available

Sprint 4 would provide CapEx planning and the complete application available

Each Sprint would follow complete Agile process of daily Scrum meetings reviewing Backlogs, and a recommended Sprint Development Review where the development completed can be reviewed by the core customer team. Tweaks are incorporated immediately thereby mitigating risk of any spillover/delay due to changes coming up during Sprint UAT.

Sprint Retrospective Meetings at the end of each Sprint and All Sprint Retrospectives become a part of the process.

4.       Testing: At the end of all Sprints Load, Concurrency & Usability as appropriate need to be taken up

Another scenario that classically emerges is when the implementation runs in parallel with an ERP/another system implementation and timelines must be married to that.  This needs an innovative approach as the methodology will remain the same, but the timelines for phases will need to be broken and not consecutive.

Requirements may need to be completed alongside ERP requirements, but there would be a lag before design and build starts off once ERP system is stood up for data to be ready for data to flow into Anaplan.  Concurrent requirements phases are run for ERP and Anaplan on account of a comprehensive user participation for both ERP and planning requirements to be gathered.

The methodology for implementation would remain the same, it is just that project planning would be broken out.

Progress Tracking

Sprint Burndown Charts and effort remaining, are used as Agile tools to track. Additional tools like MS Project can help track impact of delays to overall project and cascading impact on following Sprints.

Conclusion/Measures for Success:

1.       Tailor the Methodology for Customer Environment – goes back to what is said earlier…there is no “one-size-fits-all”

2.       Engage the Customer IT from the beginning and have them own the methodology – lack of understanding causes its own issues

3.       Sprint Planning and User Story grouping need to be co-owned by the customer, not just given to them…Sprint Planning, User Story grouping, Go Live Planning, Mirroring with ERP Plans

4.       Enforce Scrum Meetings and Sprint Development Meetings with Customer Reps

Anaplan as a product lends itself with ease to an Agile implementation.  Let users see that advantage in the implementation cycle!