Rebalance Trigger Protocol (Delivery)

Rebalance Trigger Protocol (Delivery)

1. 01

   Set the rebalance threshold before the engagement starts

   Agree on a utilization band (for example, flag any person above 90% or below 60% booked for two consecutive weeks) and write it into the staffing plan so the trigger is not negotiated mid-crisis.

2. 02

   Pull a two-week forward view of bookings against actual logged hours

   Compare scheduled allocations with time entries from the tracking layer. A gap between booked and logged hours is the earliest signal that a schedule has drifted from reality.

3. 03

   Rank the affected projects by revenue at risk, not by loudest client

   A retainer renewal three weeks out outranks an internal initiative every time. Sort by contract value, deadline proximity, and penalty clauses before deciding who moves.

4. 04

   Check skill fit before moving anyone

   A free designer is not a free developer. Confirm the receiving project's required skills against the person's last three comparable assignments, not their job title.

5. 05

   Model the move in the scheduling tool and check the ripple

   Drag the allocation and inspect what it does to every downstream project. One reassignment that fixes one overbooked person can create two new gaps elsewhere.

6. 06

   Get the account lead's sign-off in writing

   A one-line confirmation in the project channel is enough. Verbal agreement on a staffing change is how agencies end up with two people believing different things about who owns a deliverable.

7. 07

   Log the change and the reason in the capacity record

   Note the date, the person moved, the projects involved, and the trigger that fired. This log is what turns next quarter's planning session from guesswork into pattern recognition.