Assumption and Constraint Mapping Working Skill

What this skill is for

Every project rests on assumptions that are treated as facts until they fail. This skill identifies, documents, and validates assumptions before they become risks. It separates assumptions from constraints: assumptions can be proven true or false, constraints are immovable. The output is an Assumptions Log and Constraint Map that help project managers decide where to invest validation effort, and where to accept limits.

When to use this skill

• A project starts and the team says "we assume the data is clean" without verifying it.
• An estimate is produced but no one has validated the assumptions behind the sizing.
• An integration project assumes an API contract is stable, but the vendor has not confirmed it.
• A post-mortem reveals that a project failed because an unstated assumption turned out to be false.
• A regulatory requirement is treated as a constraint, but it actually allows multiple compliance paths.
• A stakeholder insists a timeline is fixed, but the constraint has not been documented with source or authority.

Real work situations

SAP S/4 migration: "The data is clean"

A migration project assumes that customer master data in the source ECC system is complete, consistent, and ready to load. The assumption mapping reveals that 12 percent of customer records lack sales area data, 8 percent have duplicate account groups, and tax numbers fail validation for three country codes. The assumption "data is clean" is false. The project must either add a data cleansing phase (effort: 3 weeks) or accept that the migration will load incomplete data and trigger incompletion blocks in S/4. Without mapping this assumption, the project plans for a 2-week migration that actually requires 5 weeks of prep.

Integration project: "The API is stable"

An e-commerce integration assumes the partner API v2.1 will not change during the 3-month project. The constraint mapping reveals that the vendor's roadmap shows a v2.2 release in 6 weeks with breaking changes to the authentication model. The assumption is unvalidated and high-risk. The project must either negotiate a stability commitment with the vendor, build an adapter layer, or accept that the integration will require rework mid-project. Without mapping this, the team builds against a moving target and discovers the break during user acceptance testing.

Credit management rollout: "All customers have credit segments"

A project to implement automatic credit checks assumes that every customer in the sales area has a credit segment in UKM_BP. The mapping reveals that customers created before 2022 were never migrated to the new credit management framework, and new customers created via a legacy CRM bypass do not receive credit segments. The assumption is false for 15 percent of the active customer base. The project must either add a data remediation step or build a fallback rule that routes non-segment customers to manual review. Without mapping this, the automatic check fails silently for a subset of orders, creating a new support ticket category.

Inputs required

• Project charter or scope statement with stated and implied assumptions.
• Requirements list or Requirements Briefs with assumptions embedded in the text.
• System documentation showing current state, versions, and known limitations.
• Data quality reports or sample extracts representing the current state.
• Stakeholder interviews with people who have seen similar projects fail.
• Vendor contracts, API documentation, or integration roadmaps.
• Regulatory documents or compliance constraints with source and validity period.
• Previous project post-mortems or risk registers for the same domain.

Questions to ask

• What are we assuming about data quality, completeness, and timeliness?
• What are we assuming about system availability, performance, and version stability?
• What are we assuming about user knowledge, training, and willingness to change?
• What constraints are truly immovable: budget, timeline, regulation, technology?
• What is the source of each constraint: who said it is fixed and can they change it?
• What happens if this assumption is wrong? How much time, money, or scope is at risk?
• Which assumptions can be validated before the project starts, and which must be validated during?
• Which constraints are actually policies that could be waived with the right approval?

Working method

1. Brainstorm all assumptions. Gather everything the team, stakeholders, or documents say that starts with "we assume," "presumably," "usually," or "as far as we know." Do not filter yet.
2. Separate assumptions from constraints. An assumption can be proven true or false. A constraint is a limit that the project must work within. If it can be changed with a decision, it is not a constraint — it is a rule or a preference.
3. Classify assumptions by type. Use: data (quality, completeness, timeliness), system (availability, version, performance), process (workflow, ownership, handoffs), external (vendor, regulation, market), and organizational (skills, capacity, authority).
4. Assess impact if wrong. For each assumption, state what happens if it is false: delay, cost increase, scope reduction, quality failure, or cancellation. Rate impact as high, medium, or low.
5. Rate likelihood of being false. Use evidence, history, and data samples to estimate how likely the assumption is to fail. Rate as high, medium, or low.
6. Create a validation plan. For each high-impact or high-likelihood assumption, define: how to validate it, who will do it, by when, and what the pass/fail criteria are.
7. Map constraints. For each constraint, document: the type (technical, budget, regulatory, timeline), the source (who imposed it), the validity period, and the consequence of violating it.
8. Document in an Assumptions Log. One log per project. Include assumption, type, impact, likelihood, validation plan, owner, and status.
9. Review regularly. Revisit the log at sprint boundaries, milestones, or when new risks surface. Update statuses and add new assumptions as they emerge.

Decision rules

• If an assumption has no validation plan, it is a risk — not a managed assumption.
• If a constraint is not documented with a source and an authority, it is not a constraint — it is a preference.
• If an assumption is proven false, update the requirements, scope, and estimate before proceeding.
• If two assumptions conflict, flag the conflict and require a stakeholder decision before the project continues.
• If an assumption has high impact and high likelihood of being false, validate it before the project starts. Do not defer.
• If a constraint is a policy that could be waived, document the waiver path and the approver.
• If an assumption is validated and confirmed true, move it to the "facts" section and remove it from the risk register.

Deliverables

• Assumptions Log — One per project. Contains assumption, type, impact, likelihood, validation plan, owner, and status. See template below.
• Constraint Map — Table of constraints with type, source, validity period, and consequence of violation.
• Risk Register updates — Assumptions that are unvalidated or high-risk are added to the project risk register with mitigation plans.
• Validation Plan — Scheduled activities with owners, pass/fail criteria, and due dates for high-risk assumptions.

Templates

Assumptions Log (compact)

---
artifact: Assumptions Log
id: ASM-001
project: <project name>
date: YYYY-MM-DD
status: draft | reviewed | active
---

## Assumption


## Type


## Impact if wrong

- Impact: <description>
- Severity: high | medium | low

## Likelihood of being false

- Likelihood: high | medium | low
- Evidence: <data sample, incident history, or expert opinion>

## Validation plan
- Method: <how to validate>
- Owner: <who validates>
- Due date: <YYYY-MM-DD>
- Pass criteria: <what confirms the assumption is true>
- Fail criteria: <what confirms the assumption is false>

## Status


## Related assumptions


## Constraint link

Quality checklist

• Every assumption has a named type and a clear statement of what is assumed.
• Impact if wrong is stated in operational or financial terms, not vague language.
• Likelihood of being false is based on evidence, not gut feeling.
• Every high-impact or high-likelihood assumption has a validation plan with owner and due date.
• Constraints are separated from assumptions and documented with source and authority.
• Assumptions are reviewed at regular intervals, not just at project start.
• Validated false assumptions trigger an update to requirements, scope, or risk register before work continues.

Common mistakes

• Treating assumptions as facts. Consequence: the project plan is built on sand. When the assumption fails, the plan collapses and there is no contingency.
• Not documenting the source of constraints. Consequence: the team treats a stakeholder preference as a hard limit, or challenges a regulatory constraint without knowing the authority behind it.
• Skipping validation for "obvious" assumptions. Consequence: the most damaging failures come from assumptions that "everyone knows" are true but no one has checked.
• Confusing assumptions with risks. Consequence: assumptions are logged but never validated, while risks are managed without understanding their root cause. The team treats symptoms instead of causes.
• Failing to update the log when assumptions change. Consequence: the project continues based on outdated assumptions that were invalidated weeks ago. Decisions are made with stale information.

Weak output vs Strong output

Weak output — Generic assumptions list

A weak AI output produces a list of vague assumptions with no validation plan, no evidence, and no owner:

Assumptions:

• The data is clean.
• The system will be available.
• Users will adopt the new process.
• The vendor will deliver on time.

Validation: To be confirmed.

Owner: Project manager.

Why this is weak: "Clean" is not defined. "Available" has no threshold. No evidence is cited. No validation method is stated. No due date. No impact assessment. A project manager cannot prioritize validation effort, and a stakeholder cannot assess risk from this list.

Strong output — Assumptions Log entry

A strong AI output produces a copy-paste-ready artifact with specific evidence, validation plans, and clear ownership:

---
artifact: Assumptions Log
id: ASM-MIG-2026-003
project: SAP ECC to S/4 Customer Master Migration
date: 2026-06-12
status: active
---

## Assumption
All customer master records in the source ECC system contain complete sales area data (sales org, distribution channel, division) required for S/4 order creation.

## Type
data

## Impact if wrong
- Impact: Incomplete customer records will trigger incompletion blocks in S/4 at order creation (VA01), generating SD support tickets and delaying revenue recognition.
- Severity: high

## Likelihood of being false
- Likelihood: high
- Evidence: Sample of 1,000 customer records from KNA1/KNVV shows 12% lack required sales area data. Historical AMS data shows 8% of blocked orders are due to missing customer master fields.

## Validation plan
- Method: Run automated completeness check on full KNVV extract for all active sales orgs. Flag records missing VSTEL, INCO1, or ZTERM.
- Owner: Data migration lead, Peter Schmidt
- Due date: 2026-06-20
- Pass criteria: < 2% of active customer records have missing sales area data.
- Fail criteria: > 5% of active customer records have missing sales area data.

## Status
unvalidated

## Related assumptions
- ASM-MIG-2026-004: Tax numbers in source system pass country-specific validation.
- ASM-MIG-2026-005: Customer-to-business partner mapping is complete for all accounts.

## Constraint link
- None. This is an assumption, not a constraint.

Why this is strong: It states the assumption with specific fields (VSTEL, INCO1, ZTERM). It cites evidence (sample of 1,000 records, historical AMS data). It assesses impact in operational terms (support tickets, revenue delay). It defines a validation method with a pass/fail threshold, a named owner, and a due date. A project manager can prioritize this, a data team can execute it, and a steering committee can understand the risk.

Agent instructions

AI Prompt Pattern

"You are a project risk analyst. You receive a project scope, requirements, and system context. Produce an Assumptions Log and Constraint Map. For each assumption: state the specific assumption, classify the type (data, system, process, external, organizational), assess impact if wrong with evidence, rate likelihood of being false, and define a validation plan with owner, method, due date, and pass/fail criteria. For each constraint: state the limit, the source, the authority, and the consequence of violation. Do not use vague qualifiers like 'clean' or 'fast' without defining thresholds. Flag assumptions that lack evidence as high-risk."

When using this skill, an AI agent must:

• Gather all stated and implied assumptions before analysis. Read requirements, project charters, and stakeholder statements for hidden assumptions.
• Separate assumptions from constraints. An assumption can be validated. A constraint is a fixed limit with a source and authority.
• Assess impact and likelihood with evidence. Use data samples, incident history, or expert opinion. Do not guess.
• Define validation plans for all high-impact or high-likelihood assumptions. Include method, owner, due date, and pass/fail criteria.
• Produce one Assumptions Log per project. Link related assumptions. Update statuses as validation completes.
• Do not treat stakeholder preferences as constraints. If a limit can be changed with a decision, it is a rule, not a constraint.
• Flag validated-false assumptions as project risks. Update requirements, scope, or estimates before continuing.
• Link to Atlas diagnostics when assumptions relate to SAP processes. For example, data migration assumptions should reference SAP Master Data Quality.

Related skills

• Requirements Elicitation Working Skill
• Gap Analysis Working Skill
• Business Rules Discovery Working Skill

Related Atlas pages

• SAP Process Audit — Diagnostic context for validating process assumptions.
• Delivery Billing Block Order-to-Cash Delays — Scenario showing assumption failures in O2C.

Verification status and limitations

This skill is a public working interpretation of assumption and constraint management practices. It is not official PMBOK, BABOK, or risk management framework documentation. It focuses on practical enterprise and SAP contexts where data quality and system stability assumptions are common failure points.

Known limitations: the skill requires access to data samples, system documentation, and stakeholder expertise to validate assumptions. In environments with poor documentation or no historical data, likelihood assessment is speculative. The skill does not cover formal quantitative risk modeling or Monte Carlo simulation.