Skill Estimation

Skill: AL Project Estimation

Purpose

Estimate AL/Business Central projects: complexity scoring, PERT 3-point estimation, SWOT/DAFO risk analysis, cost breakdown by phase, resource allocation, and structured presales documentation.

When to Load

This skill should be loaded when:

• A new BC/AL project needs time and cost estimation
• A feasibility assessment or SWOT analysis is required before commitment
• A presales proposal or technical assessment document is being created
• Resource allocation and team composition need to be defined
• A project plan with milestones and payment schedule is needed

Core Patterns

Pattern 1: Intake Questions (Mandatory)

Before any estimation, gather these parameters:

markdownCopy code
## Project Intake — Required Information

### 1. Project Identity
- Project name (will be used for folder structure)
- Brief description: What problem does it solve?

### 2. Cost Parameters (MANDATORY)
- Hourly rate (e.g., €75/hour, $100/hour)
- Currency (EUR, USD, GBP)
- Contingency buffer: Yes/No (default 15-20%)
- Risk buffer: Low (10%), Medium (20%), High (30%)

### 3. Technical Context
- Target BC version: SaaS, On-Premise, or both?
- Target delivery date
- Existing codebase? (repository URL or workspace path)
- Reference repositories for similar functionality?

### 4. Team (optional)
- Available developers: Junior, Mid, Senior?
- BC experience level: New, Experienced, Expert?

PAUSE — do NOT proceed without cost parameters. Estimation without rates is meaningless.

Pattern 2: Complexity Scoring

Score each dimension 1-10 to derive overall project complexity:

markdownCopy code
## Complexity Assessment

| Dimension | Score (1-10) | Criteria |
|---|---|---|
| Data Model | /10 | Tables, relations, migration needs |
| Business Logic | /10 | Codeunits, validations, calculations |
| UI Complexity | /10 | Pages, customizations, RoleCenter |
| Integrations | /10 | External APIs, events, webhooks |
| Reporting | /10 | Reports, queries, analytics |
| Security | /10 | Permissions, data sensitivity, audit |
| Testing | /10 | Test coverage needed, edge cases |
| Migration/Upgrade | /10 | Data migration, version compatibility |

**Overall Complexity**: (sum / 80) × 10 = X/10

Object count estimation:

Pattern 3: PERT 3-Point Estimation

Use the Program Evaluation and Review Technique for each task:

markdownCopy code
## PERT Formula

E = (O + 4M + P) / 6

Where:
- O = Optimistic (best case, everything goes right)
- M = Most Likely (normal case, typical obstacles)
- P = Pessimistic (worst case, major obstacles)
- E = Expected duration

Apply per development phase:

markdownCopy code
## Phase Breakdown

### Phase 1: Analysis & Design
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Requirements analysis | 8 | 16 | 24 | 16 |
| Technical design | 8 | 12 | 20 | 13 |
| Architecture review | 4 | 8 | 12 | 8 |
| **Subtotal** | **20** | **36** | **56** | **37** |

### Phase 2: Development
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Tables & data model | X | X | X | X |
| Pages & UI | X | X | X | X |
| Business logic | X | X | X | X |
| Integrations | X | X | X | X |
| **Subtotal** | **X** | **X** | **X** | **X** |

### Phase 3: Testing & QA
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Unit tests | X | X | X | X |
| Integration tests | X | X | X | X |
| UAT support | X | X | X | X |
| Bug fixes | X | X | X | X |
| **Subtotal** | **X** | **X** | **X** | **X** |

### Phase 4: Deployment & Documentation
| Task | O (hrs) | M (hrs) | P (hrs) | E (hrs) |
|---|---|---|---|---|
| Technical documentation | X | X | X | X |
| Training materials | X | X | X | X |
| Deployment | X | X | X | X |
| Post-go-live support | X | X | X | X |
| **Subtotal** | **X** | **X** | **X** | **X** |

Pattern 4: SWOT/DAFO Analysis

Structured risk and opportunity assessment:

markdownCopy code
## SWOT Analysis

### Strengths (Internal Positive)
| ID | Strength | Impact |
|---|---|---|
| S1 | [e.g., Team has BC experience] | High/Medium/Low |

### Opportunities (External Positive)
| ID | Opportunity | Impact |
|---|---|---|
| O1 | [e.g., Standard BC API available] | High/Medium/Low |

### Weaknesses (Internal Negative)
| ID | Weakness | Impact | Mitigation |
|---|---|---|---|
| W1 | [e.g., No existing test suite] | High | Implement TDD from start |

### Threats (External Negative)
| ID | Threat | Probability | Impact | Mitigation |
|---|---|---|---|---|
| T1 | [e.g., BC version upgrade mid-project] | Medium | High | Pin BC version |

## Feasibility Score

| Criterion | Score (1-10) |
|---|---|
| Technical Feasibility | /10 |
| Resource Feasibility | /10 |
| Timeline Feasibility | /10 |
| Economic Feasibility | /10 |
| **Overall** | **/10** |

### Recommendation
- [ ] **GO** — Project viable, proceed
- [ ] **CAUTION** — Viable with conditions
- [ ] **NO-GO** — Not recommended currently

Pattern 5: Cost Summary and Payment Milestones

Consolidate estimation into a financial summary:

markdownCopy code
## Cost Summary

| Concept | Hours | Rate | Cost |
|---|---|---|---|
| Analysis & Design | X | [RATE] | [TOTAL] |
| Development | X | [RATE] | [TOTAL] |
| Testing & QA | X | [RATE] | [TOTAL] |
| Deployment & Docs | X | [RATE] | [TOTAL] |
| **Subtotal** | **X** | | **[TOTAL]** |
| Contingency ([%]%) | X | | [TOTAL] |
| Risk Buffer ([%]%) | X | | [TOTAL] |
| **TOTAL** | **X** | | **[CURRENCY] [TOTAL]** |

## Payment Milestones

| Milestone | % | Amount | Deliverable |
|---|---|---|---|
| Project Start | 20% | [X] | SOW signed, project plan |
| Design Approved | 20% | [X] | Architecture approved |
| Development Complete | 30% | [X] | Code delivered, tests pass |
| UAT Approved | 20% | [X] | User acceptance sign-off |
| Go-Live | 10% | [X] | Production deployment |

Workflow

Step 1: Intake

1. Ask mandatory intake questions (Pattern 1)
2. Confirm cost parameters — do NOT skip this
3. If reference repositories provided, analyze them for scope comparison

Step 2: Analyze

1. Score complexity dimensions (Pattern 2)
2. Count estimated objects (tables, pages, codeunits, reports)
3. Identify integration points and external dependencies
4. If existing codebase, use al_search_objects to measure current scope

Step 3: Estimate

1. Apply PERT 3-point estimation per phase (Pattern 3)
2. Use complexity-based hour ranges for object estimation
3. Apply standard ratios:
   • Testing = 30-40% of development
   • Documentation = 10-15% of total
   • Integration = typically underestimated by 50% — adjust accordingly
   • Data migration = 15-20% of total (if applicable)
   • BC version testing = 5-10% for compatibility

Step 4: Risk Assessment

1. Conduct SWOT analysis (Pattern 4)
2. Calculate feasibility score
3. Provide clear GO / CAUTION / NO-GO recommendation

Step 5: Deliver Proposal

1. Create cost summary with payment milestones (Pattern 5)
2. Define resource allocation (roles, FTE, duration)
3. Compile all sections into presales documentation
4. Store in Technical_PreSales/{project-slug}/ folder structure

PAUSE — present proposal for stakeholder review before commitment.

Estimation Guidelines

References

• PERT Estimation Technique
• BC Extension Development Guide
• AppSource Submission Requirements
• BC Licensing Model

Constraints

• This skill covers project estimation, risk analysis, and presales documentation
• Do NOT estimate without cost parameters (hourly rate, currency) — ask first
• Do NOT build, compile, or deploy code — estimation only
• Do NOT modify production source code — analysis and documentation only
• Do NOT skip the SWOT analysis for any project — risk awareness is mandatory
• Architecture design → al-architect agent | Technical specifications → al-spec.create workflow | Implementation → al-conductor agent