magnus919_agent-skills/technical-project-management/references/hybrid-and-dependencies.md

# Hybrid delivery and dependency coordination

Use when teams, vendors, procurement, hardware, or governance work on different
cadences. Basis: S01/S06 support tailoring; C03 supplies a real coordination
example. The interface procedure below is this skill's synthesis.

## Define a hybrid precisely

Name which work follows which approach, why, and who owns each interface. A
monthly sponsor decision can coexist with continuous software delivery; it must
not secretly require every team to wait for a monthly release. Conversely, a
sprint review cannot override a required external certification.

Maintain one authoritative milestone/decision view. Team backlogs can differ;
project commitments cannot contradict each other without a visible unresolved
issue. Do not impose a shared sprint length merely to simplify reporting.

## Dependency agreement

For each material dependency record: provider, receiver, deliverable and version,
acceptance evidence, needed-by date, provider forecast, accepted commitment,
confidence basis, review date, escalation owner, and fallback. A provider saying
"we'll try" is a forecast or aspiration, not a commitment.

1. Ask the receiver what usable input is needed, not just which team is blocking.
2. Validate whether it is a hard dependency. A mock may permit development but not
   production acceptance; document both boundaries.
3. Confirm the provider's scope and capacity. Include procurement lead time,
   reviews, security, test environments, and customer participation.
4. Schedule an integration checkpoint before the final milestone. Agree how a
   failed handoff changes the forecast and who decides the response.
5. Track interface changes and receiver acknowledgement. A delivered artifact is
   not an accepted handoff until the receiving party can use it as agreed.

## Vendor and distributed-team cases

| Problem | Response |
|---|---|
| Fixed-price vendor with evolving software needs | Identify contractual acceptance/change process; assess options with procurement/legal rather than interpreting rights yourself |
| Vendor dates lag the project need | Record date gap and latest decision point for contingency; escalate before the fallback becomes impossible |
| Shared environment unavailable | Treat environment capacity as a dependency, with a specific reservation owner |
| Time-zone handoffs add a day per question | Use an async decision brief, clear response window, and backup decision-maker |
| Two teams claim contract ownership | Separate authoring, approval, and acceptance responsibilities; route unresolved authority to the sponsor |
| Several projects compete for one team | Surface program/portfolio arbitration; do not allocate another project's capacity unilaterally |

## Worked boundary (hypothetical)

A vendor provides a certified device in week 8; software teams iterate fortnightly.
The project has interface test evidence due in week 5 and integrated acceptance in
week 9. If certification moves to week 10, successful software sprints do not keep
the project green. Present a revised integration forecast, impact on commitments,
and an authorized fallback decision. A simulator retires interface uncertainty but
does not replace device certification.

Complete when critical handoffs have accepted owners, evidence, dates, and escalation
paths, or their absence is explicitly blocking the affected commitment.