The Dependency Blind Spot: Why High-Performing Teams Misprioritize

Every leader of a capacity-constrained team has experienced the same private failure. A project ranked high on the team's prioritization framework was selected, started, and stalled. Three months later, post-mortem analysis revealed that the project was blocked from the outset on a vendor contract, an upstream platform decision, or a data dependency that no one had explicitly named. The framework had not been wrong about the project's value. It had simply been silent on the project's readiness.

This silence is not accidental. The dominant project prioritization frameworks in contemporary use — RICE, developed by Intercom for product feature selection (McBride, 2014); ICE, a simplified variant; and Weighted Shortest Job First (WSJF), drawn from the Scaled Agile Framework (Reinertsen, 2009; SAFe, 2024) — were each designed to address a specific problem: how should a product organization choose among competing feature ideas? They were not designed to address the structurally different problem faced by engineering leaders, operations managers, and PMO directors: how should a capacity-constrained team sequence work that has already been deemed valuable?

The distinction matters because the two problems impose different mathematical structures on a scoring formula. Product feature selection assumes substitutability — a feature with high reach can compensate for moderate confidence, and vice versa, because the question is which features to pursue from a discovery perspective. Execution sequencing assumes necessity — a project that cannot start cannot deliver value, regardless of how well it scores on other dimensions. When the same scoring framework is applied to both problems, the second problem is systematically mishandled.

This article makes three claims. First, that the dependency blind spot — the absence of dependency as a first-class scoring axis in dominant frameworks — produces predictable misallocation in capacity-constrained teams. Second, that the architectural choice between additive and multiplicative scoring is not a matter of taste but a matter of whether one's axes describe substitutable preferences or necessary conditions. Third, that the discipline of refusing scoring axes that fail an objectivity test is itself a contribution to the practice of project management, distinct from the framework that results from it. We propose a four-axis model, IDTE, as the artifact of these claims, and articulate it in the language of the PMBOK Guide's seven Performance Domains.

RICE scores a project on the product of Reach, Impact, and Confidence, divided by Effort. The framework was developed at Intercom and published by Sean McBride in 2014, and it has become the dominant prioritization framework in product management practice. WSJF, drawn from the Scaled Agile Framework, scores a project on the sum of Business Value, Time Criticality, and Risk Reduction / Opportunity Enablement, divided by Job Size. Each framework treats dependency, when it treats it at all, as something to be folded into the Effort or Job Size estimate, or to be handled outside the formula as a sequencing concern.

This treatment is structurally inadequate for three reasons.

First, dependency is not a function of project effort. A project may require six team-weeks of work and have no dependencies, or require six team-weeks of work and depend on the completion of three external teams' deliverables. The effort estimate is identical in both cases. The probability that the project will deliver value during the planning cycle is not.

Second, dependency is not a function of confidence. RICE's Confidence axis asks whether the team believes the project will produce its claimed impact. Dependency asks something different: whether the project can be started at all. A team may have 95% confidence in a project's impact and 0% probability of starting it this quarter. Confidence and dependency answer different questions and are not interchangeable.

Third, dependency exhibits asymmetric leverage. A project that unblocks three downstream projects has different portfolio value from a project that does not, even when both projects score identically on impact and effort. Frameworks that omit dependency as a scoring dimension cannot represent this asymmetry. They produce identical scores for non-identical projects.

The cost of these inadequacies is not theoretical. In capacity-constrained teams — where the binding constraint is not which projects to pursue but which projects can actually be executed within a planning cycle — projects that score well on RICE or WSJF and start anyway frequently stall on undisclosed dependencies. The framework absorbs no blame because the framework was not asked the relevant question.

WSJF scores a project as (Business Value + Time Criticality + Risk Reduction) / Job Size. The choice of addition in the numerator is not incidental. It reflects an assumption that the three components of Cost of Delay are substitutable: a project low on time criticality can compensate by being high on business value or risk reduction. Under this assumption, addition produces an aggregate score that captures total Cost of Delay, which is then divided by Job Size to yield a value-per-unit-time rate.

This assumption fails for execution sequencing. Consider two projects scored under WSJF with components on a 1-to-10 scale:

Under WSJF's additive numerator, both projects produce a Cost of Delay of 18, and (assuming equal Job Size) both receive identical priority. Yet Project A delivers no risk reduction, while Project B is balanced across all three dimensions. Whether these projects should be treated as equivalent is a question the formula does not ask. It assumes the answer.

In execution contexts where each component represents a necessary condition rather than a substitutable preference, multiplication is the appropriate operator. A multiplicative scoring formula reduces to zero when any component is zero. It penalizes imbalance rather than averaging it away. It refuses to let a project's strengths compensate for fatal weaknesses on a dimension the team cannot afford to neglect.

“The choice between addition and multiplication should follow from the semantics of the axes, not from convention. Axes that are necessary conditions require multiplication. RICE's numerator is multiplicative for this reason.”

This is not an argument that addition is universally wrong. It is an argument that the choice between addition and multiplication should follow from the semantics of the axes, not from convention. Axes that are substitutable preferences (more of one is genuinely interchangeable with more of another) admit addition. Axes that are necessary conditions (each must be present for the project to deliver value) require multiplication. WSJF's numerator is additive because Reinertsen's original Cost of Delay framework was conceived as a financial sum. When WSJF is applied to execution sequencing rather than to its original economic-modeling context, the additive assumption travels with it and quietly distorts the result.

A scoring axis is useful only if two reasonable evaluators, given the same project information, would produce the same score. This is not a high bar. It is the minimum bar for a framework to qualify as engineered rather than performative. Yet many widely cited prioritization frameworks include axes that fail it.

Consider "Stakeholder Alignment" or "Strategic Fit," both of which appear in weighted scoring models in the literature (Cooper et al., 1999; Archer & Ghasemzadeh, 1999). These axes describe genuinely important considerations. They also resist objective measurement. Two evaluators in the same meeting will score the same sponsor's enthusiasm differently based on their own interpretive priors. The resulting score is a function of the evaluator, not of the project.

When a framework admits axes that fail the objectivity test, three pathologies follow. The framework's outputs become irreproducible: the same project scored by different evaluators yields different rankings. The framework becomes vulnerable to motivated reasoning: an evaluator who wants a project prioritized can score the subjective axis high without contradiction. And the framework's apparent rigor becomes a liability: stakeholders treat the resulting score as if it were objective, when it is in fact aggregated subjectivity with arithmetic operations performed on it.

We propose that a serious prioritization framework should refuse axes that fail this test, even when the refused axis describes a real and important consideration. Considerations that resist objective measurement should be handled in the human deliberation that surrounds the framework, not laundered through it.

Applying this discipline to candidate axes produces the following:

IDTE prioritizes projects on four axes that satisfy the objectivity test, combined in a multiplicative structure that respects the necessary-condition semantics of execution work.

The formula yields a rate: value-per-unit-of-team-capacity, weighted by readiness and urgency. We define each axis below in terms that satisfy the objectivity test, with rubrics anchored to observable criteria rather than evaluator judgment.

5.1 Impact (1–5)

Impact measures the magnitude of the project's expected outcome. Scoring requires anchoring to a single quantifiable metric chosen in advance: revenue, cost savings, users affected, or contribution to a named strategic objective. The same metric must be used across all projects in a given prioritization cycle to preserve comparability.

5.2 Dependency (1–5, inverted)

Dependency measures readiness to start. Scoring requires counting hard external blockers — items the team cannot resolve unilaterally within the planning cycle. The axis is inverted so that higher scores indicate higher readiness, preserving the convention that all numerator axes are positive.

Unblocker bonus. When a project's completion would unblock three or more downstream projects, add +1 to its composite score. This represents asymmetric portfolio leverage that the multiplicative formula otherwise cannot capture.

5.3 Time-Criticality (1–5)

Time-Criticality measures the rate at which the project's value decays if delayed. The axis is bounded by a discipline: scores above 3 require an actual date, contractual obligation, or quantified decay rate. "Urgency" without a temporal anchor cannot exceed 3. This rule prevents the well-documented inflation of urgency in subjective scoring.

5.4 Effort (in team-weeks)

Effort is measured in actual team-weeks, not on an abstracted scale. This decision is consequential. A 1-to-5 effort score destroys the formula's interpretability: the result becomes a unitless rating rather than a meaningful rate. Team-weeks preserve the interpretation of the IDTE score as value-per-unit-of-capacity, which permits cross-project comparison and capacity-budgeting calculations downstream.

Effort estimates should come from the team that will execute the work. Round to half-weeks. Anything under one week is scored as 0.5.

The Project Management Institute's PMBOK Guide (8th ed., 2025) organizes project management into seven Performance Domains: Governance, Scope, Schedule, Finance, Stakeholders, Resources, and Risk. IDTE explicitly addresses four of these domains and deliberately excludes the remaining three, with reasoning.

This explicit mapping serves two purposes. It situates IDTE within the established discipline of project management rather than presenting it as a novel methodology in isolation. And it documents the framework's deliberate omissions, allowing practitioners to identify when their context demands considerations IDTE does not score.

Consider four projects competing for a team's quarterly capacity:

The platform migration scores lowest despite the highest Impact, because it is blocked, only moderately time-critical, and expensive. This is the correct outcome. RICE would rank it second (Reach × Impact × Confidence / Effort, with high Confidence). WSJF would rank it second or third (additive numerator absorbs the dependency cost). IDTE refuses to start a project that cannot start, which is what the team's actual capacity constraint demands.

The regulatory project scores highest because it is the only project in the set that combines high Impact, full readiness, and a hard external deadline. A team using IDTE would commit capacity to it before considering the others.

IDTE is not the appropriate framework for every prioritization context. We articulate its limitations explicitly, in the tradition of methodology papers that establish credibility through honest scope-setting (Reinertsen, 2009; Cooper et al., 1999).

IDTE requires real effort estimates. The formula collapses to noise when applied to projects whose scope is too vague to estimate in team-weeks. In product discovery contexts, where scope is intentionally ambiguous, ICE or RICE remain more appropriate.

IDTE requires teams that can count their dependencies. Organizations whose dependency graph is itself unknown will produce Dependency scores that are guesses. The remedy is to do the dependency mapping work before applying IDTE, not to adopt IDTE in lieu of it.

Time-Criticality is gameable without discipline. Without enforcement of the date-or-decay-rate rule, evaluators inflate urgency to advance preferred projects. This is a process risk, not a framework risk, and it applies equally to any framework with a temporal axis.

IDTE is a framework for capacity-constrained execution, not for portfolio strategy. Strategic portfolio decisions — whether to enter a market, whether to fund a new product line — depend on considerations IDTE deliberately excludes. The framework should be used downstream of strategy, not in place of it.

The structural argument advanced here generalizes beyond IDTE itself. We argue that the choice of scoring axes and combinatorial operators in any prioritization framework should follow from the semantics of the decision being made, not from convention or convenience. Frameworks adopted from contexts whose problem structure differs from the team's actual context will systematically misallocate, even when the framework is internally well-designed.

This implies that the contemporary practice of selecting a prioritization framework from a catalog of named alternatives — RICE, ICE, WSJF, MoSCoW, Kano — should be replaced with a more deliberate practice of constructing or tailoring a framework to the team's specific decision context. PMBOK 8th edition explicitly endorses this practice under the term "tailoring," and devotes a full section of the Guide to it (PMI, 2025, §3). IDTE is offered as one such tailored framework, designed for the specific context of capacity-constrained execution teams scoring projects whose value is already accepted.

Future work should extend this argument empirically. We are conducting a structured field study comparing IDTE against RICE and WSJF on the same project set within a capacity-constrained engineering organization, tracking decision differences, completion rates, and team perception of framework usefulness over a single planning cycle. Results will be reported in a forthcoming companion piece.

Project prioritization frameworks are not abstract. They produce binding decisions about how teams spend the only resource they cannot recover: time. When the framework's structure does not match the structure of the decision, the cost is paid quietly, in stalled projects, missed deadlines, and the slow erosion of trust between teams and the prioritization process they are asked to follow.

The dependency blind spot, the compensation problem, and the failure of the objectivity test are not flaws in any single framework. They are inherited assumptions that travel with frameworks adopted from other decision contexts. IDTE is one attempt to address them. Whether it is the right framework for any given team is a question we leave to that team. The deeper claim is that the question itself — does this framework's structure match the structure of our decision? — should be asked, deliberately and with discipline, by every team that adopts a prioritization framework.

“Does this framework's structure match the structure of our decision? This question should be asked, deliberately and with discipline, by every team that adopts a prioritization framework.”