Assumptions and Exclusions in an Estimate: 40 IT Examples

In plain words

An assumption is something you rely on when you estimate, such as “the client will provide test data by week 3”. An exclusion is something the price does not cover, such as “data migration”. Writing both down, with an owner, stops arguments later about what was included.

Who this helps: Presales consultants, project managers and account managers who write estimates and proposals.

Questions this guide answers:

• What are assumptions and exclusions in an estimate?
• How do you write good project assumptions?
• Examples of exclusions in a proposal

What are assumptions and exclusions, and how do you use these 40 examples?

Select only conditions that fit the actual project. Label each one by type: a scope boundary (what is in or out), a dependency (what you need from someone else) or an estimating assumption (what you believe when sizing the work). Some items people call assumptions are really scope decisions and belong in the scope statement. Reconcile them with deliverables and the client’s requirements so an exclusion does not contradict a promised outcome. Attach an owner, validation point and impact to important assumptions. A long list of vague qualifications can make an estimate less usable than a short list of clear ones.

The numbered examples are deliberately divided between assumptions and exclusions. Their commercial or contractual wording needs the normal approval process. An estimate should explain its basis; it should not hide an impossible delivery promise behind a generic disclaimer.

An assumption is a condition treated as true for estimating. An exclusion is work outside the defined scope. A risk is uncertainty about an outcome that could affect the plan. The statements are connected but not interchangeable: assuming clean data can create a cleanup risk; excluding cleanup does not prove clean data exists.

Make high-impact wording testable. “Client provides timely feedback” is weak because nobody can verify what timely means. “The named product owner returns consolidated feedback within the agreed review window” identifies an actor, deliverable and timing condition. The estimate should also say what decision occurs if that condition fails.

Scope and solution boundaries: examples 1–8

• 1. Assumption: delivery covers one browser-based application.
• 2. Assumption: the agreed backlog is the scope version attached to the estimate.
• 3. Assumption: the existing design system can be reused without redesign.
• 4. Assumption: two user roles share the same approved workflow.
• 5. Exclusion: native mobile applications are outside this phase.
• 6. Exclusion: additional languages and translation are not included.
• 7. Exclusion: new reporting requests beyond the listed reports are not included.
• 8. Exclusion: replacement of the client’s upstream platform is outside scope.

Use the scope group to define the deliverable family and phase. A browser application, native mobile app and translated application can have different work packages even when they serve the same business goal. Check each exclusion against the buyer's stated outcome; excluding something essential creates an unresolved scope conflict rather than a complete estimate.

For reuse assumptions, name the asset and verify suitability. An existing design system saves effort only if the team can access it, its components fit the workflows and the client accepts it. Record any necessary adaptation as base work instead of assuming reuse eliminates all design effort.

Data and integrations: examples 9–16

• 9. Assumption: the client supplies documented API access before integration starts.
• 10. Assumption: representative test records are available by the agreed date.
• 11. Assumption: source records contain stable identifiers.
• 12. Assumption: integration covers one specified environment and endpoint set.
• 13. Exclusion: manual correction of historical source records is not included.
• 14. Exclusion: third-party API subscription fees are outside the delivery fee.
• 15. Exclusion: redesign of an undocumented legacy interface is not included.
• 16. Exclusion: bulk migration beyond the listed record types is outside scope.

Integration assumptions need evidence about access, documentation and representative records. A working API endpoint can still lack the fields, volumes or permissions needed for the business process. Validate a sample transaction and identify the client owner who can resolve mapping questions.

Specify the difference between data preparation and migration. If the client supplies clean records, define the expected format and checks. If the supplier excludes cleanup, explain what happens when records fail those checks. The estimate should support a decision about who performs the additional work rather than leave the issue for acceptance.

Client responsibilities: examples 17–24

• 17. Assumption: a named product owner can prioritize the backlog.
• 18. Assumption: the client provides consolidated review feedback.
• 19. Assumption: stakeholder interviews occur within the discovery time box.
• 20. Assumption: access and security approvals follow the agreed calendar.
• 21. Exclusion: writing all client content is not included.
• 22. Exclusion: internal organizational change management is outside scope.
• 23. Exclusion: training every end user is not included beyond the stated sessions.
• 24. Exclusion: support for unrelated client systems is outside this engagement.

Client responsibilities can constrain calendar duration even when supplier effort remains stable. Workshops require available stakeholders; consolidated feedback requires a decision process. Review whether the client actually has the people and authority assumed.

Give material dependencies a validation point before the affected work starts. If access is needed in week 2, waiting until release to discuss the assumption is too late. Record the scheduling consequence and follow the agreed change process where the condition changes.

Quality and delivery: examples 25–32

• 25. Assumption: acceptance uses the named scenarios and review procedure.
• 26. Assumption: deployment uses the existing approved hosting environment.
• 27. Assumption: stated availability requirements match the proposed architecture.
• 28. Assumption: handover includes one documented walkthrough.
• 29. Exclusion: external penetration testing fees are not included.
• 30. Exclusion: formal certification activities are outside the listed deliverables.
• 31. Exclusion: 24-hour operational support is not included in project delivery.
• 32. Exclusion: extra release rehearsals beyond the stated plan require review.

Translate broad quality language into acceptance evidence. “Production ready” can mean different things to sales, engineering and the client. Name the test families, operational handover and release checks included, while identifying any separate assurance requirements.

An exclusion should not silently cancel an accepted requirement. If the client needs a formal security assessment, excluding that assessment requires a visible scope decision. Estimate the supplier's support for any client-led assessment where it still consumes project effort.

Commercial and cost boundaries: examples 33–40

• 33. Assumption: the fee uses the stated currency and exchange-rate basis.
• 34. Assumption: labor costs use the approved planning-rate version.
• 35. Assumption: travel is limited to the listed visits.
• 36. Assumption: client-requested changes follow the agreed approval process.
• 37. Exclusion: applicable taxes are excluded where explicitly stated.
• 38. Exclusion: hardware procurement is outside the service fee.
• 39. Exclusion: hosting charges after handover are not included.
• 40. Exclusion: optional future phases are outside the current price.

Keep currency, rates, expense treatment and commercial assumptions consistent across the estimate and proposal. A travel exclusion in one attachment does not resolve an email promising all expenses included. Use one scope version and reconcile revisions before approval.

Separate finance policy from client responsibility. Planning-rate versions and overhead boundaries support internal economics; client access and approval windows support delivery. Both belong in the estimating basis, but they require different owners and validation actions.

How do you turn a list into a working assumptions register?

Keep the assumption identifier with the affected work package. When it changes, update effort, cost and schedule together. At commercial approval, review the unresolved items with the people who own the consequence. During delivery, use the same register to distinguish a changed condition from a task that was simply missed.

An exclusion must also be understandable to the client. “Migration excluded” is weak if the promised go-live requires migrating records. Explain who will perform the work and what dependencies remain. Do not use exclusions to conceal essential work that nobody has planned.

Give each important condition a stable identifier and preserve its history. When an assumption is confirmed, retain the evidence. When it changes, record the affected package, hours and approval. This helps explain a later price revision without rewriting the original basis.

Start with the few conditions that materially affect feasibility, cost or timing. A long register of minor assumptions can hide the critical unresolved API or acceptance dependency. The ROM versus definitive estimate guide explains how evidence maturity should influence the commitment.

Real example: a presales consultant turns a vague assumption into a useful one

An illustrative story with invented figures, to show how the idea works in a real office.

Kofi, a presales consultant, writes: “Client will cooperate.” His manager asks how anyone could check that.

He rewrites it: “The client provides a named contact who answers questions within two working days. If answers take longer, the schedule moves day for day and any extra hours are raised as a change request.” The condition is specific, it has an owner and a consequence.

Three weeks later the client contact is away for a week. Kofi’s project manager points to the assumption, and the delay is agreed without argument.

When do you write assumptions and exclusions, and who owns them?

Register, contract clauses or risk log: where should they live?

There are several ways to record the boundaries of an estimate.

Use a register for the estimate, convert the ones that matter into contract wording, and keep risks and assumptions linked so a failed assumption triggers a risk review.

Assumptions and exclusions: frequently asked questions

How do you record assumptions in Managed Margin?

Use the strategy's assumptions to identify the scope version and decision-critical conditions behind its stage and role allocations. For example, on a data-migration estimate, record whether the client supplies representative records, who validates the mapping and which acceptance scenarios the estimate includes. Keep the full working register in your project documentation when it needs more detail than a strategy note.

When an assumption fails, revise the affected draft scenario before commitment, or use the agreed delivery change process after authorization. A failed clean-data assumption may add analyst and QA effort; the calculation should show those hours and their cost. The application preserves the economic plan, while the named owners and validation evidence make its assumptions clear and usable.

Explore the pricing and estimation workflow or review the delivery margin workflow.

Continue the sequence: guides to read next

• ROM Quote and Estimate Email Examples: 6 Templates: stating assumptions in a ROM email
• From ROM to Fixed Price: What Evidence You Need First: what evidence you need before a range becomes a fixed price
• Project Baseline Handoff: From Sales to Delivery: carrying the pricing baseline from sales into delivery

Sources and methodology

The worked figures are original educational illustrations. The linked references provide background for the estimating and management concepts; they do not establish the example rates or guarantee the outcomes. Product instructions describe the current implementation and are separate from methods the reader performs outside the application.

The examples, templates and calculations are original editorial illustrations, not market benchmarks or customer results. Monetary amounts are in USD, exclude tax unless stated, and use the cost boundaries defined in the article. Validate assumptions against your own delivery history before quoting.

Further background: US DOE Cost Estimate Development Handbook. The worked arithmetic and scenarios above are original; this reference provides context and is not a source for market rates or the stated example amounts.

The application walkthrough was checked against the current stage, pricing, cost-rule and delivery calculation code on 13 October 2026. Forecasts describe recorded actuals plus the remaining plan, not predicted customer outcomes.