How to prioritise R&D when projects need the same people

Two R&D projects can each have a persuasive case and still compete for the same test engineer. Ranking them separately does not resolve the conflict. The planning conversation needs the people, timing and dependencies behind each proposal.

For a fictional pump manufacturer, the monitoring pilot requires four engineer-months in the first quarter. A seal redesign requires three. Six engineer-months are available. The combined demand is seven, so the current plan exceeds capacity by one engineer-month.

An engineer-month is one person working full time for one month. Six engineer-months in a quarter represents two full-time engineers for three months. The example uses a pooled estimate; a real plan must also account for specific skills, leave, part-time availability and other commitments.

One option is to defer part of the seal work. Another is to reduce the monitoring pilot scope. A third is to obtain additional qualified capacity. Each changes something different: timing, evidence quality, cost or risk. Record those consequences before making the choice.

Check whether the resource can actually substitute. An available mechanical engineer does not automatically replace a sensing specialist. Also check whether moving a task delays a decision or releases time that no downstream team can use.

Connecting roadmap layers and dependencies helps expose these relationships. The roadmap should let participants follow the proposed work back to its strategic purpose and forward to the decision it enables. [1]

Agree the criteria relevant to this decision: customer impact, strategic fit, technical uncertainty, learning value and resource feasibility might matter. State the scale, who contributed each judgement and which assumptions it depends on.

A high-priority pilot with weak evidence may deserve a bounded experiment rather than a rollout budget. A lower-ranked enabling project may be necessary for several higher-ranked pathways. Keep those dependencies visible when comparing the options.

Where the result is close, change a plausible assumption and check whether the preferred option changes. Ask what new evidence would resolve the disagreement. Avoid an apparent precision that the team's knowledge cannot support.

Record the accepted sequence, the owner and the conditions under which it should be reconsidered. A failed qualification test, changed customer access or a specialist becoming unavailable can each justify a review.

The next review can ask what changed in evidence, capacity and strategic need. The R2 work places maintenance and governance within the design of a roadmapping system, which is useful when these decisions recur. [2]

Try the public example: enable the seal redesign, change the available capacity, then examine how the constraint changes. Download the worksheet to repeat the discussion with your own projects.