Discovery Phase Best Practices: What to Expect & How to Get It Right

What Is the Discovery Phase?

The discovery phase is a structured, facilitated investigation into how your organization operates today and how you want it to operate after Dynamics 365 is deployed. It’s a collaborative effort between your team and the implementation partner to:

• Document current state (as-is) — Map existing processes, systems, data structures, and workflows
• Define future state (to-be) — Design optimized processes that leverage Dynamics 365 capabilities
• Identify requirements — Capture functional, technical, data, and reporting needs
• Assess gaps and fits — Determine where standard functionality covers your needs vs. where customization is required
• Estimate scope and effort — Translate requirements into implementation timeline and cost
• Build alignment — Ensure executive, functional, and technical stakeholders agree on the vision

Discovery is not a sales presentation or a product demo. It’s not about convincing you that Dynamics 365 is the right choice—that decision has been made. Instead, it’s a deep-dive investigation that produces documented, agreed-upon deliverables that become the contract basis for the rest of the project.

Typical Duration & Timeline

Most discovery phases last 2–6 weeks, depending on several factors:

Complexity Level	Typical Duration	Key Variables
Small, single-entity business	2–3 weeks	Fewer processes, fewer stakeholders, limited integrations
Mid-market, multi-location	3–4 weeks	Multiple business units, complex supply chain, multi-currency, regional variations
Large enterprise, multi-division	6–8 weeks	Dozens of business processes, 50+ stakeholders, complex data migration, extensive integrations, regulatory compliance

Discovery typically follows this sequence:

1. Week 1: Kickoff & Planning — Establish team structure, communication cadence, and logistics. Tour the current environment. Gather preliminary documentation (org charts, system inventory, business strategy).
2. Weeks 2–4: Intensive Workshop Sessions — 2–4 facilitated workshops per week, each focused on a major process area (Order to Cash, Procure to Pay, Plan to Produce, Financial Close, etc.). Parallel workstreams for technical requirements, data, reporting, and integration.
3. Weeks 3–5: Validation & Refinement — Partner synthesizes workshop output into process flows, requirements matrices, and gap analyses. Stakeholders review and validate. Refinement iterations.
4. Week 5–6: Executive Alignment & Delivery — Executive steering committee reviews solution blueprint and project plan. Sign-off on scope, timeline, budget, and resource plan.

Discovery Workshop Structure

A well-run discovery involves multiple facilitated workshops, each structured to capture specific information. A typical workshop agenda looks like this:

Workshop Type	Duration	Key Attendees	Purpose
Process Mapping Workshop	4–6 hours	Process owner, 4–8 functional users, partner facilitator	Map current and future state processes using swim lanes, decision points, and integration touchpoints
Requirements Workshop	4–6 hours	Functional leads, supervisors, business analysts, partner consultant	Elicit and prioritize functional and data requirements specific to the module (FI, SCM, etc.)
Technical Requirements Workshop	2–3 hours	CIO/IT director, systems administrators, DBAs, security officer, partner architect	Document architecture, integration, security, performance, disaster recovery, and compliance needs
Data & Reporting Workshop	2–3 hours	Data steward, IT operations, business intelligence lead, analytics users, partner data specialist	Inventory data sources, define master data strategy, capture reporting and analytics requirements
Change Management & Training Workshop	2 hours	Project sponsor, HR, training coordinator, change manager, partner change lead	Define org change readiness, training scope, communication plan, and user adoption strategy

Each workshop should:

• Start with an agenda — Attendees know the topics and desired outcomes
• Use a professional facilitator — The partner provides a trained facilitator who keeps the conversation structured and focused
• Capture output visually — Use whiteboards, flowcharting tools, or sticky notes to create visible artifacts
• Record and document — A scribe or recording captures details for later synthesis
• End with action items — Clarify what happens next, what additional information is needed, and when the team reconvenes

Requirements Gathering Techniques

Professional implementation partners use a combination of techniques to elicit and document requirements:

1. Facilitated Workshops (Primary Method)

Group sessions where stakeholders collaboratively define what they need. Workshops are efficient because they align multiple perspectives and resolve conflicts in real time. The downside: some quieter participants may not speak up, and dominant voices can sway the room.

2. One-on-One Interviews

Follow-up conversations with individual stakeholders—process owners, power users, supervisors—to capture nuanced requirements and personal workflows that don’t surface in group settings. Interviews are time-consuming but reveal edge cases and workarounds.

3. Observation & Job Shadowing

A partner consultant shadows a user through their daily workflow to understand how they actually work, not just how the documented process says they should work. This often reveals manual workarounds, data quality issues, and unofficial processes.

4. Document Review

Analysis of existing policies, procedures, training materials, system documentation, and transaction logs to understand current rules, data structures, and pain points.

5. Requirements Matrices

Structured tables that list requirements by category (functional, technical, reporting, integration, compliance) with attributes like priority (must-have, should-have, nice-to-have), effort estimate, and owner. Matrices create a shared source of truth and enable prioritization conversations.

6. Prototyping & Proof of Concept

For critical or complex requirements, building a quick prototype (e.g., a sample Dynamics 365 configuration) demonstrates feasibility and surfaces questions. The partner should never promise a POC during discovery; that’s a sign they’re conflating discovery with implementation.

Best-in-class partners use a combination of all six, tailoring the approach to your organization’s size and complexity. A partner that relies solely on workshops is cutting corners; one that insists on extensive job shadowing and interviews for a simple implementation is over-engineering.

Process Mapping: As-Is vs. To-Be

Process mapping is the single most important artifact of discovery. It’s where the rubber meets the road: instead of talking about requirements in the abstract, you’re documenting how work actually flows.

As-Is Process Map (Current State)

Documents how you run your business today, including:

• All manual steps, handoffs, and delays
• Workarounds and unofficial processes
• System integrations and data movements
• Decision points and exceptions
• Bottlenecks and pain points

The as-is map reveals where time is wasted, where errors creep in, and where data gets stuck. It’s not about blaming people; it’s about understanding the ecosystem you’re transforming.

To-Be Process Map (Future State)

Redesigns the process to eliminate waste and leverage Dynamics 365 capabilities. A good to-be map:

• Reduces manual steps through automation
• Clarifies roles and handoffs
• Builds in controls and audit trails
• Aligns with Dynamics 365 best practices and standard configurations
• Balances standardization with business-critical flexibility

Many implementations fail because the to-be map is too ambitious (trying to redesign too much) or too conservative (just automating the current broken process). A skilled partner facilitator will challenge you to optimize while respecting your business model.

Red Flag: If your partner creates process maps but they’re generic, full of Dynamics 365 jargon, or don’t reflect your actual workflows, they haven’t done the work. Push back and insist on detailed, business-specific process documentation.

Stakeholder Interviews & Engagement

Discovery requires input from across your organization. Typical stakeholder groups include:

Stakeholder Group	Typical Count	Role in Discovery
Executive Steering Committee	3–7	Define business objectives, approve scope, sign off on recommendations
Project Sponsor	1	Ensure business alignment, resolve escalations, provide resources
Process Owners	3–8	Detail their processes, identify requirements, validate to-be workflows
Functional Business Analysts	1 per major area	Detail requirements, coordinate with business, identify gaps and fits
Power Users	2–3 per module	Describe their workflows, identify edge cases, validate proposed solutions
IT / Systems	2–4	Provide system landscape, integration requirements, security and compliance constraints
Finance/Accounting	2–3	Define chart of accounts, reporting needs, intercompany rules, audit requirements

A Critical Discovery Red Flag: Absence of Executive Interviews

Some partners treat discovery as purely a functional/technical exercise and skip interviewing the CFO, COO, or business unit heads. This is a major mistake. Executives define strategic objectives (cost reduction, time-to-market, compliance), constraints (budget, timeline, risk tolerance), and the governance model for the project. Without executive input, discovery is incomplete.

Best Practice: Schedule a structured executive interview (1–2 hours) early in discovery, and then a validation session at the end so the steering committee can affirm that the proposed solution aligns with strategic goals.

Gap-Fit Analysis During Discovery

A gap-fit analysis quantifies how Dynamics 365 standard functionality aligns with your requirements. For each major requirement, the partner documents:

• Fit: Standard Dynamics 365 functionality addresses the requirement as-is, no customization needed
• Gap: Standard functionality is insufficient; customization or workaround is required
• Effort to Close: How much development effort is needed (hours, cost)
• Mitigation: What option the partner recommends (customize, use a third-party ISV add-on, accept a process change, or defer)

A sample gap-fit matrix for a supply chain module might look like:

Requirement	Category	Priority	Fit/Gap	Effort	Recommendation
Multi-level bill of materials with engineering change orders	Functional	Must-have	Fit	0 hours	Use standard functionality
Supplier portal for PO collaboration	Functional	Should-have	Gap	120 hours	Use ISV add-on (e.g., Coupa)
Demand forecasting with ML	Functional	Nice-to-have	Partial Fit	80 hours	Use standard ML features, defer advanced customization to Phase 2

Gap-fit analysis is critical because it drives the project estimate. A partner that glosses over gaps or promises to "figure it out in implementation" is setting you up for cost overruns and delays. Insist on detailed gap-fit analysis and clear mitigation recommendations.

Key Deliverables from Discovery

At the end of discovery, your partner should deliver five essential documents:

1. Solution Blueprint (aka Technical Design Document)

A 40–100-page document that describes the proposed Dynamics 365 configuration at a detailed level: organizational structure, modules, core processes, module-specific configurations (e.g., inventory models, posting profiles, workflow rules), integrations, reporting structure, and security model. This is the single source of truth for what you’re building.

2. Functional Requirements Document (FRD)

A comprehensive list of functional requirements organized by module or business process, including the gap-fit analysis, priority levels, acceptance criteria, and notes. Often delivered as a detailed spreadsheet rather than a narrative document.

3. Process Documentation

Detailed process flows (as-is and to-be) for each major business process, typically captured in visio diagrams, flowcharts, or swim-lane diagrams. Process documentation should be detailed enough that a new team member could understand how work flows.

4. Scope Statement

A concise document (2–5 pages) that articulates what is in scope, what is explicitly out of scope, and key assumptions. The scope statement prevents scope creep by establishing clear boundaries. Example: "In scope: Finance module, Accounts Payable, and Accounts Receivable. Out of scope: treasury management, intercompany accounting, advanced consolidation."

5. Project Plan & Estimate

A preliminary project plan with phases, milestones, resource requirements, and high-level timeline. The estimate typically includes budget ranges for implementation partner labor, licensing, infrastructure, training, and contingency. A good estimate has ranges, not fixed numbers, because discovery always reveals new complexity.

Bonus Deliverables (Advanced Partners)

Some partners also deliver:

• Data Migration Strategy: How you’ll move from old systems to Dynamics 365, data validation rules, cutover approach
• Integration Architecture: Detailed diagram showing data flows between Dynamics 365 and other systems (ERP, CRM, accounting, HR, web services)
• Change Management & Training Plan: Communication strategy, training curriculum, user acceptance testing (UAT) approach, cutover readiness assessment
• Risk Register: Identification of implementation risks (scope creep, resource constraints, data quality, integration complexity) with mitigation strategies

Red Flags in Discovery

Watch for these warning signs that your partner isn’t executing discovery properly:

1. Rushing Discovery

A partner that wants to compress discovery into 1–2 weeks for a mid-market organization is either inexperienced or not committed to your success. If they say "we’ve seen this before, we can skip the workshops," that’s a red flag. Every organization is unique.

2. No Process Mapping

If discovery deliverables don’t include detailed, business-specific process flows, the partner hasn’t done the work. They’re planning to figure it out during implementation, which means cost overruns.

3. Absence of Executive Interviews

If the partner conducted discovery entirely with mid-level managers and functional teams but never spoke to the CFO, COO, or CEO, they’re missing critical strategic context. This leads to solutions that don’t align with business objectives.

4. Generic Deliverables

If the solution blueprint, process flows, or requirements documents look like they could apply to any company (full of template language, generic processes, no mention of your specific business), the partner hasn’t tailored their analysis to your organization.

5. Over-Promising in Discovery

If your partner keeps saying "yes, we can do that" to every requirement without documenting gaps or discussing trade-offs, they’re selling, not discovering. A honest partner will say, "That’s a gap. Here’s what it will take to close it."

6. Skipping Data & Integration Workshops

Data migration and system integration are often where implementations blow up. If discovery doesn’t include detailed data mapping, integration architecture, and master data strategy, you’re in for pain. Make sure your partner conducts dedicated data and integration workshops.

7. No Estimate Ranges or Caveats

If the partner gives you a fixed cost quote based on discovery, they’re either overconfident or setting you up for change orders. A responsible partner provides estimate ranges with clear assumptions and contingencies.

How Discovery Feeds the Statement of Work

The Statement of Work (SOW) is your contract with the implementation partner. It should be based almost entirely on discovery deliverables. Specifically:

• Scope: Taken from the Scope Statement produced in discovery
• Deliverables: Based on the Solution Blueprint and Process Documentation
• Timeline: Derived from the Project Plan created during discovery
• Effort & Cost: Based on the estimate and gap-fit analysis
• Resource Plan: Details of partner staffing (project manager, solution architect, technical leads, functional consultants)
• Testing & Acceptance: Acceptance criteria derived from the Functional Requirements Document

If your SOW doesn’t closely align with discovery deliverables, something is wrong. Either discovery was incomplete, or the partner is adding assumptions that weren’t discussed. Read your SOW against the discovery documents line by line. If the SOW describes scope that wasn’t in the discovery brief, that’s a red flag.

Paid vs. Free Discovery

Some partners offer free discovery as a sales tactic; others charge a fee (typically $10K–$50K for a mid-market project). There are tradeoffs:

Model	Pros	Cons
Free Discovery	Low financial commitment; allows you to evaluate the partner at minimal cost	Partner may cut corners; deliverables may be shallow; partner is incentivized to upsell the implementation estimate
Paid Discovery	Partner is incentivized to do thorough work; attracts serious, professional firms; results in higher-quality deliverables; discovery fee is often credited against implementation cost	Higher upfront investment; you’re committing resources without a full implementation commitment

Recommendation: For organizations larger than $50 million in revenue or with complex operations, insist on paid discovery. For smaller organizations, free discovery is acceptable if the partner commits to a structured, multi-week engagement with clear deliverables.

If you do free discovery, make sure the partner commits to delivering the five core artifacts (blueprint, FRD, process docs, scope statement, estimate) in writing. Without a commitment to deliverables, free discovery is just a sales conversation.

Using Discovery as a Partner Evaluation Tool

Beyond documenting your requirements, discovery is a chance to evaluate whether you’ve chosen the right partner. Pay attention to:

1. Facilitation Quality

Are the partner’s facilitators skilled at drawing out information, keeping discussions on track, and building consensus among diverse stakeholders? A good facilitator makes workshops productive; a poor one wastes time and leaves people frustrated.

2. Listening vs. Selling

Does the partner listen to understand your business, or do they keep steering conversations back to Dynamics 365 capabilities? A partner that’s genuinely interested in your operations will ask follow-up questions, challenge assumptions, and sometimes suggest you not buy Dynamics 365 for certain requirements.

3. Communication & Responsiveness

Do they respond to emails promptly? Do they send clear recaps after meetings? Do they follow up on action items? Poor communication during discovery will only get worse during implementation.

4. Depth of Expertise

Are the people on your discovery team experienced with your industry and use cases? Or are they generic Dynamics 365 consultants? If they’re asking basic questions about your business, that’s a red flag.

5. Willingness to Challenge

A partner that agrees with every requirement without pushing back is not thinking critically. The best partners will say things like: "That process is causing you a lot of pain. Have you considered redesigning it this way instead?"

6. Evidence of Methodology

Does the partner follow a structured approach to discovery, or does it feel ad-hoc? They should have a discovery methodology, templates for deliverables, a standard workshop agenda, and a clear governance model.

7. Financial Transparency

Does the partner provide a clear breakdown of how the estimate was derived? Can they articulate which requirements are high-risk or high-effort? Or do they give you a black-box number with no justification?

If discovery goes well—your partner is attentive, thorough, business-focused, and produces high-quality deliverables—you have confidence in them. If discovery is rocky, use it as data to reconsider your partnership before you sign the implementation contract.

Frequently Asked Questions

1. How much time should our organization commit to discovery?

Plan for 20–30% of your functional leaders’ time for 4–6 weeks. For a 100-person company with 8 functional leaders, that’s roughly 160–240 person-days of internal effort. Don’t underestimate. Many organizations try to run discovery part-time and end up extending timelines because people aren’t available for workshops.

2. Should we hire a neutral third-party to facilitate discovery?

Not necessary if your implementation partner is skilled at facilitation. However, if you’re concerned about the partner’s objectivity (i.e., you worry they’ll steer you toward their preferred solution), hiring an independent facilitator can be worthwhile. Cost: $5K–$10K for a mid-market project.

3. Can we skip discovery and go straight to implementation?

Technically, yes, but you shouldn’t. Skipping discovery is like building a house without architectural drawings. You’ll spend 3–4x the money making it up as you go. If budget is a constraint, compress discovery rather than skip it.

4. Who should own the discovery process on our side?

Your project sponsor or Chief Digital Officer should own it, with day-to-day leadership from a dedicated project manager or business analyst. Without clear internal ownership, discovery becomes unfocused and deliverables suffer.

5. What if we disagree with the partner’s to-be process design?

That’s healthy. Discovery should include debate about future state. Your business rules, competitive advantages, and constraints should shape the to-be design. If the partner is dismissive of your concerns, that’s a red flag. The final design should be a true collaboration.

6. Should we start configuring Dynamics 365 during discovery, or wait until after?

Wait until after discovery is complete and signed off. Any configuration work during discovery is either redundant (when discovery is later updated) or rework (because initial assumptions were wrong). The only exception: if you’re running a proof-of-concept to validate a high-risk requirement, but that should be called out as a separate workstream, not part of discovery.

7. How detailed should process documentation be?

Detailed enough that a new team member could follow the process. At a minimum: swimlanes (who does what), decision points, data inputs/outputs, and system interactions. Avoid being so granular that you document every mouse click; that’s a job aid, not a process flow.

8. What happens if discovery reveals that Dynamics 365 isn’t the right fit?

That’s rare but possible. Sometimes discovery uncovers requirements that Dynamics 365 fundamentally can’t meet without massive customization. A responsible partner will tell you this. If they do, respect that feedback. It’s better to find out in discovery than halfway through implementation. However, in most cases, you’ll find a path forward—either through configuration, ISV add-ons, or accepting a process change.