How to Handle Competing Constraints in a PMP Scenario

The date cannot move. The budget is approved and there is no more. Every feature in scope was agreed with the business. Most experienced project managers have heard all three statements in the same week, often about the same project, and have learned that they cannot all stay true once something goes wrong. A supplier slips, an estimate proves optimistic or a requirement turns out to be larger than anyone understood, and one of the constraints has to give.

PMP® scenarios place candidates in exactly this position, often with plausible options that each protect a different constraint: compress the schedule, request more funding, reduce scope or take the matter to the sponsor. Each of those responses is right somewhere. The scenario is not asking which constraint matters most in general. It is asking which trade-off makes sense for this project, given what the project exists to achieve and who has the authority to decide. That is a reasoning problem rather than a rule to memorise, and it is the same problem a project manager faces when the pressure is real.

Why the most pressured constraint is not automatically the one to protect

The classic triple constraint of scope, time and cost remains a sound piece of practical wisdom. Change one and the others move, and anyone who has run a fixed-price contract or a regulated programme knows how quickly an unmanaged change in one dimension reappears as a problem in another. What the triangle does not tell you is which corner to defend when they conflict. Used on its own, it tempts a project manager to protect whichever constraint is under most pressure, or whichever stakeholder is pushing hardest, and neither is the same as protecting the project.

The Eighth Edition of the PMBOK® Guide supplies the missing reference point. Section 3.4 of The Standard for Project Management sets out Focus on Value as one of its principles, directing attention to why the project exists and whether the work remains worth doing, rather than treating the plan as the purpose. Scope, schedule and budget are the means through which value is delivered. They matter because of what they protect. A regulatory deadline protects the organisation's ability to operate, a funding cap reflects what the investment can bear, and a particular feature matters because a business outcome depends on it. PMI's 2026 PMP Examination Content Outline (ECO) reflects the same shift, drawing on PMI research that frames project success as reaching beyond schedule, budget and scope to whether the project delivered value worth its effort and cost.

This changes the question. Instead of asking which constraint is most important, a competent project manager asks what each constraint is protecting and what would be lost if it moved. Some constraints turn out to be genuinely fixed, with serious consequences attached. Others are targets that were chosen for sensible reasons at the time and have quietly hardened into commitments nobody remembers agreeing. Telling the two apart is often the most useful thing a project manager can do before any option is discussed.

Four questions to work through before choosing a trade-off

When constraints collide, it helps to work through four questions in order. This is not a PMI framework. It is a practical Omega sequence that prevents the most common mistake, which is choosing a response before the situation is understood.

The first question is what the project is for now. The business case written at initiation may still hold, or the reason for the project may have shifted. A competitor launching first can close a market window; a regulatory change can turn an optional feature into a mandatory one. A trade-off made against an outdated view of value can be executed well and still be wrong.

The second is which constraint is genuinely fixed, and what makes it so. Ask where the constraint came from and what happens if it is breached. A statutory deadline with penalties attached is a different thing from a launch date chosen to coincide with a trade event. The development approach matters here too. In predictive delivery, scope is often the most tightly defined element, sometimes contractually, so pressure tends to be absorbed through schedule, cost or formal change. In adaptive delivery, time and cost are commonly held steady for each iteration or release while scope flexes through backlog prioritisation, so the trade-off is built into the way the work is planned. A hybrid project may hold different constraints fixed in different components, which is why a single rule applied across the whole project tends to fail.

The third is what the realistic options are, and what each one costs elsewhere. Crashing the schedule spends money and can add risk when new people join late. Fast-tracking overlaps work that was sequenced for a reason. Reducing scope protects time and cost but may remove the part of the deliverable that carries the benefit. Phased or incremental delivery can protect the most valuable element while deferring the rest. Drawing on contingency reserve may be entirely appropriate if the reserve was set aside for this kind of event. None of these is right in the abstract. Each moves pressure somewhere else, and the project manager's job is to make that movement visible.

The fourth is who holds the authority to make this trade. Many adjustments sit within tolerances the project manager or team already holds, and escalating them only slows the project down. Others, such as moving a committed milestone, releasing management reserve or removing scope a sponsor approved, belong to someone else and normally pass through an agreed change process. Knowing where that line sits before the pressure arrives is what allows a project manager to act promptly without overreaching.

A repairs system six weeks short of its date

Consider a housing association replacing the system tenants use to book repairs. Go-live has been set to coincide with the expiry of the support contract for the old system. Two months out, the supplier reports that integration with the contractors' scheduling tools is running six weeks late. The sponsor's first response is that the date must hold.

A project manager reacting to the pressure has two obvious moves. One is to push the supplier to add people, which may recover little time and introduce defects where testing is hardest. The other is to go live without the integration, which meets the date and would look acceptable on a milestone report.

Working through the four questions produces a different picture. The business case rests on reducing missed repair appointments, and the contractor integration is precisely what delivers that improvement. Going live without it would move the old process onto new software, ask staff to learn a manual workaround and then relearn the process when the integration arrives, and defer the benefit the investment was approved to create. Asking what makes the date fixed reveals that the outgoing supplier will extend support month by month at a known cost. The date is therefore not a hard limit but a cost decision, and a much smaller one than it first appeared.

The realistic options are now clearer. The association could extend legacy support for two months and go live complete. It could go live on the original date for booking only, with the integration following in a second release and a tested workaround in between. Or it could fund additional supplier effort, with an honest estimate of how much time that would actually recover. Extending support spends budget beyond the project manager's authority, so the right step is to give the sponsor a short, costed comparison with a recommendation, rather than an unexplained problem or a decision already taken on their behalf. The sponsor may still choose the original date for reasons the project team cannot see. What has changed is that the choice is made knowingly, against the value the project exists to deliver.

Reading competing constraints in a PMP scenario

For a PMP candidate, the important distinction is between an answer that acts on one constraint and an answer that reasons across all of them. The ECO lists helping to ensure value-based delivery as a Process domain task, with enablers that include examining business value throughout the project and evaluating delivery options to demonstrate value. Its Business Environment domain includes setting out governance escalation paths and thresholds. The outline also states that predictive, adaptive/agile and hybrid approaches appear throughout its three domains rather than being confined to one, so a trade-off can be framed around a baseline and a change request in one question and around a backlog and a release plan in the next.

PMP preparation can sometimes leave candidates with the impression that one move is always the safe choice, whether that is protecting scope, escalating to the sponsor or never touching reserve. The ECO describes an exam built on scenario-based questions that ask candidates to apply concepts and experience to on-the-job situations, and a response that is sensible in one situation can be premature in another. The useful exam-preparation habit is to read the scenario for the facts that decide the trade-off: whether a constraint is described as fixed and why, what the project is meant to achieve, which development approach is in use, and whether the decision sits within the project manager's authority. Options that commit to a trade-off before its effect on scope, schedule, cost and value is understood tend to be weaker than options that establish that effect first. Where the scenario states that the analysis has already been done, though, repeating it is not progress. If you would like to practise that kind of reading in a structured, instructor-led setting, PMP® Exam Preparation develops the same habit across predictive, adaptive and hybrid situations.

On a real project, the best time to handle competing constraints is before they compete. Agreeing at initiation which constraint is least flexible, what tolerances the project manager holds and when a decision moves to the sponsor turns a future argument into a prepared conversation, and revisiting that agreement when the value case shifts keeps it honest. When pressure does arrive, the project manager is not choosing between being compliant and being difficult. The role is to show the people accountable for the investment what each option protects, what it gives up, and which one best serves the reason the project was started.

Andre Malowney

Interested in going further?

Competing constraints rarely arrive with a label attached, whether in the exam or on a live project. Structured preparation helps you read what a situation is telling you about value, fixed limits and decision authority, so that the trade-off you recommend is reasoned rather than reflexive.

If you want to read the Focus on Value principle in its full context, the PMBOK® Guide Eighth Edition is the source reference.

Ad · Amazon affiliate link.

References

A036: Focus on Value: The Principle Behind Better Trade-offs
A124: Cost Is Not the Same as Value
A015: When Delivering the Scope Destroys the Value
A048: Sustainability vs Schedule: When Faster Is Not Better
A109: Why Scope, Schedule and Finance Cannot Be Managed Separately

PMP and PMBOK are registered marks of the Project Management Institute, Inc.