Skill estimation
Skill javiarmesto/ALDC-AL-Development-Collection/skills/skill-estimation
AL project estimation for Business Central. Use when estimating development effort, creating cost models, SWOT analysis, or structuring project proposals.From its SKILL.md
npx -y skills add javiarmesto/ALDC-AL-Development-Collection --skill skill-estimationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
9.1 KB, as published. Nobody here has run it
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:
## 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:
## 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:
| Object Type | Low Complexity | Medium | High |
|---|---|---|---|
| Table | 2-4 hrs | 4-8 hrs | 8-16 hrs |
| Page (Card/List) | 2-4 hrs | 4-8 hrs | 8-16 hrs |
| Page (Document) | 4-8 hrs | 8-16 hrs | 16-32 hrs |
| Codeunit | 2-8 hrs | 8-16 hrs | 16-40 hrs |
| Report | 4-8 hrs | 8-16 hrs | 16-32 hrs |
| Integration | 8-16 hrs | 16-32 hrs | 32-80 hrs |
Pattern 3: PERT 3-Point Estimation
Use the Program Evaluation and Review Technique for each task:
## 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:
## 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:
## 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:
## 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
- Ask mandatory intake questions (Pattern 1)
- Confirm cost parameters — do NOT skip this
- If reference repositories provided, analyze them for scope comparison
Step 2: Analyze
- Score complexity dimensions (Pattern 2)
- Count estimated objects (tables, pages, codeunits, reports)
- Identify integration points and external dependencies
- If existing codebase, use
al_search_objectsto measure current scope
Step 3: Estimate
- Apply PERT 3-point estimation per phase (Pattern 3)
- Use complexity-based hour ranges for object estimation
- 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
- Conduct SWOT analysis (Pattern 4)
- Calculate feasibility score
- Provide clear GO / CAUTION / NO-GO recommendation
Step 5: Deliver Proposal
- Create cost summary with payment milestones (Pattern 5)
- Define resource allocation (roles, FTE, duration)
- Compile all sections into presales documentation
- Store in
Technical_PreSales/{project-slug}/folder structure
PAUSE — present proposal for stakeholder review before commitment.
Estimation Guidelines
| Rule | Guideline |
|---|---|
| Testing effort | Always 30-40% of development hours |
| Documentation | Never skip — 10-15% of total hours |
| Integration complexity | Usually underestimated — add 50% buffer |
| Data migration | Add if mentioned — 15-20% of total |
| BC version testing | Add 5-10% for compatibility verification |
| Training | 8-16 hours per user group |
| Contingency | 15-20% standard, 25-30% for high uncertainty |
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