Paper deep dive
Project resilience as network robustness
Sebastiano A. Piccolo, Giorgio Terracina
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 96%
Last extracted: 4/27/2026, 7:27:03 AM
Summary
The paper proposes a novel method to assess project vulnerability, specifically the 'Bus Factor' (the minimum number of personnel whose departure would stall a project), by modeling projects as bipartite graphs. Unlike existing coverage-based methods (MRS and MCS) that rely on arbitrary thresholds and fail to capture project fragmentation, the authors introduce a 'Network Robustness' measure (B_BT). This new measure tracks the size of the Largest Connected Task Component (LCTC) as professionals are removed, providing a domain-agnostic, threshold-free approach. The paper proves that existing measures and the new robustness measure are NP-hard problems and demonstrates through synthetic testing and a real-world case study that the proposed method better distinguishes between adding specialists versus integrators and more accurately reflects structural resilience.
Entities (10)
Relation Signals (5)
Sebastiano A. Piccolo → affiliatedwith → University of Calabria
confidence 100% · Sebastiano A. Piccolo 1,* , Giorgio Terracina 1 1 University of Calabria
Network Robustness → measures → Largest Connected Task Component
confidence 100% · We monitor the size of the Largest Connected Task Component (LCTC) as professionals are removed.
Bus Factor → modeledas → Bipartite Graph
confidence 100% · We model a project as a bipartite graph connecting professionals to their tasks
Maximum Redundant Set → isatypeof → Bus Factor
confidence 90% · We formulate them as two complementary combinatorial problems: the Maximum Redundant Set (MRS)...
Maximum Redundant Set → isatypeof → Bus Factor Measure
confidence 90% · We compare our method against existing alternatives... Maximum Redundant Set (MRS)... Minimum Critical Set (MCS)
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Engineering projects are the result of the combined effort of their members. Yet, it has been documented that labor division withing projects is unevenly distributed: some project members are specialists undertaking only few tasks, whereas other are generalists and are responsible for the success of many tasks. Moreover, the latter are often facilitators of project integration. Such a workload distribution prompts one question: how resilient is a project to key personnel loss? Far from being a theoretical problem, the reliance of a project on a few key people can lead to severe economic losses and delays. We argue that current methods to estimate such a risk are unsatisfactory: some methods offer a best-case estimate and are, therefore, too optimistic; other methods fail to capture project fragmentation leading to biased estimates and unrealistic consequences in many settings. In this paper, we develop a novel method to assess project vulnerability by looking at it from the lens of network robustness. We compare our method against existing alternatives and show that it offers better and more consistent estimates of project resilience to personnel loss.
Tags
Links
- Source: https://arxiv.org/abs/2604.17417v1
- Canonical: https://arxiv.org/abs/2604.17417v1
Trouble viewing inline? Open PDF directly →
Full Text
33,595 characters extracted from source content.
Expand or collapse full text
Project resilience as network robustness ⋆ Sebastiano A. Piccolo 1,* , Giorgio Terracina 1 1 University of Calabria, Department of Mathematics and Computer Science (DeMaCS) Abstract Engineering projects are the result of the combined effort of their members. Yet, it has been documented that labor division withing projects is unevenly distributed: some project members are specialists undertaking only few tasks, whereas other are generalists and are responsible for the success of many tasks. Moreover, the latter are often facilitators of project integration. Such a workload distribution prompts one question: how resilient is a project to key personnel loss? Far from being a theoretical problem, the reliance of a project on a few key people can lead to severe economic losses and delays. We argue that current methods to estimate such a risk are unsatisfactory: some methods offer a best-case estimate and are, therefore, too optimistic; other methods fail to capture project fragmentation leading to biased estimates and unrealistic consequences in many settings. In this paper, we develop a novel method to assess project vulnerability by looking at it from the lens of network robustness. We compare our method against existing alternatives and show that it offers better and more consistent estimates of project resilience to personnel loss. Keywords Network robustness, Bipartite graphs, Project resilience, Bus Factor 1. Introduction Engineering projects are a quintessential example of collective problem solving, combining the efforts of professionals with diverse skill-sets. Due to the nature of the project itself, the diversity of technical skills involved, and the heterogeneity of requirements, the labor distribution observed in projects is highly skewed: a relatively small number of professionals undertake a large number of tasks, while the vast majority are responsible for a limited number of tasks [1,4,5,6]. These types of professionals have respectively been termed generalists and specialists [1, 7]. Such a workload distribution may render a project vulnerable to the loss of key personnel, with heavy consequences including delays, economic losses, and service or infrastructure disruptions that propagate beyond the project itself [1,8,9]. This vulnerability has been named Bus Factor (or Truck Factor), informally defined as the minimum number of professionals whose departure from a project would stall it [10, 11, 12]. There is ample evidence of the Bus Factor and its severe consequences. Theleft-padincident is emblematic: a developer unpublished a small package (left-pad) of just 11 lines of code, breaking the dependencies of a substantial part of the JavaScript ecosystem (including Babel, Webpack, and React) 1 . Additionally, studies on open source communities have shown that when a central contributor leaves, community cohesion, performance, and bug handling suffer dramatically until others step up [8,9]. Furthermore, it has been found that core developers (termed heroes) are often more productive and introduce fewer bugs than others [5, 6]. In light of the serious damage a project with a low Bus Factor can incur, it is of paramount importance to have reliable methods to evaluate robustness [1,2,10,12]. A good measure of Bus Factor not only estimates vulnerability but can be used to drive intervention strategies and optimize the allocation of people to tasks [2]. SEBD 2026 ⋆ This paper is a discussion paper describing the research originally presented in [1, 2, 3]. * Corresponding author. $ sebastiano.piccolo@unical.it (S. A. Piccolo); giorgio.terracina@unica.it (G. Terracina) 0000-0002-6986-3344 (S. A. Piccolo); 0000-0002-3090-7223 (G. Terracina) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (C BY 4.0). 1 More details on the left-pad incident at: https://en.wikipedia.org/wiki/Npm_left-pad_incident 푝 1 푡 4 푝 2 푝 3 푡 2 푝 6 푝 7 푡 1 푝 5 푝 4 푝 8 푡 3 푝 9 푝 1 푡 4 푡 2 푡 1 푡 3 B) Maximum Redundant Set Maximumnumberofpeoplethatcanbe removedwithoutuncoveringmorethan50% oftasks. 푡 4 푝 2 푝 3 푡 2 푡 1 푡 3 C) Minimum Critical Set Minimumnumberofpeoplethat,once removed,leavetheprojectwithmore than50%oftasksuncovered. D) Bus-factor as Network Robustness Normalizedareaunderthedecaycurveofthesizeofthe connectedcomponentcontainingthelargestnumberof tasks. MRS = 8 MCS = 7 Removing푝 1 reducesthecomponentconnectingthelargestnumberof tasksfromfourtaskstoone(D2).Thus,푝 1 doesnotmerelycoverfour tasks;푝 1 isanintegrator,whoseabsenceharmstheprojectmorethan anyotherindividual. Thispropertyiscapturedbymeasuringthelargestnumberoftasksina singlecomponentaspeopleareremovedfromthegraph(thebluedecay curveinD1),whichcanbecomparedtothetheoreticalbestpossible(gray curveinD1). The ratio of the areas under these curves gives us a normalized measure of bus-factor, ℬ. For the project in A) this is: 퓑= 0.25 Stated differently, the bus-factor of this project is 2.25 people. 4 9 # people removed # connected tasks project decay curve theoretical maximum A) Bipartite graph of the project 푝 1 푡 4 푝 3 푝 2 푡 2 푝 6 푝 7 푡 1 푝 5 푝 4 푝 8 푡 3 푝 9 D1) D2) Figure 1: Comparison of the Bus Factor measures formalized as combinatorial problems on bipartite graphs. Unfortunately, as we show, the available methods to estimate Bus Factor suffer from severe short- comings: 1) they are often not generally applicable, being tailored to specific metadata (e.g., GitHub); 2) they depend on arbitrary thresholds to define stalling conditions; 3) they fail to capture the resulting project fragmentation when key personnel leave; and 4) they imply consequences that contrast with empirical findings from project management (for instance, overestimating the impact of experts while downplaying the role of generalists). In this paper, we present a novel measure of Bus Factor, that is domain-independent, threshold-free, and able to account for project fragmentation. We model a project as a bipartite graph connecting professionals to their tasks, formulating the Bus Factor as a combinatorial problem. This modeling approach allows us to generalize existing Bus Factor estimation procedures. We formulate them as two complementary combinatorial problems: the Maximum Redundant Set (MRS), seeking the maximum set of people that can be safely removed; and the Minimum Critical Set (MCS), seeking the minimum set of people whose removal uncovers a target number of tasks. Consequently, we formulate our new measure as a third combinatorial problem, Robustness, which seeks the removal order of people that minimizes the area under the curve describing the size of the largest connected task component. As a result, we make all Bus Factor measures comparable by fixing their input graph. Figure 1 provides an intuitive comparison of the Bus Factor measures. Summary of contributions. We make the following contributions: 1. We model projects as bipartite graphs and derive a unifying framework that formulates Bus Factor measures as combinatorial problems of node removal. 2.We formulate a novel measure of Bus Factor that overcomes the shortcomings of existing formu- lations. 3. We prove that all Bus Factor formulations are NP-Hard and develop efficient approximation algorithms for each. 4.We provide an extensive analysis and comparison of the Bus Factor measures through a series of tests guided by project management theory. 5.We apply our measure to a real-world project to guide a re-allocation of people to tasks, improving its Bus Factor by 40%. Together, our contributions provide both theoretical foundations and scalable algorithms for analyzing and mitigating project vulnerability. 2. Related Work The impact of low Bus Factor. Ample evidence suggests that projects with low Bus Factor face severe risks [10,11,12,13,14,15]. Empirical studies consistently show that core developers (termed heroes) are more productive and introduce fewer bugs [5,6]. Crucially, the turnover of these key personnel is followed by a reduction in code quality and slower bug fixing [8,9,13,14,15]. In extreme cases, projects fail to survive the loss entirely [12]. Prior Bus Factor assessment methods.Bus Factor estimation has been researched most prominently in software engineering [4,10,11,12,16]. Despite its intuitive definition, prior work differs substantially in how projects are modeled and how stalling is defined. Zazworka et al. [10] introduced a family of coverage-based measures, defining a project as safe if a given percentage of files (e.g., 50%) remains covered after contributor removal. While conceptually appealing, this approach does not explicitly model developer knowledge [17, 18]. Subsequent work refined knowledge inference. Cosentino et al. [11] introduced primary and sec- ondary developers based on contribution thresholds. Most notably, Avelino et al. [12] proposed a greedy heuristic that iteratively removes the most knowledgeable developer (measured via Degree of Authorship) until more than 50% of files become abandoned. This heuristic has become the standard in follow-up studies [16, 18]. Critical Analysis.Current approaches mix two distinct concerns: 1) inferring developer knowledge from metadata (the filtering stage); and 2) identifying the set of core developers (the estimation stage). By conflating these stages, prior methods rely on domain-specific heuristics rather than formal combina- torial optimization. This realization drives our proposal: a domain-agnostic framework that decouples estimation from filtering, allowing for a rigorous graph-theoretic treatment of the Bus Factor. 3. A domain-agnostic framework We model a project as a bipartite graph퐵 = (푃,푇,퐸), where푃is the set of professionals (people), 푇is the set of tasks (or artifacts), and an edge(푝,푡)∈ 퐸exists if professional푝contributes to task푡. This set푇is semantic-agnostic: it can represent source files, functions, or Jira tickets, provided that all elements in 푇 share the same granularity. Notation and preliminaries.For a graph퐺 = (푉,퐸), the neighborhood of a vertex푣 ∈ 푉, denoted 푁 (푣), is the set of vertices adjacent to푣, and the degree of푣isdeg(푣) = |푁 (푣)|. In our bipartite context, for a professional푝 ∈ 푃,푁 (푝) ⊆ 푇is the set of tasks they work on. Conversely, for a task 푡∈ 푇,푁 (푡)⊆ 푃is the set of professionals capable of performing it. We extend this notation to sets: for a subset of professionals푆 ⊆ 푃, the coverage of푆, denotedCov(푆), is the set of all tasks performed by at least one person in 푆: Cov(푆) = ⋃︀ 푝∈푆 푁 (푝). A task푡is considered active (or covered) with respect to a team푆if푡 ∈ Cov(S); otherwise, it is abandoned. A subgraph induced by푆 ⊆ 푉is denoted퐺[푆]. A connected component is a maximal connected subgraph. A vertex cover is a subset푉 ′ ⊆ 푉such that every edge of퐺is incident to at least one vertex in 푉 ′ . To analyze the complexity of Bus Factor measures, we recall the following classical NP-hard decision problems [19]: Set Cover: Given a universe푈, a familyℱof subsets of푈, and an integer푘, does there exist a subfamily풞 ⊆ℱ with|풞|≤ 푘 such that ⋃︀ 푆∈풞 푆 = 푈 ? Clique: Given a graph퐺and integer푘, does퐺contain a fully connected subgraph of size at least푘? Vertex Cover: Given a graph 퐺 and integer 푘, does 퐺 contain a vertex cover of size at most 푘? Unifying Existing Measures. We now formalize existing Bus Factor measures as combinatorial problems on the bipartite graph퐵. Zazworka et al. [10] approached the problem by assessing redun- dancy—asking: what is the largest set of people we can remove while keeping at least a fraction훿of tasks covered? This leads to two distinct formulations based on whether we remove the least critical people (Best-Case) or the most critical people (Worst-Case): 푍 푏푒푠푡 (퐵,훿) = max푘 |∃푆 ⊆ 푃,|푆| = 푘 :| Cov(푃 ∖ 푆)|≥ 훿|푇|(1) 푍 푤표푟푠푡 (퐵,훿) = max푘 |∀푆 ⊆ 푃,|푆| = 푘 :| Cov(푃 ∖ 푆)|≥ 훿|푇|(2) 푍 푏푒푠푡 essentially measures the maximum redundant workforce, while푍 푤표푟푠푡 measures the project’s resilience against the random loss of any 푘 employees. In contrast, Cosentino et al.[11] and Avelino et al.[12] emphasized criticality, defining the Bus Factor as the minimum number of people whose removal causes the project to stall (coverage drops below훿). We formalize this as: 퐴(퐵,훿) = min|푆| : 푆 ⊆ 푃 ∧| Cov(푃 ∖ 푆)| < 훿|푇|(3) This formalization reveals a direct link between these seemingly distinct metrics. Specifically, it is straightforward to verify that푍 푤표푟푠푡 (퐵,훿) = 퐴(퐵,훿)− 1. That is, the Bus Factor (퐴) is simply the threshold at which the project’s worst-case resilience (푍 푤표푟푠푡 ) breaks. This insight allows us to discard the specific ad-hoc heuristics used in prior work and subsume all definitions under two complementary combinatorial problems: MRS (Maximum Redundant Set) and MCS (Minimum Critical Set). We define the problems below and provide proof sketches for their NP-hardness, referring the reader to [3] for full formal proofs. Finally, we describe an effective approximation algorithm for each of them. Definition 1 (Maximum Redundant Set). Given a bipartite graph퐵 = (푃,푇,퐸)and0 < 훿 ≤ 1, MRS seeks the largest set 푆 ⊆ 푃 such that| Cov(푃 ∖ 푆)|≥ 훿|푇|. Theorem 1. MRS is NP-hard. Proof idea.This is equivalent to Set Cover. For훿 = 1, finding the largest set푆to remove is equivalent to finding the smallest set 푋 = 푃 ∖ 푆 to keep such that 푋 covers all tasks in 푇 . Approximation. Since MRS is equivalent to Partial Set Cover, we employ the classic greedy strategy: iteratively select the professional푝∈ 푃who covers the largest number of currently uncovered tasks, until the number of covered tasks is at least훿|푇|. The complement of this set is our approximate MRS. Definition 2 (Minimum Critical Set). Given a bipartite graph퐵 = (푃,푇,퐸)and0 < 훿 ≤ 1, MCS seeks the smallest set 푆 ⊆ 푃 such that| Cov(푃 ∖ 푆)| < 훿|푇|. Theorem 2. MCS is NP-hard. Proof idea.This can be proven via reduction from Clique. Given a graph퐺 = (푉,퐸 ′ ), we construct a bipartite graph퐵 = (푃,푇,퐸)where푃 = 푉,푇 = 퐸 ′ , and edges represent incidence. A task푡∈ 푇(an edge in퐺) is abandoned if and only if both its endpoints are removed. Thus, finding a set푆of size푘 that causes the abandonment of (︀ 푘 2 )︀ tasks is equivalent to finding a clique of size푘in퐺. By setting훿 such that the allowed remaining tasks are fewer than|푇|− (︀(︀ 푘 2 )︀ − 1 )︀ , MCS solves Clique. Approximation. For MCS, we employ a greedy removal strategy based on node degree. In each step, we remove the professional푝 ∈ 푃with the highest degree (number of active tasks). We repeat this until the number of remaining covered tasks falls below훿|푇|. While simple, this heuristic aligns with the intuition that high-degree nodes (generalists) are critical failure points. 3.1. Proposed Measure: Bus Factor as Robustness We now introduce our novel measure, designed to address the structural limitations of prior formulations. Existing measures like MCS and MRS treat professionals solely as resources, ignoring the topology of collaboration. Specifically, they fail to capture fragmentation: the scenario where a project doesn’t just stop, but shatters into isolated, non-communicating silos. Furthermore, they rely on arbitrary thresholds (e.g., 훿 = 0.5) that may not reflect the reality of a specific project. To overcome these limitations, we redefine Bus Factor based on network robustness [20]. We monitor the size of the Largest Connected Task Component (LCTC) as professionals are removed. Let휏 (퐵)denote the size of the LCTC in a graph퐵. We define the robustness of a project퐵 = (푃,푇,퐸)under a specific removal sequence휋 ∈ Π(푃 )of the professionals in푃. Let퐵 휋 푖 be the graph surviving after removing the first푖professionals in휋. We compute the area under the decay curve using the trapezoidal rule and normalize it against the theoretical maximum (a fully connected graph). The normalized robustness for a removal sequence 휋 is: ℬ(퐵,휋) = 2 |푇|(2|푃|− 1) |푃| ∑︁ 푖=1 [︀ 휏 (︀ 퐵 휋 푖−1 )︀ + 휏 (퐵 휋 푖 ) ]︀ (4) This valueℬ ∈ [0, 1]represents the percentage of the collaborative potential preserved during the removal sequence. To capture the worst-case scenario, we define the project’s Bus Factor as the robustness under the most destructive removal sequence: ℬ 퐵퐹 (퐵) = min 휋∈Π(푃 ) ℬ(퐵,휋)(5) Computational Complexity. In order to prove the hardness of the problem, we first formalize the structural shattering of a project using the concept of a Backbone Set. Definition 3 (Backbone Set). Given a bipartite graph퐵 = (푃,푇,퐸), a set푆 ⊆ 푃is a Backbone Set if the subgraph induced by removing푆consists solely of disconnected stars, where each star is centered on a professional 푝∈ 푃 ∖ 푆. Intuitively, removing a backbone set destroys all collaborative paths between professionals, isolating every remaining person. Note that for any removal sequence휋 ∈ Π(푃 )the last removal leaves an empty graph, contributing zero toℬ(퐵,휋). Therefore,ℬ(퐵,휋)is fully determined by the first|푃|− 1 removals. After these|푃|− 1removals only one professional remains, and therefore the removed set forms a backbone set. Consequently, computingℬ 퐵퐹 (퐵)amounts to selecting a backbone set of|푃|− 1 professionals (and their order) that collapses the graph most efficiently. We can thus formalize the robustness decision problem in terms of backbone sets: Definition 4 (Robustness Decision Problem). Given a bipartite graph퐵 = (푃,푇,퐸), an integer푘, and a threshold0 < 푀 ≤ 1, does there exist a backbone set of size푘with an associated removal sequence휋 such thatℬ(퐵,휋)≤ 푀 ? Theorem 3. The Robustness Decision Problem is NP-hard. Proof Sketch. We reduce from Vertex Cover. Given an undirected graph퐺 = (푉,퐸 ′ ), we construct the bipartite incidence graph퐵 = (푃,푇,퐸)where푃 = 푉and푇 = 퐸 ′ (tasks represent edges). We prove hardness even for the special case where the threshold is vacuous (e.g.,푀 = 1). In this case the decision problem reduces to determining whether a backbone set of size 푘 exists. (⇒) If퐺has a vertex cover푆of size푘 ≤ |푉|, since푆covers all edges in퐺, removing푆in퐵 disconnects every task from at least one endpoint. The graph퐵[푃 ∖ 푆]thus becomes a collection of disconnected stars (and therefore 푆 is a backbone set). (⇐)Conversely, if no vertex cover of size푘exists in퐺, then for any set of푘professionals in퐵, there remains at least one edge in퐺that is not covered. In퐵, this corresponds to a task푡that still connects two professionals. Thus, no backbone set of size푘exists in퐵. As such, solving the Robustness Decision Problem decides Vertex Cover. Figure 2: Sensitivity of Bus Factor measures to changes in network density (RQ1). A) Densification: MCS and ℬ 퐵퐹 increase with network density, as expected. Inset: values of MCS andℬ 퐵퐹 expressed as number of people. B) Sparsification: MCS andℬ 퐵퐹 decrease with network density, as expected. Inset: a zoomed-in view of the range [5000, 10000] edges removed, showing thatℬ 퐵퐹 is more stable than MCS. Approximation.Since the exact calculation is NP-hard, we approximateℬ 퐵퐹 using a greedy strategy. We define the removal order휋by sorting professionals푝∈ 푃in decreasing order of their degree. To compute the area efficiently for large graphs, we employ a Union-Find data structure and simulate the removal process in reverse (starting from an empty graph and adding nodes back). This allows us to track component sizes dynamically, ensuring the evaluation is nearly linear in the number of edges. For implementation details, we refer the reader to our prior work [2, 3]. 4. Experimental Evaluation While empirical evaluations on open-source repositories provide real-world context, they often lack the granularity required to rigorously assess the sensitivity of a metric. In addition, many projects exhibit a trivial Bus Factor of 1 (as noted by Avelino et al. [12]), making them unsuitable for rigorous tests. To overcome this, and to evaluateℬ 퐵퐹 under controlled conditions, we conduct a sensitivity analysis on synthetic bipartite graphs. Experimental Setup.We generated a set of synthetic bipartite graphs exhibiting power-law degree distributions, consistent with the heavy-tailed nature of the workload distribution in real projects [1,4, 5,6]. Our baseline graphs consist of|푃| = 7500professionals and|푇| = 10000tasks. We subject these graphs to controlled structural perturbations that mimic specific managerial actions (e.g., changing workload, hiring staff ), and compare the behaviors ofℬ 퐵퐹 , MCS, and MRS. For MCS and MRS, we set the threshold훿 = 0.5, in continuity with prior research [10,12]. We investigate two research questions: RQ1: How do metrics respond to changes in workload distribution? RQ2: How do metrics differentiate between adding specialists versus integrators? Sensitivity to Workload Distribution (RQ1). We first investigate how the metrics respond to variations in task assignment density. We simulate this by adding and removing edges from the generated graphs. Intuitively, a valid robustness measure should correlate positively with network density: more shared tasks imply higher redundancy. We simulate this by adding and removing edges from the generated graphs in batches of 100, up to a total of 50000 modifications. As shown in Figure 2, MRS is insensitive to changes in density. This is a consequence of its optimistic definition(1). MCS andℬ 퐵퐹 , instead, exhibit the desired behavior, although MCS shows significant artifacts. During densification (Fig. 2A), MCS saturates rapidly and plateaus, a direct consequence of its fixed coverage threshold. Conversely, during sparsification (Fig. 2B), MCS exhibits oscillations as the removal of edges alters node degrees and shifts the critical set. In contrast,ℬ 퐵퐹 scales smoothly and monotonically. Figure 3: Sensitivity of Bus Factor measures to personnel redundancy (Q2). A) Sensitivity to singletons. B) Sensitivity to duplicates. In the inset: values of MCS andℬ 퐵퐹 expressed as number of people. Becauseℬ 퐵퐹 measures connected components rather than simple coverage, it accurately reflects the gradual degradation or improvement of the project structural integrity without threshold-induced instability. Sensitivity to Personnel Redundancy (RQ2).A robust metric must distinguish between headcount and structural resilience. We simulate two distinct hiring strategies to test this distinction: 1. Adding Singletons: Adding specialists who work on a single task (one specialist per task). 2.Adding Duplicates: Cloning existing contributors (in decreasing order of degree) to increase backup potential. The Singleton Problem. A critical flaw in coverage-based metrics is their inability to distinguish between resources and structure. As shown in Figure 3A, both MCS and MRS grow indefinitely as singletons are added. This implies that a project can be made infinitely robust simply by hiring isolated specialists, contradicting established project management theory [1,6,7,21,22].ℬ 퐵퐹 avoids this pitfall. It correctly identifies that singletons do not bridge structural gaps. In fact,ℬ 퐵퐹 decreases slightly, capturing the dilution of the project density and the diminishing returns of adding non-integrating personnel. Integrators vs. Specialists. When adding duplicates (Fig. 3B),ℬ 퐵퐹 again demonstrates superior sensitivity. While MCS eventually saturates,ℬ 퐵퐹 increases rapidly when high-degree integrators are duplicated and plateaus as low degree people are added. This confirms that our topological approach successfully distinguishes between structure and headcount, rewarding the creation of backups for central connectors while correctly identifying the diminishing returns of backing up peripheral people. 5. Case Study: Structural Optimization in Practice To demonstrate the practical utility ofℬ 퐵퐹 beyond mere measurement, we apply it to a real-world project [1,2]. Our goal is not only to evaluate the project’s current structural robustness but to actively prescribe a more resilient task assignment matrix. Baseline Evaluation and Permutation Test.We first evaluate the original personnel-task bipartite network, yielding a baseline robustness of 0.252. To understand if this value is an artifact of the specific degree distribution of the project, we generated a statistical ensemble of 10000 networks using a degree-preserving null model to perform a permutation test. (Figure 4B). Surprisingly, the original Bus Factor of the project is statistically lower than what would be expected from a purely random assignment (푝 = 0.007). This indicates that the project suffers from severe silos that artificially inflate its vulnerability. Figure 4: Comparison of the Bus Factor of a real-world project and its version optimized for robustness, against that of a statistical null model. A: decay curves. B: permutation test. Optimization via Simulated Annealing.To correct this structural vulnerability, we treat the task assignment as an optimization problem. We employ a Simulated Annealing (SA) to iteratively rewire the bipartite graph in order to maximizeℬ 퐵퐹 , while preserving the workload of every person. The computational feasibility is guaranteed by our linear-time Union-Find-based algorithm. As shown in Figure 4A, the SA optimization shifts the decay curve drastically to the right. The opti- mized network,퐵 푆퐴 , achieves a robustness of0.352, a 40% improvement over the original configuration. The permutation test shows that this improvement is statistically significant (Figure 4B). The magnitude of this optimization is clear in the decay curves. In the original network, removing the most connected 20% of people reduces the size of the LCTC to 60% of its original size. In contrast, in the SA-optimized network, removing the exact same number of people barely disconnects the first task. By merely reassigning existing workloads (without hiring new personnel), the project can be structurally hardened against turnover. 6. Conclusion and Future Work In this paper, we challenged the prevailing resource-centric formulations of the Bus Factor. Traditional coverage-based measures, such as the Minimum Critical Set and Maximum Redundant Set, are struc- turally blind: they rely on arbitrary thresholds, fail to capture project fragmentation, and succumb to the Singleton Problem. To overcome these limitations, we introducedℬ 퐵퐹 , a novel metric grounded in bipartite network robustness. By monitoring the decay of the Largest Connected Task Component as people are removed, ℬ 퐵퐹 provides a normalized, continuous, topology-aware measure of collaborative resilience. While finding the optimal removal sequence is NP-hard,ℬ 퐵퐹 can be efficiently approximated in linear time. Beyond accurate measurement,ℬ 퐵퐹 is highly actionable. As demonstrated in our case study, by utilizingℬ 퐵퐹 as a fitness function within a Simulated Annealing framework, we successfully optimized the bus factor of a real-world project, improving its structural robustness by 40% without adding new people or increasing their workload. Future Work.This study paves the way for several promising research directions. First, we plan to extend our framework by allowing it to consider edge and task weights. Second, incorporating temporal network dynamics will enable us to track how project robustness evolves over its lifecycle, potentially serving as an early-warning system for structural decay before the departure of key personnel. Acknowledgments Sebastiano A. Piccolo is grateful to Marco Manna, Simona Perri, and Aldo Ricioppo for helpful comments. This research is partially supported by MUR under PNRR project PE0000013-FAIR, Spoke 9 - Green- aware AI – WP9.2 and PN RIC project ASVIN “Assistente Virtuale Intelligente di Negozio” (CUP B29J24000200005). Declaration on Generative AI During the preparation of this work, the authors used Gemini in order to: Grammar and spelling check. After using this tool, the authors reviewed and edited the content as needed and take full responsibility for the content of the publication. References [1]S. A. Piccolo, S. Lehmann, A. Maier, Design process robustness: a bipartite network analysis reveals the central importance of people, Design Science 4 (2018) e1. [2] S. A. Piccolo, P. De Meo, G. Terracina, Evaluating and improving projects’ bus-factor: a network analytical framework, in: 16th International Conference, ASONAM 2024, Rende, Italy, September 2–5, 2024, Proceedings, Part I, LNCS, Springer, 2024. [3]S. A. Piccolo, P. De Meo, G. Terracina, G. Greco, The theory and practice of computing the bus factor, Information Sciences 743 (2026) 123353. URL: https://w.sciencedirect.com/science/ article/pii/S0020025526002847. doi:https://doi.org/10.1016/j.ins.2026.123353. [4]K. Yamashita, S. McIntosh, Y. Kamei, A. E. Hassan, N. Ubayashi, Revisiting the applicability of the pareto principle to core development teams in open source software projects, in: Proceedings of the 14th International Workshop on Principles of Software Evolution, IWPSE 2015, Association for Computing Machinery, New York, NY, USA, 2015, p. 46–55. URL: https://doi.org/10.1145/2804360. 2804366. doi:10.1145/2804360.2804366. [5]A. Agrawal, A. Rahman, R. Krishna, A. Sobran, T. Menzies, We don’t need another hero? the impact of "heroes" on software development, in: Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice, ICSE-SEIP ’18, Association for Computing Machinery, New York, NY, USA, 2018, p. 245–253. URL: https://doi.org/10.1145/3183519.3183549. doi:10.1145/3183519.3183549. [6]S. Majumder, J. Chakraborty, A. Agrawal, T. Menzies, Why software projects need heroes (lessons learned from 1100+ projects), arXiv preprint arXiv:1904.09954 (2019). [7]S. A. Piccolo, A. M. Maier, S. Lehmann, C. A. McMahon, Iterations as the result of social and technical factors: empirical evidence from a large-scale design project, Research in Engineering Design 30 (2019) 251–270. [8] M. S. Zanetti, I. Scholtes, C. J. Tessone, F. Schweitzer, The rise and fall of a central contributor: Dynamics of social organization and performance in the gentoo community, in: 2013 6th interna- tional workshop on cooperative and human aspects of software engineering (chase), IEEE, 2013, p. 49–56. [9]G. Russo Latona, C. Gote, C. Zingg, G. Casiraghi, L. Verginer, F. Schweitzer, Shock! quantifying the impact of core developers’ dropout on the productivity of oss projects, in: Companion Proceedings of the ACM Web Conference 2024, W ’24, Association for Computing Machinery, New York, NY, USA, 2024, p. 706–709. URL: https://doi.org/10.1145/3589335.3651559. doi:10.1145/3589335. 3651559. [10]N. Zazworka, K. Stapel, E. Knauss, F. Shull, V. R. Basili, K. Schneider, Are developers complying with the process: an xp study, in: Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM ’10, Association for Computing Machinery, New York, NY, USA, 2010. URL: https://doi.org/10.1145/1852786.1852805. doi:10.1145/ 1852786.1852805. [11]V. Cosentino, J. L. C. Izquierdo, J. Cabot, Assessing the bus factor of git repositories, in: 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), 2015, p. 499–503. doi:10.1109/SANER.2015.7081864. [12]G. Avelino, L. Passos, A. Hora, M. T. Valente, A novel approach for estimating truck factors, in: 2016 IEEE 24th International Conference on Program Comprehension (ICPC), 2016, p. 1–10. doi:10.1109/ICPC.2016.7503718. [13]F. Ferreira, L. L. Silva, M. T. Valente, Turnover in open-source projects: The case of core developers, in: Proceedings of the XXXIV Brazilian Symposium on Software Engineering, 2020, p. 447–456. [14]M. Foucault, M. Palyart, X. Blanc, G. C. Murphy, J.-R. Falleri, Impact of developer turnover on quality in open-source software, in: Proceedings of the 2015 10th joint meeting on foundations of software engineering, 2015, p. 829–841. [15] G. Avelino, E. Constantinou, M. T. Valente, A. Serebrenik, On the abandonment and survival of open source projects: An empirical investigation, in: 2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), IEEE, 2019, p. 1–12. [16]E. Jabrayilzade, M. Evtikhiev, E. Tüzün, V. Kovalenko, Bus factor in practice, in: Proceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice, ICSE-SEIP ’22, Association for Computing Machinery, New York, NY, USA, 2022, p. 97–106. URL: https://doi.org/10.1145/3510457.3513082. doi:10.1145/3510457.3513082. [17] F. Ricca, A. Marchetto, M. Torchiano, On the difficulty of computing the truck factor, in: Proceed- ings of the 12th International Conference on Product-Focused Software Process Improvement, PROFES’11, Springer-Verlag, Berlin, Heidelberg, 2011, p. 337–351. [18] M. Ferreira, M. T. Valente, K. Ferreira, A comparison of three algorithms for computing truck factors, in: 2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC), 2017, p. 207–217. doi:10.1109/ICPC.2017.35. [19]M. R. Garey, D. S. Johnson, Computers and intractability, volume 174, freeman San Francisco, 1979. [20]C. M. Schneider, A. A. Moreira, J. S. Andrade Jr, S. Havlin, H. J. Herrmann, Mitigation of malicious attacks on networks, Proceedings of the National Academy of Sciences 108 (2011) 3838–3841. [21]P. R. Lawrence, J. W. Lorsch, Organization and environment: Managing differentiation and inte- gration, Harvard Business Review Press, 1986. [22] C. Heath, N. Staudenmayer, Coordination neglect: How lay theories of organizing complicate coordination in organizations, Research in organizational behavior 22 (2000) 153–191.