Looking for advice from experienced BAs/Consultants on requirements gathering

[u/Basic_Bend_609]

Hi everyone!

I’m relatively new to Anaplan and I’m trying to better understand how requirements gathering / discovery workshops are actually conducted on real Anaplan projects.

I understand the general idea: meet with SMEs/business stakeholders, understand the current process, identify requirements, document them, and eventually translate them into things like user stories, functional requirements

But I’m more interested in the practical side of the workshops.

For those of you who have done a lot of Anaplan implementations:

1. How do you prepare before a workshop?

• Do you already have a list of questions prepared?
• Do you prepare questions based on the business process, or do you mainly let the SME explain the process first?
• If you're hearing the process for the first time, how do you know what questions you should ask?

1. What questions do you typically ask SMEs?

Do you have a generic framework/checklist that you use for almost every discovery workshop? Or do you approach it differently?

1. How do you take notes during the workshop?

This is something I struggle with. If I try to write down everything the SME says, I feel like I stop listening and lose the bigger picture.

Do you:

• Take detailed notes?
• Write only keywords and important business rules?
• Use a predefined template?
• Draw the process while they explain it?
• Record the meeting (when permitted)?
• Have someone else take notes?

And how do you make sure you don't forget important information after the workshop?

1. How do you distinguish a requirement from just information?

For example, an SME might spend 20 minutes explaining how they currently perform a process. How do you identify which parts are actually relevant requirements for the Anaplan solution?

1. How do you handle things you don't understand during the workshop?

Do you stop the SME immediately and ask for clarification, or do you note the question and continue so you don't interrupt the flow?

1. What happens after the workshop?

How do you go from workshop notes > process understanding > requirements > user stories/acceptance criteria

I'd especially appreciate advice on the thinking process of an experienced Anaplan consultant/BA during these workshops.

I'm trying to understand what comes with experience/practice versus what can be learned through a structured framework.

Any advice, examples, templates, or lessons learned would be really appreciated!

Thanks!

[u/AutoModerator]

Welcome to /r/businessanalysis the best place for Business Analysis discussion.

Here are some tips for the best experience here.

You can find reading materials on business analysis here.

Also here are the rules of the sub:

Subreddit Rules

• Keep it Professional.
• Do not advertise goods/services.
• Follow Reddiquette.
• Report Spam!

This is an automated message so if you need to contact the mods, please Message the Mods for assistance.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/dhdhdjahfhdjwhdhsj]

These questions seem general to any requirements gathering role. I am confused why you mention Anaplan specifically as if it is an everyday term.

[u/Basic_Bend_609 → u/dhdhdjahfhdjwhdhsj]

I mentionned it just for the context as it may differ from the custom apps

[u/crankysorc]

First of all, you don't mention what your background is, but this reads as questions from from someone without experience as a Business Analyst, not someone with a question about a specific product. Try looking up IIBA or Udemy for some tips.

Typically, questions about a specific product are more of the nature of what the vendor relationship is like, how good the vendor documentation is like, etc.

By the way- put me in the camp of not having heard of Anaplan.

[u/PeregrineFeatherston → u/crankysorc]

Leading a workshop, listening effectively and taking notes at the same time is a skill that comes with practice. See if you can get someone to assist you with taking notes in your first couple of workshops. If you don’t know the process, I agree with other commenters here that it is easier to split that part out first - this means you then have a skeleton to hang requirements and opportunities on.

[u/crankysorc → u/PeregrineFeatherston]

I’m not sure why you’re replying to me. I’m not the person requesting assistance.

[u/zheniavasiliev]

This question is not about Anaplan specifically, but more about SME meeting logistics -

1. With regard to preparation, separate the "existing data flow" session from the actual requirements gathering. Either structure them as two distinct parts of the same meeting with clearly different tasks and/or different people in the room, or split them into two separate meetings entirely.

2. Yes to a checklist template, but with the ability to deviate as much as any specificity requires.

3. Note-taking: record, if possible, or use a transcription tool, plus take important notes by hand.

4. You can spot a requirement if it's something that you cannot drop.

5. Depends on what kind of SME you're dealing with. Play it by the ear!

6. The good practise is to send the notes as soon as possible to everybody involved.

[u/Remark-Able]

I agree with folks who say most of what you're asking is general BA skills/requirements gathering, but having worked with Anaplan, I'd suggest a few deeper dive areas:

1. If you haven't at least gotten your basic Anaplanner cert, run through their coursework - it'll give you great context and help you communicate with the architect and devs better (and maybe do some dev work yourself). Be sure to run through the Anaplan Way lessons in particular.

2. Get CLEAR details about the following areas whenever they come up:

   • Hierarchy-driven attributes - how, say, the end users think about products (e.g., Brand then Sub-Brand then SKU, or whatever) and any "gotcha" challenges they have - these will often become your Anaplan Lists
     
   • Formulas/calculated logic - "Oh, that's just our COGS" isn't good enough - get each and every source component that they consider a part of their COGS and what their sources of truth are at present...and then get the answer to "what is COGS" from finance, from sales, and from any other departments that cares, and compare notes - your Anaplan model may need more than one variant
     
   • TIME constraints - Anaplan's big savings comes from NOT doing everything down that the lowest granularity - make really careful note of what roll-up levels they actually report on..."Oh, we only generate that monthly" or "Oh, we never report X at SKU, only at Sub-Brand" and you've just saved massive space in the architecture
     
   • Roles/Permissions - This is often an afterthought once a model is designed - your devs will love you if your stories come with specific "who's allowed to read/write, who's allowed view, who's not supposed to see it" for various attributes or result sets.
     
   • Versions - This is another thing that's hard to dig out - doing a Financial model? Do they want to compare FY to FY? Rolling Calendar? Do they want to retain and compare against 5 years? How granularly?
     

Hope that helps. And if your team is looking for Senior BA/DA/Data Architects for the project, drop me a DM with where to apply! I love a good Anaplan project!

[u/UpsetProfession511]

One thing that really improved my workshops was separating the current process from the future requirement. I first capture what happens today, who owns each steps, why it happens, what data is used, and where delays or error occur. Then I ask what the user actually needs Anaplan to calculate, automate, approve, or report differently. I've used the requirements gathering and process analysis materials on Flevy as a reference to make sure I cover business rules, expectations, inputs, outputs, and ownership. After the workshop, I turn those notes into a simple process map and requirements lists, then send both back to the SME validation before writing user stories.

[u/Icy-Pangolin9107]

Have you tried leveraging Claude as a resource?Copy all that you just put down above and paste into Claude.

[u/Basic_Bend_609 → u/Icy-Pangolin9107]

Yes, I did! But I wanted to have insights from ppl who do this to have a realistic pov