Project Selection Matrix¶
Artifact — instantiates Discrete Commitment Optimization
A structured table laying out candidate projects with their scores, costs, dependencies, and selection status for transparent human review.
A Project Selection Matrix is the visible artifact of a discrete commitment decision: a table with one row per candidate project and columns for its value score, cost, prerequisites, and in/out status, laid out so a human can see the whole choice at once. Its distinguishing property is that it is a document, not a method — it doesn't compute the answer or run a search; it makes the raw material of the decision legible, so that the scoring, the dependencies, and what got selected can be inspected, questioned, and recorded. It exists precisely for the situations where a solver's black-box precision would be inappropriate: where the value of the decision comes from stakeholders being able to see why this bundle and not that one.
Example¶
A company's quarterly product portfolio review has 14 candidate initiatives competing for a fixed engineering budget. The PMO builds a matrix: each initiative is a row, with columns for its strategic value score (1–10), estimated engineering cost, its dependencies ("needs the auth-service rebuild first"), and a final Selected / Deferred flag. The rows are sorted by value-per-cost, but the matrix makes the couplings impossible to ignore — a high-scoring feature is visibly greyed out because its prerequisite lost out on budget.
In the review meeting, the matrix is the conversation. Leaders can see that selecting initiative 9 without initiative 4 would strand a dependency, that the top-scored initiative eats 40% of the budget, and exactly which projects were deferred and why. The final column, once agreed, becomes the record: what was committed, what was cut, and the stated rationale. Nobody ran an optimizer; the artifact made a defensible bundle visible enough for humans to choose and to stand behind.
How it works¶
- One row per indivisible candidate. Each project is a whole in-or-out unit; there are no fractional rows.
- Columns for value and cost. A transparent score (often weighted from several criteria) and a resource figure, so relative worth is readable at a glance.
- A dependency column. Explicit prerequisites and mutual exclusions, so couplings that would break a naive ranked pick are surfaced on the page.
- A status and rationale column. The Selected/Deferred flag plus the reasoning, which doubles as the commitment record once the review signs off.
Its whole method is legibility: it arranges the decision's evidence, it does not generate the decision. A human (often a review board) reads it and chooses.
Tuning parameters¶
- Scoring rubric — which criteria feed the value column and how they're weighted. More criteria capture nuance but dilute clarity and hide value judgments in weights.
- Column granularity — how much detail per project (single score vs. a full criteria breakdown). Detail aids scrutiny but can bury the headline comparison.
- Dependency depth — whether only direct prerequisites are shown or full transitive chains. Deeper chains prevent surprises but crowd the artifact.
- Sort / grouping order — by value, by cost-efficiency, by theme. The default ordering quietly frames which bundle "looks obvious."
When it helps, and when it misleads¶
Its strength is transparency and accountability: it turns a discrete portfolio choice into something a room full of non-specialists can inspect, contest, and later audit. When legitimacy matters more than mathematical optimality, the artifact earns its keep by showing the work.
Its failure mode is that a tidy table looks objective while smuggling in every subjective choice made upstream — the scoring weights, which projects even made the list, how costs were estimated. A ranked matrix also invites greedy top-down selection: pick from the top until the budget runs out, ignoring that a lower-ranked bundle would fit better, a classic capital-rationing error the knapsack structure warns against.[n1] The guarding discipline is to treat the matrix as an argument to be interrogated, not a verdict — pressure-test the scores, confirm the candidate list isn't pre-filtered to a preferred answer, and check couplings before trusting a rank-order pick.
How it implements the components¶
indivisible_option_set— each row is a whole, all-or-nothing candidate; the matrix enumerates exactly the units that can be committed.objective_function— the value/score columns make explicit what the selection is trying to maximize, in inspectable form.dependency_graph— the prerequisites-and-exclusions column records how the choices are coupled.implementation_commitment_record— the status-plus-rationale column documents what was selected, what was deferred, and why.
It does not implement selection_rule or fairness_guardrail — deciding the bundle and vouching for its legitimacy is the role of its nearest twin, Selection Review Board, which reads this artifact and rules on it; the matrix only lays out the evidence.
Related¶
- Instantiates: Discrete Commitment Optimization — it is the transparent-artifact variant for human-reviewed selection.
- Sibling mechanisms: Selection Review Board (reads this artifact) · Assignment Model · Constraint Satisfaction Search · Crew Scheduling Model · Facility Location Model · Integer Programming Model · Integer Programming Solver · Solver Dashboard
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Project Selection Matrix operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a structured table laying out candidate projects with their scores, costs, dependencies, and selection status for transparent human review.
Independent corroboration: The frozen evidence defines Project Selection Matrix as 'A structured table laying out candidate projects with their scores, costs, dependencies, and selection status for transparent human review', so its operative form is Representation, Specification & Plan.
Nearest alternative: Decision, Gate & Allocation — Project Selection Matrix includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Project Selection Matrix is most plausibly rooted in the operations_research tradition because its characteristic form depends on queueing, optimization, scheduling, prioritization, and constrained allocation. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
Related originating lineages:
- Economics & Finance — Capital budgeting contributes cost, return, and opportunity-cost dimensions.
- Organizational & Management Science — The organizational_management tradition materially shaped Project Selection Matrix through its own practice of the coordination, governance, learning, and redesign of organized work.
- Public Administration & Policy — The public_administration_policy tradition materially shaped Project Selection Matrix through its own practice of policy implementation, public procedures, procurement, and administrative review.
Review resolution: Both blind reviewers agree that operations research is the primary origin. Explicit reconciliation resolves alternate origin disagreement, origin mode disagreement. Formative alternate lineages are retained as organizational_management, public_administration_policy, economics_finance; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The 0-1 knapsack problem — choose a subset of items to maximize value within a capacity — is the formal skeleton of budget-limited project selection. Its lesson is that greedy value-per-cost ranking is not generally optimal once items are indivisible, which is why a ranked matrix must be read for bundle fit, not picked top-down. ↩