Assumptions and constraints: what you're taking as given, and what limits you

By the end, you can

• Distinguish an assumption from a constraint in a project brief, and explain why confusing the two is a costly mistake (PM-1).
• Explain why an AI-drafted list of assumptions or constraints must be checked against the sponsor's actual situation before it's treated as settled (PM-1).
• Classify sample project-brief items as assumptions needing verification or genuine constraints (PM-1).

Before you start

This is Module 1, Lesson 2 of the AI-Powered Project Management course. It builds on Lesson 1's goal-and-scope work and assumes the same starting point: an informal project ask, plus using an AI assistant for drafting text. It does not require project-management certification or a specific tool.

An assumption is a bet; a constraint is a wall

A goal and a scope tell you what the project is aiming at and what work it covers. Two more elements tell you what you're taking as given, and where the hard edges are: assumptions and constraints. APM's project management glossary defines an assumption as "statements that will be taken for granted as fact and upon which the project business case will be justified." An assumption is a bet — something the plan is built on that has not actually been confirmed. If it turns out to be wrong, the plan built on top of it is at risk.

A constraint is different in kind. The same glossary defines constraints as "things that should be considered as fixed or that must happen," adding that they are "restrictions that will affect the project." A constraint is not a bet — it is a wall. Budget, a hard deadline, an existing platform you must use, a rule you must comply with: these don't carry a probability of being wrong, they simply apply. Confusing the two is a common and costly mistake: treating a constraint as negotiable wastes time revisiting a fixed limit, while treating an assumption as a constraint means never checking something that might not actually be true.

Why AI-surfaced assumptions still need a human check

Ask an AI assistant to list the assumptions behind a project idea, and it will readily produce a plausible-looking list — "assumes stakeholders are available for review," "assumes the current system can be extended," and so on. That list can be genuinely useful as a starting prompt for what to check. It is not the same as a verified list.

The Open Worldwide Application Security Project's (OWASP) generative-AI security guidance names this directly: "overreliance occurs when users place excessive trust in LLM-generated content, failing to verify its accuracy." An AI assistant has no access to your organisation's actual systems, budget or politics — it can only infer plausible assumptions from what you typed. The US National Institute of Standards and Technology's (NIST) AI Risk Management Framework is consistent with this limit: it describes an AI system as something that "can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions" — nothing in that description includes the system confirming whether its own output is actually true for your specific situation. Whether "the current system can be extended" is a fact only your organisation can check.

The same discipline applies once an assumption turns out to be wrong. If a listed assumption fails and the project needs a new plan around it — a workaround, a schedule change, a bigger budget ask — that response is itself a high-impact decision, not a drafting task. OWASP's guidance on excessive agency is direct about who should make that kind of call: "utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." The fix belongs with a named person, not with whichever tool suggested it first.

A worked example: a bakery chain's online-ordering rollout

A regional bakery chain with twelve stores is rolling out online ordering. The project lead asks an AI assistant to draft a first-pass list of assumptions and constraints from her description of the rollout.

The assistant proposes assumptions: "assumes all twelve stores have reliable internet," "assumes staff can be trained within two weeks," "assumes customers will adopt online ordering at a similar rate to comparable retailers." It proposes constraints: "must launch before the December peak season," "must integrate with the existing point-of-sale system," "budget is fixed at the amount stated."

The project lead checks each one. Two stores, she knows, have unreliable rural broadband — that assumption is false as written and needs a workaround, not just a note. The two-week training assumption she keeps, but flags as unverified until she talks to the store managers. The "before December" item and the point-of-sale integration are genuine constraints — both are fixed, and she confirms the budget figure with finance rather than trusting the number she'd mentioned in passing. The customer-adoption assumption she can't verify at all yet; she marks it as an open assumption to monitor once the rollout starts, rather than pretending it's settled.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines "assumptions" as statements taken for granted as fact, and "constraints" as fixed restrictions that will affect the project.
2. LLM09:2025 Misinformation — OWASP Gen AI Security Project. Defines overreliance as placing excessive trust in AI-generated content without verifying its accuracy.
3. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a verifier of whether those outputs are actually true.
4. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.