PMP Critical Path and Dependencies

PMP® in Action (Part 4): The Invisible Chain – Managing Critical Path

Section 1: The “Monday Morning” Wall

It was 9:00 AM in Delhi, and the 7Pro ODC was finally quiet. The chaotic weekend of “Sprint 0” was behind them, and the team was ready to execute the first commit for the Biometric Gateway. Mohd Tariq leaned into his monitor, ready to push the initial code structure.

Suddenly, a red banner flashed across his terminal: FATAL ERROR: DATABASE DRIVER INCOMPATIBLE. VERSION 8.4 REQUIRED. VERSION 7.2 DETECTED.

“Shakira,” Tariq called out, his voice echoing in the office. “Did the Budapest team run the driver upgrade? Mellissa confirmed it was on her weekend schedule.”

Shakira checked the logs. “Nothing. The last activity from Budapest was Friday evening. Mellissa is offline, and Rob Miller’s Slack status just changed to a ‘Palm Tree’ emoji. He’s on vacation in the Caribbean for the next ten days.”

The room went cold. The Biometric Gateway was the Critical Path for the entire month. Without that driver, 7Pro was standing on a track where the rails hadn’t been laid.


Section 1 Breakdown: The PMP & ITIL Lens

  1. Critical Path Method (CPM): In PMP, the Critical Path is the longest sequence of activities that must be finished on time for the entire project to complete. If a task on this path (the DB upgrade) is delayed, the entire project finish date slips. There is Zero Float here.
  2. Resource Calendar: This was a failure of the Resource Calendar. PMP requires us to track when key human resources (Rob Miller) are available. His vacation was a “Known” event that wasn’t integrated into the technical timeline.
  3. Impediment/Blocker: In Agile, this is a “Hard Blocker.” The team cannot “work around” an incompatible database driver. Velocity is now at a standstill.

Section 2: The “Shadow” Dependency

Kapil Mehta walked into the ODC, sensing the tension. He didn’t need to look at the screen to know something was wrong.

“Tariq,” Kapil said, looking at the error log. “We mapped ‘Server Access’ as a requirement, but we didn’t map ‘Database Versioning’ as an external dependency. It was a shadow dependency—invisible until it broke the chain.”

Kapil immediately opened a bridge call to Tim John in Norwalk. It was late Sunday night for Tim, but the “High Urgency” alert on his phone did its job.

“Tim, we’ve hit a wall,” Kapil said. “We have 10 developers sitting idle because the Budapest database hasn’t been upgraded. Rob is on vacation, and Mellissa won’t move without his ‘Accountable’ sign-off in ServiceNow. Our Sprint is effectively dead on day one.”

“Rob told me the environment was ‘Ready’,” Tim’s voice was sharp. “I didn’t authorize a vacation that would stall the project.”

“It’s an External Dependency,” Kapil explained. “Rob thought the versioning could wait; we knew it couldn’t. Right now, we need a Proxy—someone with the authority to bypass the hierarchy.”


Section 2 Breakdown: The PMP & ITIL Lens

  1. Mandatory vs. External Dependencies: * Mandatory: You cannot code against a database that doesn’t support the driver (Hard Logic).
    • External: The upgrade is controlled by a team (Budapest) outside the project’s direct influence.
  2. The Issue Log: The moment the error appeared, this moved from the Risk Register (potential) to the Issue Log (active).
  3. Stakeholder Engagement: This highlights the danger of “Silent Stakeholders.” Rob Miller’s absence is now the biggest risk to Tim John’s ROI.

Section 3: The Proxy and the High-Risk Workaround

Tim John wasn’t a man who accepted “idle time” on his budget. Within minutes of Kapil’s alert, a three-way bridge was established between Delhi, Norwalk, and Mexico City.

Daniel Silva,” Tim’s voice was firm. “You’re the Load Balancer lead in Mexico, but you have ‘Admin’ rights to the Budapest staging cluster from the migration last year. I’m appointing you as the Proxy Accountable for Rob Miller while he’s off the grid.”

Daniel hesitated. “Tim, I have the credentials, but I haven’t touched the version 8.4 schema. If the migration script fails, I don’t have Rob to roll it back. This is a massive risk to the staging environment.”

Mohd Tariq saw the opening. “Daniel, what if we run a Simulation? We have a local ‘Sandbox’ here in Delhi that mirrors Budapest. You remote into our Sandbox, we run the upgrade together, and we document every ‘Rollback’ step. If it passes here, we move to the live cluster. We turn this Critical Path Blocker into a controlled experiment.”

For the next four hours, the 7Pro ODC turned into a “War Room.” India and Mexico collaborated in real-time to perform a task that should have been finished in New Jersey.


Section 3 Breakdown: The PMP & ITIL Lens

  1. Risk Mitigation (Reduction/Transference): By testing in the Sandbox first, Tariq and Daniel were reducing the impact and probability of a system failure. This is proactive Risk Management.
  2. Virtual Team Management: This is a classic PMP scenario. Using screen-sharing and real-time collaboration to bridge a geographical and knowledge gap when a key resource (Rob) is missing.
  3. Emergency Change (ITIL 4): Since the blocker was stopping an entire Sprint, they followed the Emergency Change path. Tim John acted as the “Emergency Change Advisory Board” (ECAB) to give the formal “Go” signal.

Section 4: The Lesson of the “Invisible Chain”

By 2:00 PM Delhi time, the driver was upgraded. The red error message on Tariq’s console vanished, replaced by a successful connection string. The first commit of Sprint 1 was finally pushed to the repository.

Kapil Mehta sat back and opened the Project Management Plan. He didn’t just want to fix the error; he wanted to fix the system. He added a new section to their governance: “Inter-Project Dependency Matrix.”

“We got lucky today,” Kapil told the team during the afternoon stand-up. “But from now on, we don’t assume ‘Onsite’ is ready just because they say so. We verify the environment 48 hours before the Sprint starts. In a global project, if you can’t see the dependency, you can’t manage the risk. Today, we made the invisible chain visible.”

The “Invisible Chain” hadn’t broken 7Pro—it had forced them to become more integrated than ever.


Section 4 Breakdown: The PMP & ITIL Lens

  1. Work Authorization System: This is a formal PMP concept—a sub-component of the overall project management system that ensures work is done at the right time and in the right sequence.
  2. Lessons Learned Register: Kapil is practicing “Continuous Improvement.” By documenting this failure and creating a “48-hour verification” rule, he is updating the Organizational Process Assets (OPAs) for future sprints.
  3. Quality Assurance (QA): Unlike testing (QC), this was a victory for QA. They improved the process of environment readiness to ensure that technical work could proceed without administrative friction.

Wrapping Up Article 4: The “Invisible Chain”

In the world of global IT, a project plan is only as strong as its weakest dependency. Today, 7Pro learned that technical readiness isn’t just about code—it’s about the Resource Calendar and the Critical Path. When Rob Miller went to the Caribbean, he didn’t just take a vacation; he took the project’s velocity with him. By using a “Proxy” and a “Sandbox Simulation,” the team proved that leadership is about finding a way through the blocker, not just waiting for the person with the keys to come back.


Section 5: Summary – What Did We Learn?

  • Respect the Critical Path: Any delay in a “Zero Float” activity (like a core DB upgrade) will delay the entire project. Always identify your “Must-Haves” before the Sprint starts.
  • Trust, but Verify (Resource Calendars): Never assume an onsite resource is available just because they are on the email thread. Always check the Resource Calendar for upcoming holidays or “Out of Office” statuses.
  • Manage External Dependencies: Use an Inter-Project Dependency Matrix to track what you need from other teams (Budapest/Jersey) and when you need it.
  • Empower the Proxy: When a key stakeholder is unavailable, identify a “Proxy Accountable” (like Daniel) to keep the decision-making loop closed.
  • Emergency Change Control: In ITIL, an emergency doesn’t mean “ignore the rules.” It means “accelerate the rules” through an Emergency CAB or a trusted simulation.

What’s Next in the Series?

The database is fixed, the code is flowing, and the team is finally hitting their stride. But just as the velocity peaks, a new challenge arrives from New Orleans. Jason Vance has a “brilliant new idea” that he wants to add to the current Sprint—without changing the deadline.

Next Episode: Article 5 – The Mid-Sprint Ambush: Fighting Scope Creep. Will Kapil and Tariq say ‘Yes’ to the client and break the team, or say ‘No’ and risk the relationship?

Leave a Reply

Your email address will not be published. Required fields are marked *