Scoping and Estimating UAT Projects: A Guide for MSPs
Scoping UAT projects is where MSPs either protect their margin or destroy it. Under-scope by 20% and your profit evaporates. Over-scope and the client pushes back on pricing. This guide gives you a framework for estimating UAT engagements that accounts for the hidden effort most consultancies miss: defect management overhead, client delays, and industry complexity multipliers.
Accurate scoping starts with understanding what you're actually pricing, which is not just test execution.
What You're Actually Scoping
Most MSPs scope UAT as if it's just running tests. It's not. Here's what a UAT engagement actually includes:
1. Test Case Creation and Planning (15% of effort)
Writing test cases, mapping them to business processes, defining pass/fail criteria, creating test data requirements
2. Client Tester Coordination (25% of effort)
Training client testers, assigning test cases, chasing tester engagement, answering questions, managing availability
3. Defect Management (35% of effort)
Logging defects, triaging severity, coordinating with developers, retesting fixes, managing defect backlogs
4. Progress Reporting and Governance (15% of effort)
Status dashboards, client update emails, go-live readiness reports, sign-off documentation
5. Client Delays and Re-Planning (10% of effort)
Scope changes, tester unavailability, go-live date shifts, priority re-assignments
Notice that actual test execution (the thing clients think UAT is) doesn't appear on this list. That's because the client's testers execute the tests. You're managing the process.
The Test Case Sizing Framework
Start by estimating the number of test cases required. Use ERP modules or functional areas as the baseline:
| ERP System | Modules Implemented | Estimated Test Cases |
|---|---|---|
| Business Central | Single module (e.g., Finance only) | 30–50 |
| Business Central | 2–3 modules (Finance + Inventory) | 60–100 |
| Business Central | Full implementation (4+ modules) | 120–180 |
| SAP S/4HANA | Single business process (e.g., P2P) | 80–120 |
| SAP S/4HANA | Multi-process implementation | 200–350+ |
| NetSuite | Standard implementation | 70–110 |
| Dynamics CRM | Sales or Service module | 40–70 |
These are baseline estimates for standard implementations. Apply multipliers for complexity factors in the next section.
Complexity and Effort Multipliers
Not all UAT projects are created equal. Apply these multipliers to your baseline test case estimate:
Regulated Industries (+30%)
Healthcare, finance, pharmaceuticals require more documentation, audit trails, and compliance validation. Test cases need more evidence capture and sign-off rigor.
Multi-Site Rollouts (+40%)
Testing the same ERP across multiple locations with regional variations (currencies, tax rules, languages) increases coordination effort and test case count.
Data Migration Testing (+25%)
If the project includes migrating legacy data, add test cases for data validation, reconciliation, and integrity checks post-migration.
Third-Party Integrations (+20% per integration)
Each non-standard integration (e-commerce platforms, CRM systems, EDI partners) requires additional test cases for data flow, error handling, and reconciliation.
Heavy Customisation (+35%)
Bespoke workflows, custom reports, and non-standard functionality require more test cases because you can't reuse standard templates.
Example Calculation
Business Central Finance + Inventory implementation (baseline: 80 test cases)
- + Regulated industry (healthcare): +30% = 24 cases
- + Data migration from legacy system: +25% = 20 cases
- + One e-commerce integration: +20% = 16 cases
Total estimate: 80 + 24 + 20 + 16 = 140 test cases
Estimating Consultant Effort
Once you know the test case count, estimate the consultant days required. Use this formula as a starting point:
Effort Formula (Per 100 Test Cases)
For a 100-test-case project, budget 14–26 consultant days depending on client maturity, defect rate, and complexity. For smaller or larger projects, scale proportionally.
Example: 50-Test-Case Project
50 test cases ≈ 50% of the baseline effort = 7–13 consultant days
Example: 200-Test-Case Project
200 test cases ≈ 200% of the baseline effort = 28–52 consultant days
Defect Management Overhead
The single biggest scoping mistake MSPs make is underestimating defect management overhead. Clients think UAT is "run the tests and tick the boxes". In reality, managing defects takes more time than the initial testing.
Why Defect Overhead Is High
- Each defect requires logging, triage, severity assignment, and developer coordination
- Retesting fixed defects takes additional execution cycles
- Critical defects often require multiple fix attempts before resolution
- Clients want status updates on every open defect, creating reporting overhead
Typical defect rates by project maturity:
| Project Type | Defect Rate | Overhead Buffer |
|---|---|---|
| Mature implementation (standard config, experienced SI) | 10–15 defects per 100 tests | +20% effort |
| Typical implementation (some customisation, average SI) | 20–30 defects per 100 tests | +35% effort |
| Complex implementation (heavy custom, new SI team) | 40–60 defects per 100 tests | +50% effort |
Always build in at least 30–40% overhead for defect management. If you're working with an inexperienced implementation partner or testing heavily customised functionality, increase it to 50%.
Industry-Specific Risk Factors
Different industries have different UAT risk profiles. Account for these when scoping:
Healthcare / Pharmaceuticals
- Risk: Regulatory compliance (MHRA, FDA)
- Impact: +30% test cases for validation and audit trails
- Scoping adjustment: Include evidence capture for every test
Financial Services / Banking
- Risk: Data accuracy, fraud controls, compliance
- Impact: +25% test cases for reconciliation and controls testing
- Scoping adjustment: Budget extra time for audit sign-off
Manufacturing
- Risk: Multi-site rollouts, production line dependencies
- Impact: +40% for multi-site coordination and regional variations
- Scoping adjustment: Factor in timezone and language differences
Retail / E-Commerce
- Risk: Integration testing (webshops, POS, payment gateways)
- Impact: +20% per integration point
- Scoping adjustment: Test end-to-end transaction flows
Defining Scope Boundaries
Clear scope boundaries prevent scope creep and protect your margin. Define these upfront in your statement of work:
What's Included
- ✓ Test case creation for agreed modules/functional areas
- ✓ Up to [X] test execution cycles (typically 1–2 cycles)
- ✓ Defect logging and triage
- ✓ Up to [Y] retest cycles for defect fixes (typically 2–3 retests per defect)
- ✓ Weekly progress reporting
- ✓ Go-live sign-off report
What's NOT Included (Add-Ons)
- ✗ Test case creation for new modules added mid-project
- ✗ Additional test cycles beyond the agreed number
- ✗ Retesting beyond the agreed retest budget
- ✗ Post-go-live hypercare support
- ✗ Training client staff to write their own test cases
- ✗ Performance or load testing
Document these boundaries explicitly. When clients ask for "just one more module" or "a few extra retests", you have a clear basis for change requests.
Preventing Scope Creep
Scope creep happens when clients expand the project without acknowledging it's expansion. Prevent this with structured change control:
1. Log All Scope Change Requests
When the client asks to add test cases or functional areas, document it as a formal change request with estimated impact (days, cost).
2. Communicate Impact Before Accepting
"Adding Warehouse Management testing will require 25 additional test cases and 6 extra consultant days. The additional fee is £X. Do you want to proceed?"
3. Track Retest Budget Separately
If you've agreed to two retest cycles per defect, track how many retests you've done. When the budget is exhausted, offer time-and-materials extension.
4. Use a Change Log Dashboard
Keep a visible log of all scope changes so clients can see what's been added. This prevents "but we thought that was included" disputes.
Common Scoping Mistakes
❌ Underestimating Defect Resolution Overhead
Most MSPs budget for test execution but forget that managing 50 open defects takes more time than writing the tests. Always add 30–40% overhead.
❌ Assuming All Industries Are the Same
Healthcare and finance require significantly more documentation and audit trails than retail or professional services. Use industry-specific multipliers.
❌ Not Defining Retest Limits
If you don't cap the number of retest cycles, clients will expect unlimited retesting. Define limits upfront: "includes up to 2 retests per defect".
❌ Scoping Based on Optimism Rather Than Data
New MSPs often assume "it'll probably be straightforward" and scope at the low end of the range. Use historical data from past projects, not best-case scenarios.
Key Takeaways
- →UAT scope includes test case creation, coordination, defect management, reporting, and client delays — not just test execution
- →Start with module-based test case estimates, then apply complexity multipliers for regulated industries, integrations, and customisations
- →Defect management overhead is the most underestimated factor — always add 30–40% buffer
- →Define clear scope boundaries (what's included vs add-ons) and retest limits before the project starts
- →Use structured change control to prevent scope creep from destroying margin
Scope UAT Projects With Confidence
LogicHive helps MSPs deliver UAT engagements profitably with reusable test case templates, defect tracking workflows, and accurate effort reporting across all clients.
Written by Reece Hallam
Sales Director
Reece brings over 15 years of experience in ERP implementations, specialising in Business Central and Dynamics 365. He has led UAT programmes for mid-market manufacturing and distribution clients across the UK and Europe.
View all articles by Reece Hallam