Assumptions, Constraints, and Dependencies: Getting Them Right
Ask ten project managers to define an assumption and you will get ten slightly different answers. Ask the same group about constraints and dependencies and the confusion deepens. Yet these three concepts sit at the heart of every credible project plan, and confusing them leads to plans that look rigorous on paper but collapse under real-world pressure.
What Is an Assumption?
An assumption is something you believe to be true for planning purposes but have not confirmed. It is a deliberate act of filling a gap in your knowledge so that planning can proceed. Examples include: the client will provide a subject-matter expert for three hours per week; the regulatory environment will not change during the project; the existing IT infrastructure is capable of supporting the new system. None of these may prove correct, but without stating them you cannot build a coherent schedule or budget.
The critical discipline is not just identifying assumptions but testing them. For each assumption, ask: if this turns out to be wrong, what happens to the project? Assumptions that, if invalidated, would threaten scope, schedule, budget, or quality are high-risk assumptions and must be actively monitored and tested as early as possible. Low-risk assumptions can be noted and periodically reviewed.
What Is a Constraint?
A constraint is a limitation the project must operate within — a boundary that is given, not chosen. The budget ceiling is a constraint. The regulatory deadline is a constraint. The fact that the project must use an existing vendor because of a master services agreement is a constraint. Unlike assumptions, constraints are not things you are guessing at; they are facts about the environment the project must accommodate.
Constraints deserve their own log because they change. A budget that was fixed at project initiation may be revised when a sponsor prioritises a different initiative. A technology constraint may dissolve when the organisation upgrades its platform. Tracking constraints means you notice when the project's operating conditions have shifted, and you can revisit decisions that were made on the basis of the old reality.
What Is a Dependency?
A dependency is a relationship — specifically, a relationship where one thing must happen before another can proceed. Dependencies exist at two levels. Internal dependencies are between activities within your own project: the requirements document must be approved before design can begin. External dependencies are between your project and something outside it: your vendor must deliver the hardware before you can begin integration testing; another project must complete its data migration before yours can go live.
External dependencies are where projects most often get into trouble. They represent schedule risk that sits outside the project manager's direct control. The discipline here is to surface them early, name the owner of each dependency, agree on a date by which the dependency must be resolved, and escalate promptly when that date is at risk.
Documenting All Three
The standard approach uses three distinct logs:
Assumption register: records each assumption, its potential impact if wrong, the confidence level assigned to it, and the action being taken to validate or monitor it.
Constraint log: records each constraint, its source (contractual, regulatory, organisational), and any known flexibility or conditions under which it might change.
Dependency log: records each dependency (internal or external), the predecessor item, the successor item, the owner, the required-by date, and current status.
The Risk Connection
All three feed directly into risk management. Unvalidated assumptions become risk triggers — events that, if they occur, will cause plan deviation. Constraints that change create scope and budget risk. Unresolved dependencies drive schedule risk. Maintaining current logs of assumptions, constraints, and dependencies is therefore not an administrative exercise; it is the foundation of proactive risk management.
A practical review cadence: check the assumption register at every key milestone to determine which assumptions can now be confirmed or invalidated. Review the constraint log whenever there is a significant change in the project environment. Review the dependency log weekly in execution, or at every sprint review if you are working in an agile context. Keep these documents short and useful — a one-page register that the team actually reads is worth far more than a comprehensive document that sits unread.
XNM Consulting helps organisations build project management disciplines that stick — including practical tools for assumption testing, constraint tracking, and dependency management. Learn more about our approach to .