If your Anaplan implementation is taking months you either need to change your implementation partner or you are using the wrong tool.
Many prospective clients ask, ‘can Anaplan be implemented quickly’ and my answer is always;
“you can implement 90% of the possible Use Cases within 10 weeks if an Agile Implementation Methodology is followed”
First, and with emphasis; implementing Anaplan should be approached no different than implementing any other software application; understand, anticipate and plan for the 6 Phases of any implementation;
- User Stories (Requirements)
- Build (and Unit Test)
- User Testing and Defect Resolution
Second; the only phase of the implementation that is ‘compressed’ is the build, Anaplan development is rapid; lists and modules can be constructed in days with the model developed in weeks. The remaining phases are not compressed, and need to be planned for accordingly. (see more below)
Third; it is not the Anaplan build that delays implementations, it is the failure to enforce effective project management, anticipate inherent delays and take the necessary steps to keep the project on track.
The most common reason for Anaplan Project Delays is failure to fully capture, document and validate User Stories (requirements) followed by devising an efficient and effective model design that considers Anaplan’s strengths and weaknesses. Prototyping is mandatory, and is the only effective approach to confirm requirements are fully captured and understood by the implementation team.
The second most common reason for Anaplan Project Delays is source system data, either the source system data is not available timely or the source system data does not include all required fields including those needed to support end to end automation eliminating all manual processes. All Source Systems should be identified during project scoping, at which time source system sample data and full data sets should be requested. Implementation partners should be willing to review and provide feedback on sample data files prior to the start of the implementation. Most organizations have policies and processes for obtaining source system data which impacts timing that can range from days to weeks. If you are not requesting source system sample files until the first day of the implementation, you are already behind schedule.
The Anaplan Trap; Anaplan is the easiest modeling tool currently available in the marketplace which presents inherent risks and challenges. Scope creep, stick to the deliverables agreed to during User Stories and Design. Though most of the requests for modifications during development will provide value, assess each request on how the specific modification will or will not materially affect the ability to complete the forecast in Anaplan. If it will not, add the request to a future enhancements list.
“The risk is users will continually request enhancements, and though many will probably be quick to develop you should balance these against ‘going live in full production and declaring success”
As noted earlier, implementing Anaplan should be approached no different than implementing any other software application, Project Management processes and artifacts are mandatory and should include;
- User stories; for both current and future associated use cases
- Open items list
- Model design
- Build schedule (detailed)
Below is an example of a typical plan:
Pre – Project Kick Off:
- Project scope
- Identify source systems
- Request source system sample and full data extracts
Project Kick Off:
- User stories, design, prototyping and project planning – 2 weeks
- Iterative model build, source system integration, including unit testing – 6 weeks
- User acceptance testing and defect resolution – 1 week
- User training, deployment, documentation and administrator training – 1 week
Keep use cases focused and simple, Anaplan is designed and intended to be Connected;
“The power to connect models and collaborate seamlessly across the entire business….”