The Foundation Phase is without doubt one of the most critical steps in The Anaplan Way and sets the benchmark for the success of the overall delivery. During this phase we drill into both Project Planning & Sprint Planning where we define project pre-requisites like training, project kick off, existing solution reviews, initial requirement workshops, writing user stories and plotting our sprints. In the previous Pre-Release Phase blog, we focused on the scope of work, project deliverables, size of application, user concurrency, resourcing, timelines & project pricing in order to draft a Statement of Work [SoW] for the customer. We have also defined our Application Manifesto, a short paragraph derived by the key stakeholders outlining in a very focused and concise manner the overall goal of the project. But remember, neither is an exhaustive list of every minute task or activity, rather a statement of intent. The Foundation Phase should be used to explore those areas in greater detail and plot them against our sprints. Remember this is not a 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 which invariably disappoints.
Aligning with the four cornerstones, one of the first deliverables is to ensure customer training on the Anaplan Platform. This is the very first focus of an implementation project. Getting a customer ready for Anaplan is key to a collaborative and successful project and we will widely enforce that the training is completed by the key modellers prior to project kick off. Customers will be empowered with the key concepts of the Platform (Lists, Modules, Line Items, Dashboards) which in turn will aid in drafting the User Stories. The next step is to plan a Project Kick-Off Meeting, the purpose of which is to introduce The Anaplan Way methodology to the customer and review the objectives of the project together. The Executive Sponsor typically presents an overview of the company and the business objectives that the project addresses. This provides the entire team with a high-level overview of the business and the use case before we start drilling into specific User Stories. Naturally, this meeting should echo the Application Manifesto drafted in the Pre-Release Phase.
No matter how well your project requirements are defined or how many times you’ve completed a similar project, every project is going to have its fair share of surprises, so it is important to document any 'known unknowns'. An example of which might be; we know that we will need to import a data set from an upstream source but have not yet been given sight of the data formats. This is a known unknown, and everyone needs to acknowledge and potentially build in some contingency to deal with such occurrences. At this stage it’s about getting everything on the table, warts and all so that we can plan for it.
The client must also now start to consider how they will resource the project and naturally, their resource needs will typically extend beyond the life of the project itself. They will need to ask questions like; who will act as Product Owner (overall process and the system landscape), are the skill sets of those involved on the project the right skill sets, will they be on the project full-time or part-time, what are the hours required for each sprint, what is the client’s resource commitment. In asking these questions the client will be defining their Scrum team roles including Business Sponsor, Scrum Master, Model Builders, Data Subject Matter Experts (SME) and key business users for UAT & Training. Depending on the size of the project some of these roles may be covered by the same person but nonetheless the role itself must be allocated accordingly.
During the Sprint Planning process, we will be laying the foundation for managing the project using the Agile Scrum Methodology. We will be gathering requirements, completing the model design and plotting 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. A Sprint should almost be a self-contained project in itself, covering design, build, integrate, test and demo. Although the user stories will have been clearly defined at this stage, the Agile 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 that 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 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.
As part of our continued blog series, we will be drilling further into The Anaplan Way with Sprint Planning - Writing User Stories & Managing the Buckets, so stay tuned.