> For the complete documentation index, see [llms.txt](https://productcommittee.docs.intersectmbo.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/research-grants-evaluation-framework-and-process.md).

# Research grants - Evaluation framework and process

## Core Evaluation Framework

### F — Fit to Grant Objectives (0–5)

<table><thead><tr><th width="115.15625">Score</th><th>Meaning</th></tr></thead><tbody><tr><td>5</td><td>Fully meets minimum requirements + fully covers nice-to-haves + adds meaningful extra value</td></tr><tr><td>4</td><td>Fully meets minimum requirements + covers most nice-to-haves</td></tr><tr><td>3</td><td>Fully meets minimum requirements</td></tr><tr><td>2</td><td>Meets most minimum requirements but with gaps</td></tr><tr><td>1</td><td>Major gaps in minimum requirements</td></tr><tr><td>0</td><td>Does not meet minimum requirements (automatic disqualification)</td></tr></tbody></table>

### C — Cost Efficiency (0–5)

Question: Given scope and quality, how efficient is this proposal compared to the others?

<table><thead><tr><th width="115.42578125">Score</th><th>Meaning</th></tr></thead><tbody><tr><td>5</td><td>Excellent value for money</td></tr><tr><td>4</td><td>Strong value</td></tr><tr><td>3</td><td>Fair / reasonable</td></tr><tr><td>2</td><td>Weak value</td></tr><tr><td>1</td><td>Poor value</td></tr><tr><td>0</td><td>Unjustifiably expensive</td></tr></tbody></table>

This avoids over-optimizing for the cheapest proposal (important for research grants).

### &#x20;T — Team Capability (0–5)

Question: Can this team deliver?

<table><thead><tr><th width="114.8984375">Score</th><th>Meaning</th></tr></thead><tbody><tr><td>5</td><td>Proven team with directly relevant expertise + past delivery evidence</td></tr><tr><td>4</td><td>Strong team with relevant experience</td></tr><tr><td>3</td><td>Competent team, skills present but limited proof</td></tr><tr><td>2</td><td>Some skill gaps</td></tr><tr><td>1</td><td>Major skill gaps</td></tr><tr><td>0</td><td>No credible delivery capacity</td></tr></tbody></table>

### P — Proposal Quality & Execution Plan (0–5)

Question: Is the execution credible?

<table><thead><tr><th width="114.75390625">Score</th><th>Meaning</th></tr></thead><tbody><tr><td>5</td><td>Extremely clear proposal, strong logic, clear milestones, timeline, risks identified</td></tr><tr><td>4</td><td>Clear proposal + milestones + timeline</td></tr><tr><td>3</td><td>Clear proposal + milestones</td></tr><tr><td>2</td><td>Some clarity but missing structure</td></tr><tr><td>1</td><td>Unclear or poorly structured</td></tr><tr><td>0</td><td>Incoherent</td></tr></tbody></table>

***

## Weighting

<table><thead><tr><th width="352.96875">Category</th><th>Weight</th></tr></thead><tbody><tr><td>F – Fit</td><td>40%</td></tr><tr><td>T – Team</td><td>25%</td></tr><tr><td>P – Proposal</td><td>20%</td></tr><tr><td>C – Cost</td><td>15%</td></tr></tbody></table>

Why?

* Fit matters most (this is strategic alignment)
* Team next (research quality risk)
* Proposal clarity third
* Cost last (research should not be optimized like commodity dev work)

***

## Evaluation Process

To reduce evaluator bias:

{% stepper %}
{% step %}

### Step 1 – Independent Scoring

Each evaluator scores privately each proposal
{% endstep %}

{% step %}

### Step 2 – Calculate Weighted Final Score

Final score per proposal:

\[(F × 0.4) + (T × 0.25) + (P × 0.2) + (C × 0.15)]
{% endstep %}

{% step %}

### Step 3 - Group Calibration Step (Very Important)

* Show anonymized averages from previous step
* Only discuss:
* Proposals with high variance (std deviation > 1): if any proposal was scored very high by someone and very low by someone else
* Proposals close in final ranking (< 0.3 difference): If weighted score of two or more proposals is too close
* Allow one rescoring round
  {% endstep %}

{% step %}

### Step 4 - Final decision

{% endstep %}
{% endstepper %}

***

## Evaluation Sheet Structure

Each evaluator fills:

<table data-header-hidden><thead><tr><th width="115.55078125"></th><th width="89.44921875"></th><th width="83.0546875"></th><th width="86.609375"></th><th width="85.11328125"></th><th width="81.6015625"></th><th></th></tr></thead><tbody><tr><td>Proposal</td><td>F (0–5)</td><td>T (0–5)</td><td>P (0–5)</td><td>C (0–5)</td><td>Notes</td><td>Individual evaluator proposal score</td></tr></tbody></table>

Master sheet calculates:

<table data-header-hidden><thead><tr><th width="118.64453125"></th><th width="89.86328125"></th><th width="89.3515625"></th><th width="88.4140625"></th><th width="84.00390625"></th><th width="107.76953125"></th><th></th></tr></thead><tbody><tr><td>Proposal</td><td>Avg F </td><td>Avg T </td><td>Avg P </td><td>Avg C</td><td>Weighted Score</td><td>Rank</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://productcommittee.docs.intersectmbo.org/committee-outcomes/product-research/product-research-grants/research-grants-evaluation-framework-and-process.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.