2610: The Shelf You Put It On

I've been building a slide for a seminar I'm putting together, and one small piece of it kept stopping me mid-edit. It's a short segment on risk, and it splits into three categories: opportunity, constraint, and obstacle. Opportunity is upside uncertainty — the easy one. Constraint is a condition you genuinely cannot change. Obstacle is a problem that can change, if you push on it the right way. Simple to state. I've been designing a quiz to help people feel that third distinction in their gut, using something as ordinary as planning a BBQ — sourcing, venue hours, who's available to run the grill, who has to sign off on the budget — and every time I write a new example, I catch myself second-guessing which shelf it belongs on.

That's the part worth admitting: I've made this mistake plenty of times myself, on real projects, not just in slide-writing. Call something a constraint too early and you stop pushing on it — you file it away as unchangeable and walk past whatever quiet negotiation or workaround might have moved it. Call something an obstacle for too long and you burn weeks of energy trying to bend a regulation or a physical limit that was never going to bend, no matter how creatively the team attacked it. The two failures point in opposite directions, but they share the same root: a single, unexamined decision about which shelf a problem goes on, made early and never revisited.

Building the quiz taught me something I didn't expect going in — getting the "correct" classification right matters far less than I assumed. What actually matters is whether a team develops the habit of stopping to ask "is this really unchangeable, or have we just decided it is?" The same fact pattern can sit as a constraint in one organization and an obstacle in another, or flip from one to the other once the timing or the people involved change. The classification isn't the destination. It's the door into a conversation the team should be having anyway.

That's close to the actual core of what a project manager does, once you strip away the scheduling software and the risk registers. It's less about the technical skill of identifying risks and more about whether the team can keep asking, out loud, whether a wall is actually load-bearing or just looks that way because nobody's leaned on it yet. A team that stops there gets a different outcome from an identical set of constraints than a team that pushes through that one question together.

I'm not going to lay out the full framework or the quiz here — it's built for the room, not the page, and I'd rather people work through the constraint-versus-obstacle confusion the way it's meant to be worked through, with a group and a whiteboard, not by reading my answer key. If the distinction sounds like something your team keeps tripping over, I'm putting together a three-day seminar with a colleague that spends real time on exactly this, alongside the rest of what project design and facilitation actually require. Details are here: https://www.guc-intel.com/seminar.html. For everyone else, the smaller takeaway travels fine on its own: next time something feels immovable, it's worth one more question before you file it away.