Blog Post #6: More on the Quadruple Constraint +1 (aka the "Flexible Quadrangle +1")

(Fair Lawn, NJ - March 12, 2018) - This is the 6th in a series of blogs posted in early 2018 with excerpts from the upcoming book: Project Management for Performance Improvement Teams (PM4PITs) co-authored by our COO -- Bill Ruggles -- which is scheduled to be launched on May 7th at the PMI-NJ Chapter's 2018 Seminar & Symposium at the Pines Manor in Edison, NJ!

Our last blog (#5) provided an excerpt from Chapter 2 which addresses the 'contemporary' approach to project management and its 3 key strengths that create a better way to manage a project — especially a Performance Improvement Project undertaken to address an Opportunity For Improvement (OFI) — in the twenty-first century! 

This new framework is founded on what we call the "Quadruple Constraints + 1" or the "Flexible Quadrangle + 1". (See figure below for the "Basic" version of this framework.)

 If you were to look carefully at a typical 21st century project – whether it has a “Waterfall”, “Iterative”, “Adaptive” or “Hybrid” life cycle – you would see that there are SIX (6) competing project constraints: Scope, Time, CostResources, Quality, and Risk which need to be addressed throughout that life cycle.  Our "contemporary" framework provides for ALL SIX of these Project Constraints!

Ironically, the 6th Edition of PMI’s own document (PMBOK® Guide) DOES identify all six of these competing constraints, not once but TWICE:

  • “Tailoring should address the competing constraints of: Scope, Schedule, Cost, Resources, Quality, and Risk.” 1
  • Managing a project typically includes but is not limited to: …balancing competing project constraints, which include but are not limited to: Scope, Schedule, Cost, Quality, Resources, and Risk...”2

Yet, PMI's own Registered Education Providers refuse to update their training materials to include them!  Go figure!

Taking this Basic Framework one level further, as you can see in the Figure below, the “Expanded Quadruple Constraints +1” is shaped exactly like the Basic version in the center, but now you see the addition of two “stakeholders”:  a “Requesting Organization” (on the left) and a “Performing Organization” (on the right) who are positioned on opposite sides of this diamond-shaped table:

One represents the fundamental interests of a “Buyer”, “Customer”, “End-User”, or “Investor” (on the left) and the other a “Seller”, “Vendor” or “Provider” (on the right) where the Project Manager and his/her Project Team normally reside.

Let’s assume that, like any “Buyer”, “Customer” “End-User” or “Investor”, the “Requesting Organization” (RO) has one or more expectations about getting a Performance Improvement Project done that will meet its value-added expectations.  In addition to Quality (“Good”), the RO’s expectations typically include Time (“Fast”), and Cost/Resources (“Inexpensive”) but, normally, it hasn’t even considered the potential Risks (“Threats”) inherent in this undertaking yet.

In fact, since the RO rarely has the expertise to get the work done on its own, it must go looking for someone else who does: either inside the same enterprise or outside of it.  That’s where the “Performing Organization” (PO) positioned on the right side of the diamond-shaped table comes in.

The PO chosen should have the resources with the knowledge, skills, tools, and techniques (e.g., “Expertise”) to submit a proposal or a quotation detailing what such an undertaking would entail, based on the RO’s expectations as documented in a Requirements document and/or Product Backlog.

Yet, like any “Seller”, “Provider” or “Vendor”, the PO has its own perspective on the very same constraints and expectations about getting that Performance Improvement Project done for the RO.  But, before the PO can do so, it needs to know more about how much work is involved (Scope).  Let’s “listen-in” on a "typical" initial conversation between representatives for each party:

  • RO Rep (Buyer): “Thanks for taking the time to meet with me.”
  • PO Rep (Seller): “It’s my pleasure. I understand that your business unit has identified an opportunity for improvement involving one of its processes and that our Shared Services unit might have the expertise to help you fulfill your requirements in that regard.”
  • RO Rep (Buyer): “Requirements? What’s a requirement?”
  • PO Rep (Seller): “A Requirement is a functional or technical characteristic of the new process you want that will, when combined with the other requirements, meet or exceed your needs and expectations. Our Business Analyst can help you identify all your initial requirements and, after you prioritize them into 3 levels (High, Medium, and Low) the BA will itemize and describe them in a way that can be converted by our developers into prioritized specifications. Then, we’d be able to come up with a Proposal that would include an estimate of the initial Scope, Quality, Schedule, Budget/Resource, and Risk parameters for you. At that point, we’d be able to sit down together and determine what’s feasible within your constraints. We can even use an “agile approach” where you can progressively elaborate or refine your highest priority requirements or product back-log on a frequent basis over time.”
  • RO Rep (Buyer): “That’d be great! When can we start?”

(Authors’ Note:  An “agile approach”, used most frequently in a Software Development project environment, is described in 1st Edition of the Agile Practice Guide3 that is bundled with the 6th Edition of the PMBOK® Guide.  It is most appropriate for high-uncertainty projects that have high rates of change, complexity, and risk where it is being applied with increasing frequency.)

Hopefully, this brief conversation above will lead the two parties to a series of conversations and meetings at which a negotiated agreement (also called a “tailored outcome”) will emerge. For example, for any project to be successful, both parties must be willing to recognize that there are three (3) possible performance improvement project outcome combinations that will be: “balanced” or in a “state of equilibrium”.  These 3 possible performance improvement outcomes are:

  1. Good, Fast, and Smart” (but not so “Inexpensive”; it’ll probably cost more than desired)
  2. Good, Inexpensive, and Smart” (but not so “Fast”; it’ll probably take longer to complete than desired)
  3. Fast, Inexpensive, and Smart” (but not so “Good”; it’ll probably be delivered with less functionality and fewer features than desired).

Then, there’s a fourth possible project outcome combination that is “unbalanced” and which will likely be unsuccessful.  This outcome combination is the one referenced back in the Introductions for Chapter 1 and this chapter.  Take another look at them if you’ve forgotten them.  Here’s the toxic combination:

  1. Good, Fast, and Inexpensive” (but not so “Smart”, it’ll probably be imbalanced and encounter more threats and challenges than can be managed properly.)

So, you may call such an undertaking a “half-baked idea”, a “pipedream”, “wishful thinking”, “deliverable delusion disorder”, or a “mission impossible”. The solution may not be in line with the organization’s culture and as a result, it will not be accepted by the employees. Unfortunately, these cursed project assignments have become all-too-common over the years we’ve been around such that one of the co-authors has a nickname for it:  he simply calls it an “Anti-Project”!

This “Quadruple Constraint + One” or “Flexible Quadrangle + One” paradigm puts the Project Manager within the Performing Organization in a much more secure position to negotiate the necessary adjustments and make trade-offs among each project’s competing objectives and alternatives to respond to BOTH types of Risk – favorable AND unfavorable:

  • Favorable:  Exploit, Enhance, Share, and/or Accept them (Opportunities);
  • Unfavorable:  Avoid, Transfer, Mitigate, and/or Accept them (Threats).

We believe this framework is the foundation upon which to manage each project in the 21st Century and we aren’t surprised, after we walk someone through it, and when we’re told that it makes so much common sense.  They usually want to know why someone didn’t publish it sooner!  On behalf of the project management professional community, we apologize for the delay, but help is here now! 

- PMBOK® Guide, 6th Edition, © 2017 PMI, p. 28
2PMBOK® Guide, 6th Edition, © 2017 PMI, p. 542
3 - Agile Practice Guide, 1st Edition, © 2017 PMI, p. 2

For more details regarding this Contemporary Framework be sure to pre-order your copy of our book by going to:

In the meantime, please let us know if you have any questions or comments about 'contemporary' project management in a performance improvement project context by contacting us either at or simply leave us a comment below.

Leave a comment

Please note, comments must be approved before they are published