Skip to content

Portfolio Intake Gate

Capacity-bound governance gate — instantiates Overcommitment Prevention

Routes every proposed initiative through a capacity-bound gate that can defer, reject, or require a trade before it becomes a commitment.

Portfolio Intake Gate is the governance checkpoint every proposed initiative must pass before it becomes a commitment. Proposals enter a single intake queue, are ranked into priority classes, and are admitted only if portfolio capacity allows — with the gate empowered to accept, defer, reject, split, or require an existing commitment to be retired to make room. Its distinguishing property is being the decision mechanism with authority to say no at the portfolio level, and its signature move is forcing a swap: new work in means either spare capacity or something goes out. Unlike the item-level checklist, it arbitrates across the whole portfolio and can actually block.

Example

An enterprise IT PMO faces a constant stream of "must-have" project requests from every VP. It stands up an intake gate: all requests file into one queue, get sized and slotted into priority classes (regulatory / strategic / discretionary), and the monthly gate admits only what the delivery portfolio's finite team-capacity allows. When Marketing's new personalization project arrives, the portfolio is full — the gate's options are stark: defer it to next quarter, reject it, or retire an in-flight discretionary project to fund it. Forced to name which existing project to stop, Marketing's sponsor discovers the request was not worth the trade and withdraws it. The gate converted "add it to the list" into an explicit, capacity-bound choice.

How it works

The signature is a single choke point with a real admission rule and swap authority. Proposals cannot become commitments except through the gate, which applies accept / defer / reject / split / retire against current portfolio headroom and priority ranking. Subordinating intake to the delivery constraint is the whole idea: the portfolio has finite throughput, and the gate protects it by admitting at the rate the constraint can absorb, not the rate requests arrive.[1]

Tuning parameters

  • Admission verdicts — the menu the gate can issue (accept / defer / reject / split / require-retire). A richer menu handles nuance; a blunt accept/reject is faster but cruder.
  • Priority scheme — how classes are defined and ranked (regulatory-first, value-over-effort, WSJF-style). This determines what wins under scarcity.
  • Capacity headroom rule — how full the portfolio may run before the gate hard-stops. Running near 100% maximizes output but destroys responsiveness.
  • Gate cadence and authority — how often it meets and whether it can truly say no. An advisory gate that cannot block is just a queue with a meeting.
  • Swap requirement — whether new admits must name a displacement. Enforcing swaps prevents silent scope creep but raises the political cost of each yes.

When it helps, and when it misleads

Its strength is being the mechanism that actually stops overcommitment at the portfolio boundary, with the forced-swap rule keeping total load conserved rather than ever-growing. Its limit is that a gate is only as strong as its authority: if senior stakeholders routinely bypass it through side channels, it becomes a bureaucratic speed bump that slows honest requests while the powerful skip it. The classic misuse is running it backwards as rubber-stamp theater — everything is admitted and "priority" is assigned after the decision. The discipline is to subordinate the gate to a real capacity number, require a named displacement for every over-capacity admit, and close the side channels so the gate is the only door.

How it implements the components

Portfolio Intake Gate realizes the admission-decision side of the archetype:

  • admission_rule_for_commitments — the gate is the accept / defer / reject / split / require-retire rule applied at the portfolio boundary.
  • demand_intake_queue — all proposals are funneled into one queue where they wait to be gated, rather than entering through side doors.
  • commitment_priority_class — proposals are ranked into priority classes that decide what is admitted under scarcity.

It decides at the portfolio level but does not specify each item's terms (Intake Capacity Checklist), model the capacity it gates against (Calendar Capacity Audit), or handle reductions after acceptance (Renegotiation Notice Protocol).

References

[1] In the Theory of Constraints, a system's throughput is set by its bottleneck, and intake must be subordinated to that constraint rather than to demand. A portfolio intake gate applies this to commitments: admit at the rate the delivery constraint can absorb, not the rate at which requests arrive. ↩