HKSM

Dependency determination and integration is an analysis technique used to identify, classify, and link dependencies among activities, deliverables, and external parties. It integrates the agreed relationships into the schedule network and team plans so work can be sequenced, coordinated, and monitored.

Key Points

• Identifies and classifies relationships among activities, deliverables, and external entities.
• Uses logical types (finish-to-start, start-to-start, finish-to-finish, start-to-finish) and categories (mandatory, discretionary, internal, external).
• Captures leads and lags with clear rationale, owner, and approval where needed.
• Integrates dependencies into the schedule network, team boards, and release plans.
• Supports critical path analysis, risk management, and sequencing decisions.
• Is iterative: revisit as scope, design, or resource availability changes.

Purpose of Analysis

• To reveal how work items relate so the team can plan realistic sequencing and coordination.
• To anticipate constraints, handoffs, and external lead times that affect schedule and risk.
• To enable overlap where beneficial and safe, and to document rules for doing so.
• To standardize how dependencies are recorded, communicated, and monitored.

Method Steps

• List the activities, backlog items, and deliverables to be sequenced.
• Elicit constraints, interfaces, and assumptions from technical leads, suppliers, and stakeholders.
• Identify logical relationships and assign a type (FS, SS, FF, SF) for each pair that must be linked.
• Classify each as mandatory vs discretionary and internal vs external; note the source and rationale.
• Determine any leads or lags; quantify them and record the justification and risk.
• Validate dependencies with involved parties; challenge discretionary links to increase flexibility.
• Integrate approved dependencies into the schedule network, boards, or roadmaps.
• Analyze impacts on the critical path, float, and milestones; propose adjustments if needed.
• Baseline or update plans per governance; communicate changes and owners of key dependencies.
• Monitor and revalidate dependencies at regular cadence and after change events.

Inputs Needed

• Scope statement, WBS or backlog, and acceptance criteria.
• Activity list with attributes or user stories with definition of ready/done.
• Technical designs, interface maps, and system or process architecture.
• Resource calendars, team capacity, and skills availability.
• Contracts, supplier schedules, service-level commitments, and regulatory dates.
• Assumptions log and risk register, including known constraints.
• Organizational lessons learned and dependency registers from similar efforts.

Outputs Produced

• Dependency register with type, category, owner, lead/lag, rationale, and status.
• Updated schedule model or network diagram with annotated relationships.
• Proposed schedule changes and, if approved, updates to the baseline.
• Updates to risk register and assumptions log based on dependency exposure.
• Interface or coordination agreements with internal teams and external parties.
• Inputs to release plans, iteration plans, and milestone forecasts.

Interpretation Tips

• Mandatory internal dependencies are often real, but verify they are not preferences in disguise.
• Discretionary links are candidates for re-sequencing when you need flexibility or compression.
• Leads reduce buffers and increase risk; ensure test coverage and controls if you overlap work.
• Lags should be measurable and sourced (e.g., vendor lead time), not placeholders.
• Watch for circular dependencies or excessive constraints that can lock the schedule.
• Reassess external dependencies frequently; they tend to drive slippage.

Example

A cross-functional project has activities: finalize design, procure components, assemble prototype, and test. The team identifies an external dependency: supplier delivery must occur before assembly (finish-to-start) with a 10-day lead time. They also agree to start test planning 3 days before assembly finishes (start-to-start with a 3-day lead) to accelerate delivery. These are documented in the dependency register with owners, integrated into the network diagram, and used to analyze the critical path and communicate risks to stakeholders.

Pitfalls

• Labeling most links as mandatory without proof, reducing options for optimization.
• Ignoring external lead times or contract clauses until late in planning.
• Overusing leads and lags, making the schedule hard to understand and maintain.
• Missing resource-driven dependencies that create hidden queues and delays.
• Failing to validate and update dependencies after scope or design changes.
• Allowing circular or conflicting dependencies to persist in the network.

PMP Example Question

During planning, the team proposes a 4-day lead between development and system testing to meet a milestone. What should the project manager do next?

1. Add the lead to the schedule immediately to protect the milestone.
2. Remove the dependency to avoid overlap risk and extend the milestone.
3. Validate the dependency type and impact with stakeholders, document the 4-day lead with rationale, and update the schedule model.
4. Ask the sponsor to approve a new milestone date before any analysis.

Correct Answer: C - Validate the dependency type and impact with stakeholders, document the 4-day lead with rationale, and update the schedule model.

Explanation: Dependencies with leads must be validated, documented, and integrated into the schedule before committing. Acting unilaterally or removing links without analysis increases risk.