The corollary is: “When one Project Constraint Changes at Least one Other Constraint is Affected”. The 6 project constraints are Product Requirements (i.e., Quality), Project Scope, Project Delivery Schedule, Project Resources, Project Costs, and Project Risks (the “variable”). A “Balanced” Project Plan meets the first 5 constraints, within Organizational Risk Tolerances (the 6th Constraint). When the project team veers too far off course (i.e., falls within the “Red” Zone for a Project Constraint) the project plan should be “re-Balanced” to keep the “Cost of Change” to a minimum. RED should mean “stop”. Under this condition the team leaders (e.g., PM and Functional Leads) and organizational Leaders (e.g., Functional Managers) should assess options and implement changes to one or more other constraint(s). If everyone decides that no changes are warranted, then the “Red Zone” boundaries should be changed. The kiss of death is when we don’t recognize or admit that we are in the trouble and end up doing what everybody wants to do – take the path of least resistance and absorb the risk. Then the real question is “How much risk can we absorb and still succeed?”
The “Cost of Change” is lowest at the onset (e.g., Kick-Off) of the project. The nasty thing about this curve is that it only increases over the PLC (Project Life Cycle) timeline, and it eventually “hockey-sticks”, so the earlier you make a necessary change to resolve or prevent an issue, the lower the “Cost” associated with the change. The “Cost” could be the resultant impact to any combination of the following: Budget, Schedule, Scope, Resources, Product Requirements, and/or Project Risk(s). You might be asking “How do we combat the Cost of Change?” The simple answer is through diligent tracking of key metrics, or KPIs (Key Performance Indicators), and their trends. In addition, the organization should establish governance guidelines (i.e., Red/Yellow/Green) where RED means “Stop” – but where the team members do not literally stop – however, the Team and Functional Leaders must expediently act to rectify the situation (i.e., agree on a change). And the organization should establish processes that facilitate expedient decision-making for reviewing, approving, and implementing those necessary changes.
This is basically a human tendency which supports the notion of establishing more aggressive “Targets” for project and task schedules and/or costs. It means that you are not likely to do better than what you “Target”, and thus, you are more likely to do worse (i.e., miss your “Target”). It advocates for the establishment of a “Target” schedule that is more aggressive (i.e., higher risk) than the schedule committed to. It recognizes that the “Critical Path” schedule is of strategic importance to the project’s success – it typically (i.e., for complex projects) has a very low probability of success due to the inherent project risks. Inherent project risks? Yes, resulting from the innate organizational desires to “Do more with less” by taking on as much risk as possible. Thus, the critical path schedule is a good aggressive “Target” schedule, but typically a very low confidence level “Commitment” schedule. If your teams appropriately utilize a good SRA (Schedule Risk Analysis) tool to determine and establish sound “Commitment” and “Target” project plans, they will be more successful. How do I know this? Because every time I did, my projects were successful.