5.5 Issues, Risks, Assumptions, and Constraints
Key Takeaways
- An issue is a current problem affecting the project now; a risk is an uncertain future event that may or may not occur - the defining difference is timing and certainty.
- A risk that materializes becomes an issue, triggering the planned risk response or a workaround; an assumption that proves false becomes a realized risk requiring corrective action.
- Assumptions are factors taken as true without proof; they must be documented, validated early, and monitored because false assumptions are a leading source of risk.
- Constraints are limiting factors (time, cost, scope, quality, resources, regulatory) that you plan WITHIN rather than try to eliminate.
- The assumption log records both assumptions and constraints; the issue log tracks current problems with owner, priority, status, and resolution.
Four Concepts the CAPM Loves to Confuse
A recurring CAPM trap mixes up issues, risks, assumptions, and constraints. They look similar in plain English but are documented in different artifacts and managed by different processes. Master the timing and certainty of each.
| Concept | Definition | Timing / certainty | Recorded in | Example |
|---|---|---|---|---|
| Issue | A current problem actively affecting the project | Happening now, certain | Issue log | "The lead developer resigned yesterday" |
| Risk | An uncertain future event, positive or negative | May happen later, uncertain | Risk register | "The lead developer might resign" |
| Assumption | A factor taken as true without proof | Believed true now | Assumption log | "The developer will stay the whole project" |
| Constraint | A limiting factor restricting options | Fixed boundary | Assumption log | "Must finish by December 31" |
Issue vs. Risk: the Most-Tested Distinction
| Aspect | Issue | Risk |
|---|---|---|
| Timing | Has already occurred | May occur in the future |
| Certainty | Certain - it is happening | Uncertain - it may or may not |
| Response | Immediate action / workaround | Planned response strategy |
| Document | Issue log | Risk register |
| Process | Issue resolution | Risk management |
Exam Tip: A risk that occurs becomes an issue. "The vendor may deliver late" is a risk; once "the vendor delivered late," it is an issue. At that moment you execute the planned risk response if one exists, or implement a workaround if the risk was unidentified. CAPM phrasing tense ("may" vs. past/present tense) is the giveaway.
Note that risks can be positive (opportunities), but issues are always something that has already gone wrong or needs resolution now. If a question describes an opportunity that has not yet happened, it is a risk, not an issue.
Assumptions
Assumptions are factors considered true, real, or certain without proof. They are inherently dangerous: every unvalidated assumption is a latent risk. Manage them with a clear cycle:
- Identify assumptions during planning.
- Document them in the assumption log.
- Validate as early as possible (e.g., a proof of concept).
- Monitor throughout for changes.
- Respond if an assumption proves false.
Common project assumptions: key resources will be available, technology platforms will be compatible, stakeholders will show up for reviews, regulations will not change, the vendor will deliver on time, and the team has the needed skills.
Link to risk: an assumption like "the vendor's API will integrate cleanly" carries the risk that integration forces costly rework if false. The correct action is to validate early rather than discover the problem during execution. When an assumption is proven false, it has become a realized risk that requires corrective action.
Constraints
Constraints are limiting factors that restrict the team's options and shape how the project is planned and executed. Unlike issues and risks, you generally do not try to eliminate a constraint - you plan within it.
| Type | Examples |
|---|---|
| Time | Fixed deadline, regulatory milestone |
| Cost | Budget ceiling, capped funding |
| Scope | Mandatory features, regulatory inclusions |
| Quality | Industry standards, customer specs |
| Resource | Limited staff, scarce specialist skills |
| Technology | Required platform or tool |
| Regulatory | Permits, licenses, compliance |
| Organizational | Policies, governance, procedures |
Managing constraints: identify them in planning, document them in the assumption log, design the plan around them, communicate them to stakeholders, and monitor for change - a constraint can be lifted (a deadline extended) or a new one can appear.
The Two Logs
The assumption log records both assumptions and constraints, with fields for ID, type, description, owner, date identified, status (open/validated/invalidated/closed), impact if invalid, and action required.
The issue log tracks current problems, with fields for issue ID, description, impact, priority, owner, date raised, status (open/in progress/resolved/closed), and resolution. Note the risk register is separate - it holds future uncertainties, not the two logs above.
Memory hook: Assumption + Constraint = same log (assumption log). Issue = issue log. Risk = risk register. Three artifacts, four concepts.
The Six-Constraint Trade-off
Constraints rarely act alone. PMI describes competing project constraints — commonly scope, schedule, cost, quality, resources, and risk — that are interdependent: tightening one usually loosens another. If a sponsor adds scope (more features) without changing the deadline or budget, something must give — typically quality drops or risk rises. The CAPM tests this balance through scenarios: "the customer wants more features but the same end date," and the project-manager-correct response is to surface the trade-off and pursue integrated change control, not to silently absorb the extra work.
Understanding that constraints push against each other is what separates a memorized definition from real project judgment.
How the Four Concepts Flow Together
These concepts form a chain across the project life cycle:
- During planning, you record assumptions (beliefs without proof) and constraints (fixed limits) in the assumption log.
- Unvalidated assumptions and identified threats become entries in the risk register, each with a planned response.
- When a risk occurs, it converts into an issue logged in the issue log and triggers the planned response or a workaround.
- When an assumption is proven false, it likewise becomes a realized risk and may demand corrective action.
So the same underlying concern can change category over time. "The vendor will deliver on time" starts as an assumption; the chance it slips is a risk; the day it actually slips, it is an issue.
Worked Classification Drill
Classify each statement — a skill the exam tests directly:
| Statement | Classification | Why |
|---|---|---|
| "Our budget cannot exceed $250,000." | Constraint | A fixed limit to plan within |
| "A key supplier could go bankrupt next quarter." | Risk | Uncertain future event |
| "The server crashed this morning and stopped testing." | Issue | Happening now, certain |
| "We believe the client will approve the design in one review." | Assumption | Taken as true without proof |
Exam Tip: Read the verb tense and certainty words. "Might/may/could" plus a future event = risk. Present/past tense of a problem = issue. "We assume/believe/expect" = assumption. "Must/cannot/by" with a hard limit = constraint. Sorting on these cue words clears most of these questions quickly.
What is the PRIMARY difference between an issue and a risk?
During execution, a documented assumption that the vendor's API would integrate cleanly turns out to be false. This is BEST described as:
Which document records BOTH assumptions and constraints?
A statement reads: "The project must be completed by December 31 due to a regulatory deadline." How should this be classified?