Chapter 11: Constraint Management
Constraint Management is an essential aspect of project management and extends beyond the planning and control method known as Critical Chain Project Management (CCPM). It is applicable in identifying and selecting projects, allocating resources across the portfolio [1], and managing constraints in various project management-related systems.
In his Theory of Constraints (TOC), Eliyahu M. Goldratt argues that system performance improves when a small set of factors is successfully influenced. From a systems perspective, Goldratt describes the Theory of Constraints as a cyclical process in which an organization first aims to optimize the use of its existing resources before focusing on improving the system itself [2].
Even in the context of TOC, the constraints in projects are interpreted in a variety of ways within the project management community: ranging from the belief that there is always only one constraint to the existence of many; and from the search for constraints without defining the system's goal to defining the project’s critical chain as a “universal constraint.” Let us examine this issue systematically.
Goldratt’s view is that a constraint is "anything that limits a system from achieving higher performance versus its goal" [2].
In the context of project management, we work with clearly defined, hierarchically dependent systems: the investing organization, project portfolios, programs, and individual projects. To improve these systems, we need a single goal for each of them (or a mechanism to determine a "synthetic goal" for multiple goals). Furthermore, the goals of the system hierarchy must be compatible and measurable with compatible metrics.
The issue of project profit, interpreted in the broadest sense, has already been examined [1]; therefore, we will define the basic goal hierarchy as follows:
Project Profit → Portfolio Profit → Organization Profit (Investor Profit)
This hierarchy means that, for example, we should sacrifice some project profit if doing so increases the overall profit of the project portfolio.
To be precise, Goldratt did not state that there is a single constraint in a system, but that there are “very few constraints” and “at least one constraint” [2]. Of course, the existence of a single constraint is possible, and we can deliberately change the system to achieve this. We can even choose what the constraint should be.
In the book where he introduces TOC (The Goal), Goldratt actually writes about two simultaneous constraints, discovered by Alex Rogo. Here is how Goldratt’s example can be summarized:
Figure 10.1: Two Simultaneously Existing Constraints
Technically, this system is constrained to the greatest extent by the capacity of workstation C; however, focusing the effort solely on it would have a negligible effect. In practice, we must accept that there are two constraints: C and E.
But, are there not a large number of constraints in every project, not just a very small number? We can agree that there is a huge number of potential constraints in every project. We often see a large number of constraints due to a lack of clarity regarding the project’s goal, or, even worse, due to multiple goals that need to be navigated between. Then we truly work without a compass and face constraints everywhere.
Furthermore, the more complicated, complex, and chaotic a project is, the more numerous its constraints are and the more complex the interactions between them. If a project is simplified to a Minimum Viable Project (MVP) and has a clear goal, we can expect a small number of constraints in it.
Portfolios and projects are systems created by people. Therefore, to a large extent, they are manageable and can be simplified.
Goldratt argues that the critical chain is a constraint in projects [3]. But is it always so? Is the goal of every project to finish on time, or more precisely, to be executed within a certain time? If the completion date is the main obstacle to achieving the goals of the projects, then we could accept the critical chain as an irreplaceable constraint.
But this cannot be a universal truth. For example, if a project is wasteful by design, or during execution, its expected profit becomes negative, focusing on finishing "on time" can prevent realizing that the project should be terminated as soon as possible. We leave aside the question of what exactly it means for the critical chain to be a constraint.
Drawing upon TOC, we must approach constraints in projects and project portfolios as in any other system.
The constraints in projects and portfolios are contextual and always depend on the goal and specific conditions.
Well-known examples are resource availability or capacity, which could be the main obstacle to achieving the expected project or portfolio profit. Since project benefits depend on the utility of the project products, the demand (including market demand, where applicable, or “the market,” in TOC’s terms) for the project products could also be a constraint. According to TOC, policies, such as that projects with a higher expected ROI should have a greater priority, or limiting beliefs (e.g., that the sooner we start a project, the sooner we will be able to finish it), can also compromise profitability.
False assumptions, such as that the project’s “strategic value” provides the best return on project investments, are also possible constraints. The assumption that projects always have only one constraint or many constraints can be a constraint, too.
What is not a constraint in the context of TOC:
- A fixed requirement that must be met (e.g., a condition for stakeholder satisfaction or a date on which an event is to be held). Constraints are something that can be influenced and managed; therefore, they are not boundaries. Conversely, fixed requirements (as long as they remain fixed) are something that must be achieved or ensured; hence, they are boundaries.
- A factor that cannot be influenced, e.g., legal regulation or geotechnical conditions. Applying a logic similar to that of fixed requirements, such factors should be considered as boundaries.
The fixed requirements and the factors that we cannot influence are boundaries of our freedom of action, within which we must seek specific constraints to manage.
If there are contradictions in this chapter, they are deliberately allowed, with the sole purpose of entertaining the reader!
Isn't the market demand, mentioned above as a possible constraint, an example of a factor that we cannot influence? If we assume that is the case, then we should not perceive it as a constraint. However, if we reframe market demand as a manageable, internal factor that we can influence—such as the capacity of salespeople—then we can turn it into a constraint.
Let's summarize the comparison of Boundary and Constraint.
Table 10.1: Boundary vs. Constraint
Characteristic | Boundary | Constraint |
|---|---|---|
Definition | A fixed requirement or a factor beyond our control. | A factor that limits a system from achieving its goal. |
Manageability | It cannot be influenced directly or is a fixed requirement that must be satisfied. | Can be influenced and managed. |
Examples | Legal regulation; Geotechnical conditions; Fixed date for event; Stakeholder satisfaction requirement. | Resource capacity versus need; Policy (e.g., ROI priority); False assumptions. |
Role in Project Management | Limits freedom of action. A border within which constraints must be identified and managed. | Must be identified and managed through the TOC processes. |
Here is what the process of reframing Boundary into Constraint looks like (Reframing Framework):
- Identify the Boundary
- Reframe the impossible into the possible using one of these constructs:
a) We cannot change the Boundary, but we can manage the internal factors that prevent us from meeting the demands it places, or b) We cannot eliminate the Boundary, but we can move (expand) it. - Define the areas of influence
- Specify and verify the Constraint
The examples below illustrate the application of the Reframing Framework.
Table 10.2: Reframing Legal Regulation (A) and Market Demand (B)
Step | From Boundary | To Constraint |
|---|---|---|
1. Identifying the Boundary | A: On date D, a new safety standard for product X comes into effect. B: Market demand for product Y is less than our production capacity. | - |
2. Reframing the Impossible into What is Possible | A: We cannot change the date and the new security requirements… B: We cannot secure unlimited demand for the product… | A: BUT we can manage the internal factors to ensure the adoption of the new standard on time. B: BUT we can increase demand, as market needs exceed current demand for product Y. |
3. Defining Areas of Influence | - | A: The capacity of the legal compliance team and the technical ability to execute. B: The sales process; the time our salespeople spend making sales. |
4. Specifying and Verifying the Constraint | - | A: Lack of a legal expert on the new security standard. We possess all the other resources needed to implement the new security standard on time. A: Lack of a legal expert on the new security standard. |
Feel free to reframe the Reframing Framework if it needs improvement!
We must also bear in mind that:
- In addition to the existing constraints, there are also anticipated future constraints, on which we must work proactively in the present.
- Constraints can change—either due to our actions or due to other reasons.
- Constraints can be relatively stable (e.g., resource capacity relative to need) or incidental (e.g., limited access to a construction site due to a landslide).
- A hierarchy of constraints exists, which reflects the hierarchy of systems. A constraint that stands higher in the hierarchy potentially has a greater impact on the global system. For example, a well-managed constraint at the portfolio level is not a constraint for individual projects; a well-managed constraint at the project level is not a constraint for individual teams.
- Constraint management applies to all aspects of project management. There are no universal constraints in project management. Identifying wrong constraints leads to ineffective resource allocation and creates waste.
- If projects are simplified to Minimum Viable Projects and have a clear, single goal, we can expect a very small number of existing, relatively stable constraints. This way, projects become more manageable.
- We should not rely only on the "technical" criteria for identifying constraints. They should be complemented by reasonable judgment.
- The constraints of hierarchical systems (e.g., project portfolios and projects) reflect a hierarchical dependence. In addition to the existing ones, we must also manage anticipated future constraints, as well as incidental constraints that may appear at any moment.
- The fixed requirements that projects and portfolios must meet, as well as the factors we cannot influence, should not be viewed as constraints, but as factors that limit the freedom of action required to achieve the respective goal.
- To manage factors outside our sphere of influence, we must reframe them as internal factors we can influence (see the Reframing Framework).
We'd love to hear from you.
Share your thoughts in the comments below!
_______________
[1] See: Apostolov, A. (2025). The Combination-Permutation Algorithm: Optimizing Portfolio Allocation with TOC and Cost of Time, PM World Journal, Vol. XIV, Issue VII, July. Available online at https://pmworldlibrary.net/wp-content/uploads/2025/07/pmwj154-Jul2025-Apostolov-Combination-Permutation-Algorithm.pdf
[2] Goldratt, Eliyahu M. (1990). What is This Thing Called Theory of Constraints and How Should It Be Implemented? North River Press
[3] Goldratt, Eliyahu M. (1997). Critical Chain. North River Press