Project Scheduling as a Network: Extending Spider Project with Python and NetworkX
The CPM taught us how to find the critical path… but not how to understand the structure of the project. For years, we’ve treated schedules as sequences of activities: Gantt charts, logic, float, performance indicators… and that’s it.
But a schedule is not a list. It’s a network.
💡 This is where a conceptual framework starts to emerge:
And around this… an entire universe of possibilities. A universe where we are no longer limited to traditional indicators, but able to develop new metrics to truly understand schedule behavior.
💡 Recently, I worked on integrating these three components:
Spider Project + Python + NetworkX
Not to replace Spider… but to extend it.
The workflow, in essence, was this:
1. Model and calculate the schedule in Spider Project Preserving its full logic: activities, dependencies, uncertainty, Criticality Index, DRAG, pDRAG, Elasticity.
2. Extract key project tables
3. Process the data in Python Cleaning, structuring, and preparing it for analysis.
4. Reconstruct the project network in NetworkX Each activity becomes a node, each dependency an edge. The schedule stops being a table… and becomes a graph.
5. Enrich the network with Spider indicators Assigning to each node:
6. Analyze the schedule as a system And this is where things get interesting:
Recommended by LinkedIn
📊 What emerged?
👉 Two activities can have the same Criticality Index… and behave completely differently 👉 Some high-impact activities do not dominate the network 👉 Others, with lower impact, are structurally far more influential
💥 In other words:
Criticality is not a single dimension.
At least three layers are at play:
🔍 And this is the key point:
An activity can be critical… but not structurally influential.
And another one may not seem critical… yet it acts as the node that connects everything.
⚙️ This changes the conversation:
We are no longer reading schedules… we are analyzing systems.
🔥 My conclusion:
Spider is the engine. Python is the laboratory. NetworkX is the accelerator.
And the schedule… is far more than what we are used to seeing.
I’m currently exploring this direction further:
If anyone is working along similar lines, I’d be glad to exchange ideas.
On reflection, this is probably also why techniques like GERT never really took off — powerful in theory, but harder to operationalise and communicate in real delivery environments.
Really interesting approach Jair — I like the idea of treating the schedule as a network and exploring criticality beyond a single dimension. That said, I think there’s a balance to strike. Schedules are ultimately models of reality, and in most delivery environments the goal is clarity, alignment, and execution. The simplest model that drives the right behaviour is often the most effective. Where I see real value in your work is as a diagnostic layer — surfacing hidden dependencies, structural weak points, and how risk propagates — rather than replacing the core schedule. Keen to see how you evolve this, especially if it can bridge deeper insight with practical decision-making.
What has changed in recent years is the awareness of advanced methods, not the methods themselves. There have been no real breakthroughs in scheduling over the past five years. A few new metrics have emerged, but they weren’t mentioned in the article. Spider Project have been calculating metrics such as Criticality Index, pDrag, Recovery Gap, and Flex for over a decade. These approaches were presented at conferences like CPM and PMI many years ago. Some communities already use advanced scheduling methods to optimise plans and accelerate delivery, and in some portfolios, this is standard daily practice. What we truly need is to increase awareness and adoption of these capabilities. I’ve published two papers that explain advanced metrics in detail and introduce two additional ones: Activity Spread and Recovery Gap Super. I encourage you to read them, they weren’t included in your overview.