The inevitability of boundaries
In my last Insight, we talked about the leaking faucet. Once you've decided to fix the leak, you immediately run into reality: How much time do you have before the hardware store closes? How much are you willing to spend? Do you have the right wrench?
These are constraints. In the enterprise, we often treat constraints as "bad news." But a project without constraints isn't a project—it's a dream. To deliver a usable product, you have to manage the "Pack of Elephants."
Model: The pack of six
While many talk about the "Triple Constraint" (Time, Cost, Scope), I lead with six. If you ignore any one of these, that elephant will eventually sit on your project.
1. Time
The schedule and deadlines.
2. Cost
The budget and financial boundaries.
3. Scope
The specific work to be completed.
4. Resources
The people, tools, and expertise available.
5. Risk
The "known unknowns" that could disrupt progress.
6. Quality
The non-negotiable standards (Non-Functional Requirements).
The tension of the pack: Why quality can't be a trade-off
The most important lesson in "Elephant Management" is that these six are interconnected. If you pull on one, the others will move.
When a project is under pressure, the Quality elephant is often the first one people try to push out of the room. They treat Quality—specifically Non-Functional Requirements (NFRs) like Accessibility, Security, and Performance—as "extra steps" that can be skipped to save Time or Cost.
In my work on Business Process and Defect Management, I argue the opposite. NFRs are not "extra"; they define how a system should work. If you ignore how a system performs or who can use it, you haven't saved time—you've just built a defect that you'll have to pay to fix later.
In one line
If you ignore how a system performs or who can use it, you haven't saved time—you've just built a defect that you'll have to pay to fix later.
The security blueprint: From requirement to experience
To help stakeholders understand why Quality constraints are non-negotiable, I use the example of biometrics.
Think about using your face or fingerprint to log into your phone. Originally, this was a Security Requirement (an NFR). It was a constraint designed to protect data. However, once implemented, it became a massive Customer Experience (CX) win. It made signing in easier for people with disabilities, but it also made it easier for everyone else.
When we treat Accessibility or Security as a core constraint, we aren't just checking a box for compliance; we are improving the product for every single user. We move these requirements into the team's "Definition of Done" so they are baked into the fabric of the work, not tacked on at the end.
Root cause analysis for constraints
Just as we use Root Cause Analysis for initiation, we use it to understand our limits. When a constraint feels arbitrary, I ask "Why?" or "How?" until the truth comes out.
"We have to finish by June." Why?
"Because that's when the marketing campaign launches."
"How does the budget change if we miss it?"
By understanding the root of the constraint, you stop being a "task-master" and start being a System Navigator. You can make the trade-offs that keep the pack in formation.
The leader as a navigator
Managing a project isn't about the absence of limits; it's about the mastery of them. When you recognize that Constraints Are Always Present, you stop fighting the boundaries and start using them to focus your team's energy.
By keeping the "Pack of Six" in balance—and refusing to sacrifice Quality for the illusion of speed—you ensure that the "leaking faucet" isn't just patched, but repaired to a standard that lasts. You move from managing a schedule to delivering a system that is secure, accessible, and valuable to the enterprise.
How this insight supports different learners
R Readers
See the logic of why NFRs (like Security/Accessibility) are actually CX requirements in disguise.
L Listeners
Relate to the "Biometric" story, seeing how a technical constraint becomes a daily convenience.
D Doers
Get a rule for the "Definition of Done": Quality is a constraint that must be met before any task is considered "finished."
O Observers
Recognize a leader who doesn't just manage "tasks" but understands the deep architectural relationship between constraints and value.