2.1.2. Approaches, Constraints and Ethics

This subsection covers the rest of Task 1's enablers: the vocabulary for logging problems (issues, risks, assumptions, constraints), applying the PMI Code of Ethics, and revisiting "vehicle for change" with more depth than Phase 1 had room for.

💡 First Principle: Issues, risks, assumptions, and constraints all sound like "things that could go wrong," but they answer four different questions — and a project team logs and manages each one differently. Confusing them means solving the wrong problem.

⚠️ Exam Trap: A risk that has occurred is not "a bigger risk" — it becomes an issue. If a scenario says something already happened, the correct term is issue, and the correct action is resolution, not risk-response planning.

Applying the PMI Code of Ethics. The Code of Ethics and Professional Conduct rests on four values: responsibility, respect, fairness, and honesty. Scenario questions rarely mention "ethics" by name — instead they describe a small, ordinary decision (disclosing that you have a personal relationship with a vendor being evaluated, giving an accurate status update when the honest number looks bad, crediting a team member's idea correctly) and expect you to identify the ethical action.

⚠️ Exam Trap: Don't wait for a scenario to look like misconduct before applying the Code of Ethics. Most CAPM ethics questions describe routine situations — an honest status report, a disclosed conflict of interest — not fraud or legal violations. If an answer choice involves hiding, omitting, or downplaying something relevant, that's usually the wrong choice regardless of how minor it seems.

Projects as a vehicle for change, revisited. Phase 1 introduced this idea briefly; here's the fuller version the exam expects. A project should always trace back to an intended organizational benefit — cost savings, new capability, risk reduction, market opportunity. "Explain how a project can be a vehicle for change" means being able to state that benefit in plain language, not just describe the deliverable. A scenario that only describes outputs ("the team built a new reporting dashboard") without a benefit ("...so leadership could cut monthly close time from 5 days to 1") is describing an incomplete, partial picture of why the project genuinely exists in the first place.

Why an unvalidated assumption is a live risk, not a settled fact. An assumption logged early in a project ("the vendor's estimate is accurate") often gets treated as background noise once it's written down, but it's really an unconfirmed belief the plan is quietly relying on. If that belief turns out to be wrong, the assumption converts directly into a risk or an issue — the exam tests whether you recognize assumptions as something to periodically revisit and validate, not a category you log once and then forget.

When honesty is inconvenient, not just when it's dramatic. The scenarios that trip up candidates most aren't the obvious fraud cases — they're the ones where the honest answer is simply awkward: reporting a schedule slip nobody wants to hear about, or disclosing a minor conflict of interest that probably wouldn't have changed anyone's decision anyway. The Code of Ethics doesn't have a minimum-severity threshold below which disclosure becomes optional; the test is whether the information is relevant, not whether withholding it would cause obvious harm.

Constraints trade against each other, not in isolation. When a scenario tightens one constraint — the deadline moves up, the budget is cut — expect the exam to ask what gives elsewhere. The associate-level answer is rarely "work faster"; it's that scope, cost, schedule, or quality must be renegotiated, and the project manager's job is to make that trade visible to the sponsor before it happens silently.