6.3 Resource & Dependency Management

6.3 Resource & Dependency Management

[!NOTE] Core MSP Resourcing & Dependency Principles:

• Programme Resourcing: The systemic identification, allocation, mobilization, and optimization of all assets—people, capital, infrastructure, tools, and intellectual property—needed to deliver capabilities without creating unsustainable operational friction.
• Programme Dependencies: The critical relational links between activities, projects, and external entities where the commencement, execution, or completion of one element relies on the output, decision, or state of another.

Even the most meticulously architected Delivery Plan will fail if the programme lacks the resources to execute its commitments or fails to master the intricate web of interdependencies connecting projects to the outside world. In complex enterprise transformations, projects rarely fail due to technical incompetence within an isolated work package; they fail because two projects collided over the same scarce specialist, a supplier delivered hardware six months late, or the business was physically incapable of absorbing a new IT system during its peak trading season.

In MSP 5th edition, Resource Management and Dependency Management are treated as inseparable disciplines within the Structure theme. Programme leadership must actively orchestrate resources across multi-project portfolios while mapping and stress-testing dependency paths.

---

Resourcing Complex Programmes: Beyond Headcount

In MSP, resourcing is not simply an HR exercise in hiring project team members. Programmes require a multi-dimensional blend of physical, human, financial, and digital assets:

                               PROGRAMME RESOURCES
       ┌───────────────────────────────┼───────────────────────────────┐
       │                               │                               │
       ▼                               ▼                               ▼
[ HUMAN ASSETS ]              [ FINANCIAL ASSETS ]            [ PHYSICAL & DIGITAL ]
- Leadership (SRO/BCMs)       - Capital Expenditure (Capex)   - Staging/Testing Labs
- Technical Specialists       - Operational Transition (Opex) - Specialized Hardware
- Operational SMEs            - Contingency / Buffer Funds    - Software Licenses
- External Consultants        - Dual-Running Subsidies        - Data Migration Tools

1. The Human Resource Ecosystem

Transformational change requires specialized leadership and operational roles that must work in unison:

• Governance Leaders: The Senior Responsible Owner (SRO) provides strategic direction; the Programme Manager directs operational delivery; the Business Change Managers (BCMs) safeguard business-as-usual and drive operational adoption.
• Project Delivery Teams: Project Managers, software engineers, systems architects, and construction leads focused on producing technical deliverables.
• Subject Matter Experts (SMEs): Frontline operational personnel (e.g., senior nurses, credit underwriters, air traffic controllers) whose deep institutional domain knowledge is essential for designing workable solutions.
• Change Champions & Trainers: Embedded operational staff who coach peers, alleviate cultural anxiety, and drive behavioral change across operational departments.

2. Sourcing Strategy: Internal Personnel vs. External Partners

A critical responsibility within the Resourcing Approach is balancing internal staffing against external commercial procurement:

[!TIP] The Knowledge Retention Mandate: A recurring theme on the MSP exam is ensuring that external partner engagements include explicit contractual requirements for knowledge transfer. An MSP programme must never conclude with the organization unable to operate, maintain, or evolve its new capabilities because technical know-how was monopolized by external consultants.

---

Managing Resource Contention and Skill Bottlenecks

In any multi-project programme, projects will inevitably compete for the same scarce, high-demand resources. Typical bottlenecks include Enterprise Cybersecurity Architects, Lead Cloud Migration Engineers, Regulatory Compliance Officers, and Specialized Testing Environments.

                    [ SCARCE ENTERPRISE RESOURCE ]
                 (e.g., Lead Cybersecurity Architect)
                                  │
         ┌────────────────────────┴────────────────────────┐
         ▼                                                 ▼
   [ PROJECT ALPHA ]                                 [ PROJECT BETA ]
Requires Security Audit                           Requires Security Audit
  (Weeks 14 to 18)                                  (Weeks 16 to 20)
         │                                                 │
         └────────────────► [ CONTENTION ] ◄───────────────┘
                                  │
                    ▼───────────────────────────▼
                    PROGRAMME GOVERNANCE DECISION
                    - Critical Path Priority?
                    - Resource Leveling / Smoothing?
                    - Schedule Re-sequencing?

Programme-Level Mechanisms for Resolving Contention

When Project Manager A and Project Manager B clash over resource availability, the dispute cannot be left to informal negotiations between project managers. The Programme Manager and PMO apply structured leveling techniques:

1. Critical Path Prioritization: The Programme Manager assesses which project deliverable sits on the overarching programme critical path. The project on the critical path receives top priority, because any delay to its completion directly delays the tranche review gate or benefits realization.
2. Resource Leveling: Delaying the start date or extending the duration of non-critical project tasks within their available schedule float to eliminate peak over-allocations.
3. Resource Smoothing: Re-allocating tasks across time so that resource demand remains within predefined capacity limits without altering the overall project completion milestone.
4. Capacity Planning & Heat Maps: The PMO maintains a 12-month rolling skills heat map that tracks committed hours versus available hours for critical specialist roles, identifying bottlenecks months before they trigger project delays.
5. Executive Escalation to SRO: If resource constraints cannot be leveled without breaching programme time or cost tolerances, the Programme Manager presents an Exception Report to the SRO, recommending options such as procuring external contractor capacity, re-sequencing projects, or descoping non-essential deliverables.

---

Categorizing Dependencies in MSP: Internal, External, and Operational

One of the most heavily tested areas of the Structure theme is the classification of dependencies. MSP 5th edition categorizes dependencies into three distinct types based on their boundary and sphere of managerial control:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE THREE MSP DEPENDENCY CATEGORIES                     │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. INTERNAL DEPENDENCIES   : Project A Output ──► Project B Prerequisite   │
│     (Inside Programme)        (Within Programme Manager's Direct Control)   │
│                                                                             │
│  2. EXTERNAL DEPENDENCIES   : Legislative Mandate / Vendor Delivery         │
│     (Outside Programme)       (Requires Risk Management & Stakeholder Care) │
│                                                                             │
│  3. OPERATIONAL DEPENDENCIES: BAU Peak Season Blackout / Staff Readiness    │
│     (Business as Usual)       (Governed by BCMs & Operational Absorption)   │
└─────────────────────────────────────────────────────────────────────────────┘

1. Internal Dependencies

• Definition: Dependencies between projects, work streams, and activities that exist strictly within the programme boundary and fall under the direct authority of the Programme Manager.
• Examples:
  • Project Beta (Mobile Banking App) cannot execute user integration testing until Project Alpha (Core API Gateway) completes its production deployment.
  • The Business Change team cannot begin frontline teller training until Project Gamma delivers the finalized user interface and training sandbox.
• Management Approach: Managed directly by the Programme Manager through the Delivery Plan, the dependency register, and weekly project integration meetings.

2. External Dependencies

• Definition: Dependencies connecting the programme to initiatives, organizations, or events outside the programme's direct governance boundary.
• Examples:
  • A national regulatory authority enacting a mandatory data privacy directive by a fixed calendar date.
  • An enterprise-wide corporate cloud migration managed by a central corporate IT department outside the programme's control.
  • An international hardware supplier delivering specialized network sensors subject to global supply chain delays.
• Management Approach: Because the Programme Manager lacks direct authority over external entities, these dependencies are managed through robust risk management, commercial contracts with penalty clauses, service level agreements (SLAs), and executive stakeholder engagement led by the SRO.

3. Operational Dependencies

• Definition: Dependencies linking programme transition activities to the operating cycles, readiness, and change absorption capacity of business-as-usual (BAU) departments.
• Examples:
  • A retail bank transformation cannot execute a core banking cutover during the high-volume Christmas shopping blackout period.
  • Hospital clinical staff cannot be pulled from intensive care units for electronic health record training during the peak winter influenza surge.
  • A corporate ERP cutover requires financial accounting teams to have successfully closed and audited annual fiscal accounts first.
• Management Approach: Owned and coordinated primarily by the Business Change Managers (BCMs), who monitor operational readiness and ensure that project cutover windows align with business change capacity.

| Dependency Category | Locus of Control | Primary Risk Factor | Key Management Mechanism | | :--- | :--- | :--- | | Internal | Inside programme boundary; full direct control | Scheduling misalignment between project managers | Delivery Plan, milestone tracking, PMO integration meetings | | External | Outside programme boundary; influence but no direct control | Third-party delays, corporate priority shifts, regulatory changes | Commercial SLAs, risk registers, executive stakeholder lobbying by SRO | | Operational | Operational BAU boundary; collaborative control | Change fatigue, service disruption, operational blackout conflicts | BCM operational readiness audits, seasonal change windows, dual running |

---

Dependency Tracking and Critical Path Analysis at the Programme Level

To manage dependencies effectively, the PMO maintains a live Programme Dependency Register (often displayed as a cross-project dependency matrix). Each dependency record captures:

• Dependency Identifier: Unique tracking code.
• Predecessor (Giver): The project, external supplier, or operational team delivering the prerequisite.
• Successor (Receiver): The project, transition activity, or milestone that requires the prerequisite.
• Nature & Criticality: Internal, external, or operational; classified as High, Medium, or Low impact.
• Interface Date & Float: The scheduled delivery date and the amount of buffer time before successor work is delayed.
• Assigned Owner: The specific manager accountable for monitoring the interface.

The Programme Critical Path

The Programme Critical Path is the longest sequence of dependent activities and milestones through the programme schedule that determines the earliest completion date of a tranche or the overall transformation.

Crucially, on an MSP programme, the critical path does not run exclusively through technical software development or engineering deliverables. In practice, the critical path frequently runs through business change and transition activities—such as workforce consultations, statutory safety certifications, dual-running operational trials, and user adoption milestones. A technical deliverable completed three months ahead of schedule provides zero value if the operational transition activity on the critical path cannot begin until staff are fully retrained.

---

Real-World Organizational Transformation Scenario

Apex Health System Regional Telehealth & Clinical Integration

Context: Apex Health System, operating six regional hospitals and 40 outpatient clinics, launched a $70M clinical transformation programme to deploy unified electronic medical records (EMRs) and regional telehealth services.

The Resourcing Contention: The programme experienced severe contention over Senior Clinical Nurse Specialists. Project 1 (EMR Clinical Workflows) needed 15 nurse specialists to design digital medication order sets. Simultaneously, Project 2 (Telehealth Video Triage) needed 10 nurse specialists for clinical protocol testing. Compounding the crisis, hospital ICU directors demanded that these same nurse specialists remain on the hospital floor due to nursing shortages.

• Resolution: The Programme Manager conducted capacity modeling and determined that Project 1 sat on the programme critical path for Tranche 1, whereas Project 2 could be delayed by four weeks within available float. The SRO approved a dedicated $1.2M budget from programme contingency to hire qualified locum agency nurses, backfilling the clinical specialists on hospital wards and freeing them for the critical path project.

The Dependency Web:

• External Dependency: Delivery of medical video streaming licenses from an overseas cloud vendor, subject to strict national data privacy compliance approval.
• Internal Dependency: Project 2 (Telehealth App) could not launch its pilot until Project 1 (EMR Core) opened its patient medication API.
• Operational Dependency: The rollout of mobile clinical tablets to emergency ward nurses was barred during the winter seasonal respiratory virus surge (November to January blackout).

By systematically tracking these dependencies, the PMO preserved the Tranche 1 critical path, avoiding both hospital operational disruption and costly regulatory fines.

---

Exam Tips & Common Traps

• Exam Tip (The Scope of Critical Path): In MSP Foundation questions, remember that the programme critical path frequently includes operational readiness, staff training, and business transition activities, not merely project engineering work packages.
• Exam Tip (Distinguishing Dependency Types): When analyzing scenario questions:
  • If the dependency is on a supplier or event outside the programme's governance authority (like a new law or corporate cloud build), it is External.
  • If the dependency is between two projects inside the programme, it is Internal.
  • If the dependency involves business trading cycles, operational absorption, or staff readiness, it is Operational.
• Common Trap (Informal Negotiation Fallacy): A common distractor suggests that when two projects compete for the same critical resource, the project managers should settle it between themselves through compromise. In MSP, resource contention must be resolved systematically at the programme level based on critical path priorities and tranche objectives.
• Common Trap (Treating External Dependencies as Risks Only): While external dependencies carry high risk, they must be formally logged in the Dependency Register with specific interface dates and assigned owners, not merely buried in a risk log.