# Shared capacity counted twice across projects

Illustrative planning brief; no automatic product import.

Synthetic planning case: A shared editing pool has 24 person-hours available this week. Project North requests 16 and South requests 12; both project plans describe the full pool as theirs.

## Decision

The combined request is 28 person-hours against one 24-hour pool. Resolve the four-hour over-allocation before accepting both project plans.

## Owned work

- Identify the shared pool
  - Owner role: Capacity owner
  - Acceptance evidence: Both project allocations point to the same 24-hour availability record.
- Reconcile combined demand
  - Owner role: Planning lead
  - Acceptance evidence: The combined 28-hour request and four-hour excess are visible.
- Agree the displacement
  - Owner role: Project owners
  - Acceptance evidence: A named request is reduced, moved or supplied by separately confirmed capacity.

## Workflow

1. Identify the shared pool. Check: Both project allocations point to the same 24-hour availability record.
2. Reconcile combined demand. Check: The combined 28-hour request and four-hour excess are visible.
3. Agree the displacement. Check: A named request is reduced, moved or supplied by separately confirmed capacity.

## Judgment

Availability and demand are supplied planning inputs, not measured productivity. A different skill or calendar constraint may still block a feasible total.


## Filled manual planning note

The combined request is 28 person-hours against one 24-hour pool. Resolve the four-hour over-allocation before accepting both project plans. 16+12=28 requested; 28−24=4 uncovered person-hours. Adding the same 24-hour pool to each project does not create 48 hours. Availability and demand are supplied planning inputs, not measured productivity. A different skill or calendar constraint may still block a feasible total.


## Workflow questions

### Can each project pass its own capacity check?

Yes, each request is below 24; the shared-pool check still fails when requests are combined.

### Does the four-hour gap imply overtime?

No. Additional availability requires a separate agreement; the ledger does not authorize it.

## Product connection

Use the owned checks and downloaded brief to discuss this planning decision alongside your TeamBoostAI tasks. Confirm available fields, roles and account features separately. The example is manual; it does not calculate live analytics, create work or run an experiment in the product.

Confirm account availability before adopting this manual outline.

## Original worked case

Synthetic records, manual planning only. No account import or live analytics.

### Inspect the invented case records

Capacity or request | Person-hours | Scope
--- | --- | ---
Shared pool | 24 | One pool
North request | 16 | Uses shared pool
South request | 12 | Uses the same pool

### Reasoning

16+12=28 requested; 28−24=4 uncovered person-hours. Adding the same 24-hour pool to each project does not create 48 hours.

### Bounded result

The combined request is 28 person-hours against one 24-hour pool. Resolve the four-hour over-allocation before accepting both project plans.

### Distinct decision

This audits duplicate use of one availability pool across project allocations; it is not merely a sprint availability checklist.

### Limits

Availability and demand are supplied planning inputs, not measured productivity. A different skill or calendar constraint may still block a feasible total.

### Definitions and method context

- GAO Schedule Assessment Guide — https://www.gao.gov/products/gao-16-89g — General schedule-model context. All records, local policies and arithmetic are original toy examples, not a certified or optimized schedule.