Why Scope, Schedule and Finance Cannot Be Managed Separately
The three constraints are usually taught as a set of trade-offs, drawn as a triangle, with the lesson that moving one moves the others. That is true and it is not quite what happens on a project. What happens is that scope gets changed by decisions that were not about scope, taken in meetings with other names on them, by people who would be surprised to hear they had changed anything. The reduction becomes visible months later, at commissioning or at handover, when somebody asks where a piece of work went.
Section 2.2.4 of the PMBOK® Guide Eighth Edition deals with how the scope work connects to everything around it, and the practical value of taking that seriously is early warning. The interactions are not occasional. They run continuously, in both directions, and they are mostly invisible unless somebody is deliberately looking.
How a schedule decision becomes a scope decision
Compression removes work, and it removes the work at the end. When a sequence is squeezed, nothing formally leaves the project, but the activities with the least defended position lose their time: commissioning, training, data migration verification, soak testing, the second round of user acceptance. None of that appears as a scope change, because the line items still exist. They are simply done in a third of the time by people who now have to choose what to skip, and the choosing happens at operational level with no record.
Fixing a date turns requirements into options. The moment an immovable date is confirmed, the project acquires a mechanism for silently deprioritising anything that threatens it. This is often the right response, and a team that does it consciously, with the sponsor's agreement about what will not be delivered, has managed a constraint properly. A team that does it by absorption discovers at go-live that three things everyone assumed were included were quietly shed in week eleven.
How a money decision becomes a scope decision
Package boundaries decide what falls between them. Splitting work into two contracts creates an interface, and whatever nobody explicitly bought at that interface becomes a gap: the testing between two systems, the making-good after a removal, the commissioning of an installation somebody else fitted. The boundary is a commercial decision taken for good commercial reasons, and it changes what the project will actually deliver.
Contingency behaviour shapes what gets built. Where contingency is held centrally and released reluctantly, teams engineer to avoid asking, which means simpler solutions, fewer options carried, and less provision for what might be found. Where it is released easily, the opposite happens. Neither is wrong, and both change the product without a single scope conversation.
Funding rules set the shape of the deliverable. Capital and operating budgets have different rules about what they can buy, and a project funded entirely from capital will find reasons to build things it might otherwise have rented, licensed or outsourced. The accounting treatment is not a detail at the edge of the project; it is an active constraint on the design.
A compound finished six weeks before its trench
A wind farm connection ran as two packages. The electrical package covered the compound: switchgear, transformer, protection, commissioning. The civils package covered the trench and duct route from the turbine array to the compound, about a kilometre of it across farmland.
Both packages were let to sensible dates and both delivered to them. The compound was complete, fenced and ready in early September. The trench was contracted to finish in mid October, which was six weeks later and entirely in accordance with its own programme. The connection date assumed by the financial model was the end of September.
Nobody had decided to miss it. The electrical date came from the switchgear lead time, the civils date from a ground conditions survey and a seasonal access restriction across two fields, and each had been agreed in its own package review by people who were correct about their own work. The connection date lived in the financial model, which was reviewed monthly by a different group, and the two programmes had never been laid against it in the same room.
The cost was not the six weeks of delay. It was that the site sat complete and unproductive through six weeks of good autumn wind, which the model valued at a figure large enough to have justified paying the civils contractor to work through the restricted period, had anybody asked in June. By the time the gap was visible on site it was too late to buy the time.
The fix afterwards was procedural and small. The two package programmes and the financial model went into one monthly review, with a single question standing at the top of the agenda: which of the three has moved since last month, and what has that done to the other two? The second connection on the same programme landed within four days of its modelled date.
Managing the three as one conversation
Keep one register of commitments, not three. Where scope, date and cost commitments live in separate documents owned by separate people, the interactions have nowhere to become visible, and they surface as surprises at the points where the work physically meets. One place where all three are recorded is a low-cost intervention with a disproportionate effect.
Ask the second-order question every time one of them moves. A date has moved: what work just lost its float, and who will decide what to skip? A budget has been cut: which requirement has quietly become optional, and does the person who asked for it know? Scope has been added: whose date absorbed it? The question takes a minute and it is the whole of the discipline.
For a PMP® candidate, it helps to recognise that a change in one constraint has already changed the others by the time anybody discusses it, so the first move in any such situation is to establish the effect on the other two before responding. A response that addresses only the constraint that moved is treating a symptom in one domain. Situations where a schedule or funding decision has silently redefined the deliverable are one of the staples of a structured PMP exam preparation course.
A direct test settles it. Look at the last three significant decisions taken about dates or money, and for each one, name the piece of work that changed as a result. If you cannot name one, the likelihood is not that there was no effect; it is that the effect has not been found yet, and it is usually waiting at the end of the programme where the least defended activities live.
Interested in going further?
The expensive version of this problem is never a bad decision. It is two good decisions taken in different rooms against a third number neither room was looking at. Omega's PMP® Exam Preparation works through constraints as a connected system.
The connections between scope and the domains around it are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A203: How to Handle Competing Constraints in a PMP Scenario
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A107: Scope Creep vs Legitimate Change
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
