Any good business analyst has a go-to way to extract requirements for your Dynamics implementation. There’s the standard how many users, show me your process collection of questions. But that’s not where the real useful info comes from.
Requirements gathering and planning is not a one-way conversation. If all you had was a list of “go make this” you should just do it yourself. Successful requirements planning needs to be a negotiation. You tell me what you want/need/like. I tell you the most effective way to make that happen in Dynamics. You agree, great. You don’t, then we dance a bit and agree on an approach. This is actually the best value an experienced consultant can bring you.
For me the most important question is simple. It’s “Why?”
Customer: We need to see all of these things on one page.
Customer: It’s how we do it now, so we need to do it that way moving forward.
Customer: Our users are afraid of change.
What I get from the conversation:
· I need to be very aware of making things easier for users. Adding extra navigation steps will hurt user adoption in any engagement but maybe even more so here.
· Use the OOB features that make this less of an issue. Editable sub-grids on the forms. Quick create forms. Business process flows.
· Remove the stuff they don’t need. The business doesn’t care about freight terms for their account records? Gone!
· Maybe I need to investigate other people in the organization to help me get requirements, this one is afraid of change. If we aren’t changing, why am I here?
I posed a question online and the responses were often sarcastic (I know, big surprise). But, the underlying result of these sarcastic responses will help make a better implementation.
What inflated expectations did the sales guy promise would be simple to do?
I would hope that it doesn’t need to be said, but sales and implementation really (really) need to talk. Yes, sales should be selling what’s possible. But sell it in the right context and the right size/effort.
May I have a list of any medications you may be taking?
We’ve all had the customer that made us feel crazy. Changing requirements. Meetings that go off the rails. If only we could know in advance the obstacles.
How often will this requested custom feature be used? By whom exactly? What's his or her name? Is it a real person or an imaginary friend of yours?
Do we really have users that will DO what you’re asking? Are you sure? Did you ask them?
Is this your ACTUAL business process or just how the system we are replacing forced you to do it?
All too often what you see is a list of the old functions from the old system. If all we’re doing is wrapping Dynamics to mimic the old system, meh, I’ll pass.
Why do you need a wolf?
This goes back to my favorite XKCD, the logic boat. The premise is here’s your task list, it seems impossible and illogical. So, you question it.
Do you like cats?
I got nothing.
Do you know the muffin man?
**Here are the genuine responses, of good straightforward questions to ask to get to what you need to make a good implementation of Dynamics.
· Who holds the final decision card on cost to develop the request and priority of the request?
· How is what we are about to build going to generate value for you and your company?
· What are you expecting this to do for you? How can I improve upon the last one you had?
· What would you like to accomplish? How can we help meet your business goals?
· Which license will you be using?
· How will you measure success? Followed by, will your answer be the same in 1 week, 1 month, 1 year?