There are two major areas of planning that are completed during this phase:
Project planning includes all the tasks which get the project underway, for example; training and holding the kick-off meeting.
Sprint planning includes requirements gathering and scheduling project work into sprints.
Sales to delivery hand-off meeting
Create Scrum team
Scrum team identified and training scheduled
Trained model builders
Verify high level schema of customer ecosystem
Initial Requirements Workshop
- Write user stories
- Size user stories
- Sign-off on user stories
User stories completed
User stories estimated
Agile Implementation - The Anaplan Way app
Plan for how to handle the cornerstones
Agile Implementation - The Anaplan Way app
User stories allocated to sprints
Agile Implementation - The Anaplan Way app
Wireframes or prototypes of dashboards
Balsamiq or other tool
Model Design schema
Dashboard/end user experience design/prototype
Lucid Charts or other tool
Data flow diagram
Lucid Charts or other tool
Change management plan - work with the customer to develop
Set mutually agreed upon expectations for everyone involved in the project during the Foundation phase. Document feedback and state ambiguous areas in the SOW. Clarify outstanding issues, project risks, or contingencies in the SOW prior to sign off.
With a strong SOW in place, aligned expectations begin with understanding what the customer has been promised. When Anaplan makes a commitment to a customer, we have an opportunity to meet customer expectations. As the Business Partner responsible for the implementation of Anaplan, understand the power of commitments to a customer. Clarify Anaplan’s commitments; be careful not to promise something Anaplan cannot deliver.
The next sections include expectations for each phase of the implementation.
Measure twice and cut once: memorize this phrase as you set a project’s foundation. Project planning and sprint planning take place in the Foundation phase. A strong foundation contributes to overall release success. Help the customer understand that the information provided during this phase must be as accurate as possible to avoid issues later. For example, if the customer commits to having two model builders that can work 20 hours per week on the project and in actuality, they only work ten hours, the project timeline will slip.
Don’t forget the cornerstones when building the project plan in the Agile Implementation – The Anaplan Way app. Build activities around model, data, process, and deployment to address each cornerstone and ensure that you meet customer expectations.
Use Planning Poker as your sprint planning exercise. Customers may or may not have experienced this type of planning. Manage expectations by explaining the process in advance and highlighting the benefits:
Build consensus on time it will take to build a user story
Build consensus on the priority of the user story
Determine the necessary resources to build those user stories with highest priority
Manage expectations by agreeing with the customer on how to manage the buckets. Managing the Buckets provides a process for ensuring that when new user stories are added during sprints, other user stories are shifted to different sprints or removed in order to keep sprints balanced. See Managing the Buckets later in this chapter.
This phase includes building the model in sprint cycles. During the first sprint, customers can feel a bit nervous, especially if the customer has not used an Agile methodology. Reassure the customer that nervousness is normal and to trust the system. Agile differs from most other approaches because at the end of sprint one, there will be some pieces in the model that show the structure and how things will work. It will not be perfect, but the end result can be imagined. The first sprint gets end users involved in order to achieve buy-in needed for a successful release.
At the end of sprint two, the customer will imagine the possibilities with Anaplan, and may want to include additional requirements. Hold firm. You cannot allow the customer to add requirements willy-nilly without running the risk of over-promising and under-delivering.
During sprints three and four, data and data integration become the focus. You have completed pre-work and discussed the importance of the data earlier in the project, and the customer begins to see how important the cornerstones are.
User testing is usually a time when bugs and enhancements come to light. The customer may call things defects that are actually enhancements. Carefully consider these requests; capture the enhancement ideas for another release. Create a triage committee to sort through UAT feedback. Be careful about over-promising. Do not add to the model during UAT; instead, ensure the model is robust and stable.
The model must meet the customer’s usability expectations. Usability includes performance: wait times must be kept to the minimum described that you and the customer have agreed to. (See the Service Levels section in Chapter 5 Implementation Phase.) If human testing shows that a certain task or item is misunderstood, work with users to adapt the dashboard so it works smoothly for them. The adoption of Anaplan is at stake: happy users make a satisfied project team.
The deployment phase includes end user training, communication planning, and change management. Since deployment is one of the cornerstones, address deployment plans well in advance.
Consider one final expectation. As your customer deploys the Anaplan model, they will collect user feedback for use in the next release. Sometimes customers may have experienced a challenging rollout and may sense risk in gathering feedback: What if it comes back negative? Remind the customer of the process: from the beginning, you have not set out to create something perfect. Continue to improve upon what has been built; the best way to improve is to collect user feedback.
The project planning activities included here ensure the project starts in the right direction. Remember the saying: measure twice, cut once. During project planning, measure twice.
Project planning includes these activities:
Sales to delivery handoff meeting
Facilitating the Project Kick-off Meeting
Working with the customer to create a Manifesto or goal statement
Working with the customer to select the Scrum team
Working with the Scrum team to establish team ground rules
Planning for a Center of Excellence or Competency Center
The Sales to Delivery Handoff meeting occurs once the customer has signed a contract. In this meeting, the sales team provides the customer success team with details regarding the customer’s requirements. The sales team provides sample data files or demo builds created during the sales cycle.
First focus on customer training. Getting contributors ready for Anaplan helps create a collaborative and successful project. As part of the deployment cornerstone, ensure that at least two people at the customer achieve Official Anaplanner accreditation.
Why does training come first?
Customers must understand key Anaplan platform concepts before working on requirements gathering. Customers who complete the training understand how to define and use dimensions, lists, modules and dashboards.
Introduce the customer to The Anaplan Way methodology and review project objectives during project kick off. The executive sponsor typically presents an overview of the company, and the business objectives the project addresses. In addition to the executive sponsor, include an influential IT leader in this meeting.
Objectives of this meeting include:
Review the executive sponsor’s overview of organization and business objectives
Agree on project schedule and responsibilities – focused on planning
Introduce team members
Discuss and align on customer resources needed
Review the timeline that was included in the SOW
Check in to ensure training has been completed
Revisit data preparation activities
Orient the customer to The Anaplan Way Methodology
Introduce user stories and sprint planning
After this meeting, work to keep the momentum going. Consider regularly scheduled steering committee meetings to keep executives involved and informed. Executive involvement elicits buy-in and raises project visibility.
Think about how you involve IT. Can they be used as the first line of user support? If so, IT will need to learn the Anaplan platform and dedicate time and resources to support it. In some cases, IT would be the best group to support a data hub, and may be eager to move other lines of business to Anaplan. IT could become the driving force for expands, as using Anaplan could significantly reduce the number of software applications supported.
Manifestos state what the customer intends to build.
Creating a Manifesto:
Gather key stakeholders in a room
Key stakeholders craft a paragraph or two that describes exactly what the team will build.
When the project is at the go live date, you should be able to read your manifesto and say yes, the model we built aligns completely with the manifesto.
The manifesto should be clear, concise, and focused on the overall project goal. Creating a manifesto early in the project ensures that you have agreement and buy in among stakeholders.
The manifesto acts not only as a checkpoint at the end, but also as document referred to regularly during the release. Use the manifesto as a checkpoint to ensure the project is going in the right direction. Return to the manifesto and determine if current work achieves the manifesto. If not, determine what needs to be done to get the project back on track.
Every manifesto is different, but should be:
Focused on a single goal
This image represents a simple sales forecasting manifesto.
Tips/Hints for Getting the Customer to Write a Manifesto
Most customers like the idea of a manifesto, but may object to writing one. Help customers understand that a manifesto acts as a tool which ensures the project remains on track.
To get people thinking about the manifesto, ask: What are we trying to accomplish? and/or How do we achieve success for this project?
Ask the customer how he or she will know the project has been a success. Write down his or her thoughts and then turn it over to for polishing.
Refer back to notes taken during the sales cycle and shared during the sales to delivery hand-off. Often the customer has shared his/her vision with the sales team; this can be a good start to a manifesto.
While thinking about who is going to help with the model build and determining which resources will be assigned to the project, keep in mind the customer also must consider resource needs. The customer’s resource needs will typically extend beyond the life of the project and it is important that the customer has thought about and made decisions around the following questions:
Are the people on the team expected to be on the project full-time or just part-time?
Select the correct key role of project sponsor.
The project sponsor understands the overall process and the system landscape, knows the different types of users, and understands their roles in the process.
The project sponsor has a vision for what needs to be built and will support the business in defining the requirements (user stories).
The project sponsor is ultimately responsible for the prioritization of the user stories and the successful delivery of the model.
This role requires an average of two to three hours per day for the duration of the project.
Who will take on this role and will this person be able to dedicate this amount of time?
Determine the hours needed each week to:
Get the project up, running, and ready to go live
Manage the platform post go live
Extend the platform to connected up-stream and down-stream processes
Run through another life cycle (processes may require design tweaks and changes as the business changes)
Determine required effort on the four cornerstones:
Build time on the Anaplan model is usually small compared with data and metadata work, process changes, and the deployment.
Should I be looking to involve a partner to supplement my efforts, especially around process change and deployment?
Are the skill sets of those involved on the project the right skill sets?
Are the resources actually available for the proposed time line?
What is the customer’s resource commitment? Are they able to provide dedicated resources to the project to assist in the build? Note: Care should be taken not to put too much dependence on customer resources as this often changes.
Have all the resources involved bought in to the process and the decision to choose Anaplan?
While the customer is ultimately responsible for selecting the resources to assign to the project, be involved in that process. These roles will not only have project responsibilities, but may smooth or hinder the organization’s Anaplan deployment.
Ideally, people selected to fill these roles should have most or all of these characteristics:
Clear vision. This person should have a clear vision of what project success means for the organization, and the ability to clearly communicate that vision. This needs to be consistent, as someone who changes his or her mind frequently or seems to be all over the place can scare people off and make them unsure.
Patient, yet persistent. Every project can be frustrating and seems as though no progress is being made. Someone who understands that good things take time and the importance of following a process will probably not share their frustrations or “the sky is falling’-type concerns with co-workers. They may feel that way, but understand that sharing their frustration will not help and may hinder the project’s progress.
Asks tough questions. The person who asks tough questions has some skin in the game – he or she has bought in to the solution and asks good questions to ensure that the solution is really the best for the organization.
Knowledgeable. This person understands the business and the process and is sought out by coworkers who need help. He or she is able to provide an explanation at the correct level of detail.
Strong relationships. This person is approachable and reliable. People in the organization trust this person.
Positive, but realistic perspective. This person is good at seeing the big picture and what the new process can mean to the organization, but is not simply a yes-person. He or she can spot issues or problems and makes suggestions for how to get around them. A person with a negative perspective tends to focus on the problems and doesn’t offer any ideas for how to correct them.
This chart shows the Scrum team roles, approximate number of hours per week the project work requires from the role, and the role’s responsibilities. Note in the chart that the roles identified in the Other Team Member section usually are not putting hours in for the entire project. Instead, their hours are for certain phases: for example, the Data SME is involved during requirements gathering (Foundation phase) and UAT (Testing phase).
Hours Per Week
With primary responsibility for maximizing return on investment (ROI), the customer-provided project sponsor focuses on leadership needs and is an expert on current processes and upcoming changes in any process. This person is engaged in all phases of requirements and sprint reviews and these key areas:
Guiding the vision and re-prioritizing long-term expectations such as release date, content, and backlog.
Final arbiter of user stories (requirements); accepts or rejects each sprint.
Considers stakeholder interests at all times and may contribute as a Scrum team member when practical.
Like the project sponsor, the Scrum master will come from the customer side and have a leadership role. Unlike that role, this role does not have management authority over the team. This person runs Agile, leads daily meetings, tracks user stories, and updates the backlog. Primary responsibilities are:
Facilitating the Scrum process and resolving any impediments along the way.
Making the Scrum process effective by creating an environment conducive to team self-organization.
Capturing empirical data to adjust forecasts and shielding the team from any external interference and distractions.
Once the model design has been reviewed, model builders execute on the model architecture, model management and maintenance. They can be an Anaplan employee, partner, or a customer.
Other Team Members
Data Subject Matter Expert (SME)
Owns data sources and arranges for edits and data scrubbing. Involved in requirements, testing and validation phases.
UAT & Training
Develops engagement plan, writes UAT test scripts, develops communications, and trains users. Involved in UAT and deployment.
Take a realistic view when planning resources and sprints. Many times, people must perform their regular job responsibilities; the team must be realistic as to how many hours per day can be dedicated to Scrum activities. When the number of hours is not accurate, sprint planning will not be accurate.
You’ve probably worked with many teams. Some of them have quickly gelled and worked together efficiently without a lot of drama, while others have struggled. Establish a set of ground rules to help teams make better decisions, improve working relationships, and increase team satisfaction.
Devote some time as a team to establishing ground rules. The team creates, documents, and agrees to the rules. The rules should include what is important to each team member in terms of acceptable behaviors and norms:
Pick a common medium for collaboration (Slack, IM, etc.)
Set a daily time place for the Scrum meeting
Require concise and to the point communication
When a critical issues come up, discuss them in person, rather than using email.
Never use email when angry
Don’t CC the world when emailing
Feedback should focus on behavior
See things from both sides
Be calm and professional at all times
Be transparent – share all relevant information, including your thoughts, feelings, intentions
Some teams may only need a few ground rules; others may need more. All team members participate in the creation of the ground rules and agree to follow them. Once the team establishes ground rules, ask:
Does everyone agree to follow the rules? (Important to ensure commitment to these rules)
How will you point out violations? (This is a function of the team.)
Where will the ground rules “live” so they can be easily accessed?
Has everyone provided input?
How will new members be informed of the ground rules?
How often will we review / change these ground rules?
One question asked at every Sprint Retrospective meeting: How well is our team working? If you’ve established ground rules, you can ask how the ground rules are working and if there have been violations that weren’t addressed. Remind the team that they are responsible for not only following the ground rules, but also pointing out when a team member is not. With ground rules in play, you won’t have to act as a police officer making sure that the rules are enforced.
Anaplan has shifted strategy around the establishment of a Center of Excellence (CoE) from being only needed for large organizations to being considered for every project. Not every customer will recognize the need for a CoE at the beginning of the project. The project may be well into the sprint cycles before the customer realizes they need a CoE. Remember the customer relies on Anaplan expertise; lay the groundwork for the CoE up front. Complete the first three steps during the Foundation phase:
Include a data hub as part of the model design. This will make it much easier to add another model for a different use case.
Document the business processes. When a new use case is being considered, you’ll be able to determine how it fits into the overall business process. You won’t have to ask the customer to repeat the exercise of explaining the processes.
Document the model logic and business rules:
Technical ecosystem topology
Model flow (model map)
For more information, see Chapter 9, Center of Excellence.
During sprint planning, lay the foundation for managing the project using Agile Scrum methodology. Gather requirements, complete the model design, and use planning poker to craft the sprint schedule. Explain to the customer the proven way to keep sprint planning on track: managing the buckets.
Writing user stories ranks at the top of critical project tasks. When the customer writes user stories, business subject matter experts (SME) sit down with the Scrum team to lay out user requirements – what the user community needs from the Anaplan platform so they can follow the business process. For example, a customer may be using the Anaplan platform to improve their sales forecasting process. The team needs to discuss all upstream and downstream processes within the sales forecasting process that Anaplan will impact.
The customer documents requirements by producing user stories. A user story includes:
The description should be as comprehensive as is possible. Model builders take user stories and build the model, set up processes and data feeds. If possible, include an Excel file to be used as a visual guide or template for what is required.
When writing user stories, it is easier to put the work in early and create a good user story. You’ll find it more challenging to revisit a user story later in the project timeline. Write comprehensive user stories, however if the story starts getting long break it into separate pieces. In the next step, you’ll estimate how long it will take to build out that user story. If the user story isn’t well written, it will throw the estimating process off track.
User stories are usually written by a business SME in conjunction with someone from IT. Anaplan Business Partners and the project sponsor review the user story to ensure quality, accuracy, and business need.
Notice the User Story Task list in the graphic above. The task includes things that need to get done in addition to the actual model build. All tasks take time and require resources that need to be estimated along with the actual model build.
Typically, you can expect between 75 and 125 user stories in a project. Generating more than this range may indicate a need for a phased implementation.
How do you plan how long each user story takes to build? Use the Sprint Planning Tool (aka Planning Poker). While it may seem a bit silly to play a card game to determine level of effort, using this tool results in:
A stronger project team. This collaborative task serves to enhance team dynamics and define roles within the team.
Diverse perspectives. Two heads are better than one; more are better.
Consistency. Planning poker provides a unit of measure that you can use to easily recalculate how long all of the user stories will take if your estimate is off.
Cards are an important part of this tool. Members of the team make estimates by playing numbered cards face-down on the table, instead of speaking them aloud. The cards are revealed and the estimates are then discussed. By hiding the numbers and sharing them all at once, the team avoids bias – where the first number spoken aloud sets a precedent.
What do you need?
Each person needs a set of poker planning cards. Alternate: have participants download a mobile app. They will need a standard set of Agile Scrum cards – search in the app store for Agile Scrum Planning.
A moderator to facilitate the voting and decision making process and keep time.
Seating around a table, so everyone can see the cards.
Determine a baseline
The first step is to share the baseline – or in other words, the number of points for a user story of medium complexity and medium build time. In the example below, the baseline is 8 points. The baseline should be between five and 13 story points. This table can be found on the Sprint Planning tab of the Agile Implementation – The Anaplan Way app.
It is important to understand how this baseline works. The base line IS NOT a straight estimate of time, it is an estimate of complexity and effort that equates to time. The difference is subtle but important.
In the example above a story with Medium complexity and Medium time equals eight points, while one with Medium complexity but Low time is two points, and Medium/High is 20 points. If the group decides each point is worth two hours of development time then the Medium/Medium story should take 16 hours to develop, the Medium/Low should take four hours, and Medium/High equals 40 hours.
This comes into play if adjustments are needed. If, for example after the first sprint, the group discovers their estimate was wrong it can be corrected quickly. Say the stories that were Med/Med only took eight hours (half the time estimated). With this system, you can just go through and refigure the math (done automatically in the Anaplan Way app). Now the story ranked two points would change from four hours to two and the 40-hour story is reduced to 20.
This allows you to quickly recalculate not only the story build times but also sprints. In this example, we can now put more stories into each sprint, decrease the time estimate for the release date or add more stories to this release from the master bucket all because the stories are not taking as long as the original estimate.
Determine meeting time
Next, determine how many minutes to spend estimating each user story during the meeting. Take the number of minutes the team will be meeting and divide by the number of stories to determine how much time you have for each story. For example, the team will be meeting for the rest of the day, so you have about 6½ hours of working time (taking breaks into account) and you have 75 user stories. That’s 390 minutes / 75 = ~ 5 minutes per story.
The user story owner gets up and reads the story to the group in such a way as all can understand it and can vote on how long they think the user story will take to create, end-to-end. The user story owner can answer questions or provide clarity.
For our example of 5 minutes per story, each story should take no more than 2 minutes. Five minutes – (1 minute for questions + 2 minutes for voting) = 2 minutes.
The voting members think about the story and have one minute to ask clarifying questions.
Everyone has 30 seconds to pick the card that represents the number of points for the user story.
Steps 3 – 6 take up to two minutes.
When the 30 seconds is up, the moderator calls for the vote and everyone shows his or her card.
If there is consensus, the points are recorded and the team moves on to the next user story (step 1). If there was not consensus, continue with step 6.
If there was not consensus, but there are consecutive cards, the higher card is chosen for the user story points. If there was not consensus and the cards were not consecutive, then the moderator calls for one minute of discussion and a re-vote. If there is still not consensus, the moderator adds the user story to the parking lot. The user stories in the parking lot will need to be re-visited at a later time.
At the end of voting, you’ll have story points for each user story. In the Agile Implementation -The Anaplan Way app, assign a multiplier for the project. Begin with two or three as the multiplier: see what works best by comparing the number of hours for the first sprint using the multiplier and the total number of build hours available for the sprint. Adjust the multiplier as the project progresses and model builders get past the learning curve and up to speed.
If you can get through user stories and have some time left in the day, go back to see if you can get through the stories in the parking lot. If you are out of time and parking lot items remain, schedule another meeting to work through those user stories.
Time spent at the front end of the model design process is time saved during the model-building process. Great model design helps the customer avoid a trip back to the drawing board after you’ve realized you completely overlooked an important piece of structure or processes. In model design, begin by:
Understanding the business requirements for the model (in the SOW)
Identifying who will use the model (defined in the SOW)
Documenting how users will interact with the model (defined by user stories)
Establishing how data flows through the model (defined in Rough Cut or SOW)
These considerations must be clearly defined to avoid any unwanted surprises after model building begins.
Remember: measure twice, cut once. When completing a model design, double-check information before you get started. Work through your design by white boarding or using flip chart paper to capture the model elements and process flow. Design the model before you begin to build. Anaplan uses a flexible, Agile process for development, so things will change and shift a bit.
The architecture within the Anaplan platform that drives model design contains three simple components:
Shared dimensions and lists (Library)
Think of the shared dimensions and lists as being a library of the lists and versions needed for the model. It may include organization lists, including hierarchies, product lists, and employee lists. When a change is made to a list, that change is included wherever the list is used in the model.
Three types of modules do the real work:
Use Input modules to import data. An input module might also be a module where the user will enter data using a dashboard.
Use an Engine model to perform calculations.
Use an Output module to collect data (possibly from several driver modules) needed for dashboards.
The user experience (or dashboard) holds the components that a user needs to do their job. They include:
Filter or change views
Data input fields
Modules, parts of modules, and other objects generate dashboard outputs.
Model design can get very complex. There are many moving parts; both project teams and business partners who aren’t well versed in model construction can become overwhelmed. Use this white boarding example as a way to help project teams understand Anaplan model design.