The planning gap
Every project looks fine on its own. That is why the constraint hides.
The Theory of Constraints starts with a simple discipline: identify the constraint, exploit it, subordinate everything else to it, elevate it, and keep inertia from becoming the new constraint. In a single project the constraint is often a chain of tasks. In a portfolio it is usually a scarce skill or resource: data engineers, a test environment, the few people who understand the billing system. Every project needs a little of them, and together they set the pace.
A constraint like that rarely shows up in a status report. Only the combined load, period by period, shows that one pool is planned far beyond what it can deliver. Approving a project and starting it are also different decisions. When they are treated as one, a project is approved and starts now, another is approved next week and starts too, and soon the same specialists are switching between many projects, each waiting on the others, while every finish date slides.
The portfolio also keeps changing. A new top priority lands, a team loses people, a project slips, and the constraint quietly moves somewhere else. The theory is well understood. Keeping the sequence right by hand, week after week, is the hard part, and a plan rebuilt on a spreadsheet each time is already out of date when it reaches the meeting.