This is the third in our series exploring key insights on implementation methodologies for Microsoft and this one is focused on Dynamics 365 Project Types.
The Complexity Trap: Right Sizing Your Approach
Organizations often fall into one of two traps: over-engineering simple rollouts with excessive governance, or dangerously underestimating the complexity of multi-location, highly integrated deployments.
The Three Types of Dynamics 365 Projects
Microsoft has historically categorized Dynamics 365 implementations into three distinct types.
Rapid Projects
- Users: Less than 25
- Custom Code: None
- ISV Solutions: None
- Integrations: None to one
- Locations: Single location
Rapid projects are straightforward deployments focused on standard functionality. These implementations might involve “a couple of folks on the partner side” who are “perfectly capable of delivering it.” The documentation requirements are minimal, with most project management happening through tools like Azure DevOps.
Standard Projects
- Users: 25 to 250
- Custom Code: Less than 150 hours
- ISV Solutions: 1 to 3
- Integrations: 1 to 3
- Locations: 1 to 3
Standard projects represent the middle ground where most organizations find themselves. These require more oversight and documentation but remain manageable with a structured approach and clear role definitions.
Enterprise Projects
- Users: 250+
- Custom Code: More than 150 hours
- ISV Solutions: 4 or more
- Integrations: 4 or more
- Locations: 3 or more
Enterprise deployments demand comprehensive governance, extensive documentation, and often span months or even years. For example, a multinational, multi-location rollout for 350 users for a manufacturer of chemical goods will require extensive quality control measures.
The Real-World Impact of Misalignment
“Nobody wants to watch a project derail due to poor planning or poor execution,” per Nash Simeunovic. “That’s not on our bucket list.”
When organizations try to force-fit a rapid approach onto an enterprise-scale project, they often encounter:
- Scope creep and budget overruns
- Inadequate testing coverage
- Poor user adoption
- Missing critical requirements discovered too late
- Failed go-lives requiring expensive remediation
Conversely, applying enterprise-level governance to a simple deployment creates unnecessary friction, delays, and costs that can erode stakeholder confidence.
Finding Your Project’s True Complexity
Several factors to consider beyond the basic metrics when determining project type:
Regulatory Requirements: Industries with strict compliance needs (healthcare, financial services, manufacturing with quality standards) often require enterprise-level approaches regardless of user count.
Business Process Maturity: Organizations with well-documented, standardized processes may achieve rapid implementations even with higher user counts. Those with ad-hoc or highly customized processes need more structure.
Change Management Needs: Projects during periods of growth, acquisition, or significant organizational change require more robust methodologies to manage the human element.
Technical Debt: Legacy system replacements with complex data migration needs or numerous system retirements push projects toward enterprise classification.
The Partner Methodology Factor
Many partners have their own branded methodologies (Edge, QuickStart, Express, Rapid) that claim to accelerate deployments. While these can be valuable, they’re typically variations of standard approaches with “additional flavor” for specific industries or client sizes.
The key question isn’t what a methodology is called, but whether it appropriately scales to your project’s complexity. Documentation requirements should be “reviewed” based on the project type, not applied uniformly across all implementations.
Practical Steps for Categorizing Your Project
Here’s how to properly categorize your Dynamics 365 implementation:
- Start with the Numbers: Count users, locations, required integrations, and ISV solutions
- Assess Customization Needs: Be realistic about custom development requirements
- Consider Hidden Complexity: Factor in regulatory requirements, change management needs, and technical debt
- Validate with Your Partner: If they can’t clearly articulate why your project fits a particular category, dig deeper
- Plan for Growth: If you’re on the borderline between categories, plan for the higher level
When to Recalibrate
Our experience with rescue projects provided a clear warning: if your project classification seems off, act quickly. Warning signs include:
- Stakeholders expressing concern about pace or governance
- Scope discussions that keep expanding
- Timeline or budget pressure appearing early
- Confusion about roles and responsibilities
- Lack of clear deliverables matching the project phase
As the executive briefing noted, “If your governance looks the same for a 5-user rollout and a 500-user rollout, something’s off.”
The Bottom Line
Properly categorizing your Dynamics 365 project isn’t just an academic exercise—it’s a critical success factor that impacts every aspect of your implementation. The difference between a rapid implementation with “limited documentation” and an enterprise deployment with “30-plus iterations” isn’t just scale—it’s a fundamental difference in approach, governance, and resource allocation.
Take the time to honestly assess your project’s complexity. Your stakeholders, budget, and career will thank you.
In Part 4 of our series, we’ll explore Microsoft’s Success by Design framework and how it provides guardrails for projects of all sizes.
