estimation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited estimation (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill enforces decomposition-based, range-driven estimation for SAP work so that no single number, unsupported assumption, or unrisked commitment ever leaves this engagement.
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| Give a single number | "The user asked 'how long will this take?' — they want one answer" | Single numbers become commitments. The PM puts them in the Gantt chart. The client uses them in contracts. Ranges force an honest conversation about uncertainty. | Iron Law 1: Always three-point. If the user insists on one number, give the realistic estimate with explicit written caveats. |
| Skip work package decomposition | "The scope is clear enough for a top-down estimate" | Top-down estimates miss hidden complexity: legacy data cleanup, authorization design, integration mapping, transport management. Each of these can double a phase estimate. | Iron Law 2: WBS first. Every process area gets its own row before any numbers are written. |
| Skip complexity factors | "The work is straightforward" | 'Straightforward' SAP work has a 40-60% overrun rate when complexity factors are not applied. Customization depth, team experience, and integration count multiply base effort materially. | Checklist Step 3: Apply all five complexity factors to every work package. If all factors score 1.0×, provide written justification. |
| Merge testing into development | "Testing is implicit in the development estimate" | Testing is 30–40% of SAP delivery. When it is hidden, it gets cut under time pressure. Then it happens anyway — in production. | Iron Law 5: Testing is a mandatory separate line item in every work package. |
| Omit training and cutover effort | "We're estimating development, not the full project" | Training, cutover prep, and hypercare are 20–30% of total project cost. Omitting them produces estimates that look lean until Realize when the full picture emerges and the budget is already committed. | Checklist Step 2: Six effort categories are mandatory: Build, Test, Data Migration, Integration, Training, Project Management. |
| Skip risk identification | "We can handle risks as they come" | Unidentified risks become 'surprises' that justify emergency change requests. Clients lose trust. Budgets collapse. Identify them now and quantify their day-impact. | Checklist Step 5: Minimum 3 estimation risks with quantified day-impact and a named contingency allocation. |
| Apply calendar days = working days | "The user asked for a timeline, so I'll use working days" | SAP consultants attend workshops, prepare for calls, review designs, handle environment issues, and wait on approvals. Utilization on a project is typically 60–70% of calendar days. | Template: calendar-day conversion uses a 0.65 utilization factor by default. State the factor explicitly. |
| Anchor to a previous project | "We estimated similar work at 40 days on the last project" | Different client, different legacy landscape, different team, different SAP release. Analogical estimates without documented similarity criteria are guesses with false authority. | Red Flag trigger: "Based on similar projects..." → State the similarity criteria explicitly or do not use the analogy. |
Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:
<HARD-GATE> DO NOT produce an effort estimate until ALL of the following exist:
</HARD-GATE>
Before producing any numbers, confirm what is being estimated:
Evidence: Scope statement with all five items confirmed. Gate: All five scope parameters are defined before any decomposition begins.
Decompose scope into estimable work packages:
Mandatory WBS categories:
| Category | Examples |
|---|---|
| Build | Configuration, development (ABAP, CDS, RAP, BTP), customization |
| Test | Unit test, integration test, UAT, regression (never merge with Build) |
| Data Migration | Extraction, transformation, load, validation, legacy decommission |
| Integration | Interface design, development, testing, monitoring setup |
| Training | Materials, delivery, train-the-trainer, e-learning |
| Project Management | Workshops, status reporting, governance, cutover coordination |
For each work package, capture: Name, Module/Workstream, Owner Role, Dependencies.
Evidence: WBS table with at least one row per SAP module in scope and all six categories represented. Gate: No work package is labelled "Miscellaneous" or "TBD." Every row has a named owner role.
Adjust base effort using the five SAP-specific complexity multipliers:
| Complexity Factor | Low (0.8×) | Medium (1.0×) | High (1.3×) | Very High (1.6×) |
|---|---|---|---|---|
| Customization Ratio | Standard config only | Minor config changes | Moderate custom dev | Heavy Z-code / BAdIs |
| Data Migration Volume | < 10K records, clean data | 10K–100K records | 100K–1M records, dirty data | > 1M records, complex transformation |
| Integration Count | 0–2 interfaces | 3–5 interfaces | 6–10 interfaces | 11+ interfaces, real-time |
| Team Experience | Team has done this 5+ times | Team has done this 2–4 times | First time for most team members | First SAP project for team |
| Requirements Clarity | Fully documented, signed off | Mostly documented, minor gaps | High-level only, key gaps | Undefined, frequent change |
Composite Score Calculation:
Evidence: Complexity factor table with a score for every factor for every major work package. Gate: No work package carries a complexity score of 1.0× without a written justification.
For every work package, produce three values:
| Value | Definition | Typical Relationship |
|---|---|---|
| Optimistic (O) | Everything goes right: full requirements, experienced team, no surprises | 60–70% of Realistic |
| Realistic (R) | Normal conditions: some ambiguity, some rework, some waiting | Your complexity-adjusted estimate |
| Pessimistic (P) | Known risks materialize: scope grows, team issues, environment delays | 140–160% of Realistic |
PERT Formula for Expected Value:
Expected = (O + 4R + P) / 6
Range to present: Present as O–P days with the PERT Expected value as the "most likely" scenario.
Evidence: Three-point table with O, R, P, and PERT Expected for every work package. Gate: Pessimistic value for no work package is less than 130% of the Realistic value.
List factors that could invalidate the estimate:
Each risk must include:
Evidence: Risk table with minimum 3 SAP-specific estimation risks, each with a day-impact figure. Gate: Total contingency percentage is explicitly stated (minimum 10%, maximum 30% unless justified).
Translate effort days to calendar dates:
Formula: Calendar Days = (Effort Days / Team Size) / Utilization Factor
Evidence: Timeline table mapping work packages to SAP Activate phases with start/end dates. Gate: The utilization factor used is stated explicitly.
Assemble all outputs into the template below.
Evidence: Complete effort estimate document with all sections populated. Gate: All Hard Gate conditions are confirmed before proceeding.
# SAP Effort Estimate
## Estimate Header
- **Project / Scope:**
- **SAP Product / Release:**
- **Estimation Date:**
- **Prepared By:**
- **Estimation Method:** Three-Point / PERT
- **Validity Period:** [Date after which the estimate requires re-baselining]
## Estimating Assumptions
[List every assumption. If an assumption proves wrong, the estimate is invalid.]
1.
2.
3.
## Work Breakdown Structure with Effort
| Work Package | Module / Workstream | Category | Owner Role | Optimistic (d) | Realistic (d) | Pessimistic (d) | PERT Expected (d) | Complexity Score |
|-------------|--------------------|---------|-----------:|---------------:|--------------:|----------------:|------------------:|-----------------|
| [Name] | [Module] | Build | [Role] | [O] | [R] | [P] | [(O+4R+P)/6] | [x.x×] |
**Category Subtotals**
| Category | PERT Expected Days |
|----------|--------------------|
| Build | |
| Test | |
| Data Migration | |
| Integration | |
| Training | |
| Project Management | |
| **Subtotal** | |
| Risk Contingency ([X]%) | |
| **Total Estimate** | |
## Complexity Factor Assessment
| Work Package | Customization | Data Migration | Integration Count | Team Experience | Requirements Clarity | Composite |
|-------------|:-------------:|:--------------:|:-----------------:|:---------------:|:--------------------:|:---------:|
## Estimation Risks
| Risk | Probability | Day Impact | Contingency Allocation |
|------|:-----------:|----------:|----------------------|
| | | | |
**Total Contingency:** [X]% = [Y] days
## Timeline Summary
| SAP Activate Phase | Work Packages | Effort (PERT) | Calendar Days | Start | End |
|-------------------|--------------|-------------:|-------------:|-------|-----|
| Prepare | | | | | |
| Explore | | | | | |
| Realize | | | | | |
| Deploy | | | | | |
| Run (Hypercare) | | | | | |
**Utilization Factor Applied:** [0.65 / other — state justification]
**Team Size Assumed:** [number of consultants]
## Estimate Range Summary
| Scenario | Total Days | Calendar Duration | Interpretation |
|----------|----------:|------------------:|---------------|
| Optimistic | | | All assumptions hold, no risks materialize |
| PERT Expected | | | Normal conditions, standard risks |
| Pessimistic | | | Key risks materialize, scope ambiguity increases |
## Open Items That Will Change This Estimate
| Item | Impact if Unresolved | Owner | Due Date |
|------|---------------------|-------|----------|This skill is complete ONLY when ALL of the following are true:
Evidence required: Completed effort estimate document with all sections populated and no placeholder values in numeric cells.
If any verification item is not met, the skill is NOT complete. Do not claim completion.
After completing this skill, invoke one of:
solution-architecture — When the estimate is part of a solution design that needs architecture validationfit-gap-analysis — When the estimate is being built ahead of Explore phase and gaps are not yet quantifiedConditions for handoff: The effort estimate is complete and the project is moving from Prepare into Explore, or from Explore into Realize where estimates need to be refined against confirmed gaps.
project-kickoff — The project charter (from kickoff) defines the scope input for this estimatefit-gap-analysis — Gap resolution strategies (configure / extend / custom) drive effort by gapbrainstorming — T-shirt sizing from brainstorming feeds into the WBS as preliminary estimatessolution-architecture — Architecture decisions (BTP extensions, integration patterns) affect complexity factorssap-estimator agent — Dispatch for deep effort decomposition when scope spans 5+ modules~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.