Requirements gathering for Dynamics 365 implementations

Requirements gathering is the foundation of every Dynamics 365 implementation. Done well, it produces clear functional designs and confident scoping; done badly, it leads to discovery surprises, rework, and budget overruns. The methodology matters less than the discipline applied.

The output goals.

• Clear understanding of as-is processes.
• Defined to-be processes.
• Specific functional requirements.
• Non-functional requirements (performance, security, etc.).
• Prioritisation (must-have, should-have, nice-to-have).
• Documented assumptions and risks.
• Stakeholder consensus.

The output feeds FDDs, TDDs, and project planning.

Workshop-based approach. Most common:

• Facilitated workshops per business area.
• Stakeholders engaged in person or virtually.
• Documented in real-time.
• Iterative validation.

The workshop format produces alignment alongside requirements.

Workshop preparation.

• Pre-read materials sent.
• Specific agenda.
• Right participants invited.
• Workshop length appropriate (half-day to multi-day).
• Logistics organised.

Unprepared workshops waste senior time; preparation matters.

Discovery techniques.

• Process mapping — walk through current state step by step.
• Pain point analysis — what's broken in current process?
• Aspirational visioning — what would the future look like?
• Quick-win identification — what's easy and high-impact?
• Edge case discussion — what unusual scenarios occur?

Combine techniques to draw out comprehensive requirements.

As-is vs to-be.

• As-is — current state documentation.
• To-be — desired future state.

The gap analysis between them is the implementation scope.

Why document as-is. Tempting to skip:

• Saves time.
• Future-focused.

But:

• Reveals dependencies on legacy.
• Surfaces process knowledge held by individuals.
• Provides context for to-be design.

Always document as-is, even briefly.

To-be process design.

• Reflect best practices.
• Match Dynamics 365 standard processes where appropriate.
• Customise only where business genuinely demands.
• Validate with stakeholders.

The "fit-gap" analysis identifies where standard fits and where it doesn't.

Functional vs non-functional requirements.

• Functional — what the system does (e.g., "create sales order").
• Non-functional — quality attributes (performance, security, scalability, usability).

Both essential; non-functional often overlooked until late.

Common non-functional requirements.

• Performance — response time targets.
• Availability — uptime requirements.
• Scalability — user count, data volume.
• Security — encryption, access control, audit.
• Compliance — regulatory requirements.
• Accessibility — WCAG, Section 508.
• Localisation — multi-language, multi-currency.

These shape architecture and implementation.

Prioritisation methods.

• MoSCoW — Must, Should, Could, Won't.
• High / Medium / Low.
• Value vs effort matrix.
• Cost / benefit analysis.

Force ranking — be explicit about trade-offs.

Stakeholder management.

• Executive sponsors — strategic direction.
• Business owners — process accountability.
• Subject matter experts — operational detail.
• Power users — daily use perspective.
• IT team — technical integration.

Engage appropriate level for each requirement type.

Documentation formats.

• Process narrative — text describing flow.
• Flow diagrams — visual.
• User stories — "As a [role], I want [action], so that [benefit]."
• Use cases — formal scenarios.
• Requirements catalogue — structured list.

Different audiences prefer different formats; multiple representations may help.

Tools.

• Microsoft Word / Excel — common.
• Microsoft Loop / OneNote — collaborative.
• Confluence — for development-led teams.
• DevOps Boards — user stories tied to development.
• Specialised requirements tools — IBM DOORS, others.

Tool choice less important than discipline.

Validation cycles.

• Draft requirements.
• Review with stakeholders.
• Revise based on feedback.
• Validate with final readers.
• Sign-off at design completion.

Iteration is healthy; first-draft signed off rarely matches reality.

Common pitfalls.

• Wishlist syndrome. Every nice-to-have included; scope explodes.
• Anchoring on current. "Same as today but in Dynamics" — misses opportunity.
• Missing edge cases. Happy path documented; exceptions emerge in test.
• No prioritisation. Everything's a "must"; budget impossible.
• Stakeholder absence. Key person missed; requirements gap.
• Verbal-only agreement. Documented vaguely; interpretation differs.

Discovery anti-patterns.

• Boil-the-ocean discovery. Months of analysis paralysis.
• Insufficient discovery. Rush to build; discoveries come later as change orders.
• Wrong abstraction level. Either too detailed too early or too vague throughout.

Time-boxing. Discovery shouldn't be indefinite:

• Plan phase duration.
• Acknowledge some unknowns won't resolve until later.
• Document what's known and assumed.
• Move forward; refine during build.

Iterative discovery. For agile implementations:

• High-level requirements upfront.
• Detailed per-sprint discovery.
• Backlog grooming.

Suitable for some projects, not all; depends on scope clarity.

Standard vs custom. Important judgement:

• Adopt standard wherever possible — easier maintenance.
• Customise only where business value clearly justifies.

The "we always do it this way" reflex often hides opportunities to adopt better-fitting standards.

Strategic positioning. Requirements gathering is investment in clarity. Spent well, it produces confident designs; spent poorly, it produces brittle specifications that don't survive contact with build. Mature implementations balance enough discovery to design confidently with enough humility to refine during build.

For project leaders:

• Plan discovery time deliberately.
• Engage right stakeholders.
• Document candidly, not aspirationally.
• Prioritise ruthlessly.
• Iterate; don't expect first pass to be final.

The discipline is constant attention to clarity and stakeholder engagement; the payback is build phases that proceed smoothly without constant re-questioning of requirements.