Sources of Uncertainty in R&D Projects
A single risk score tells you a project is risky. R6's framework tells you which kind of risky it is — and that difference is what determines what anyone does about it on Monday.
Four conditions, inverted into four uncertainties
R6 is a 1986 practitioner-journal report on a large multi-firm research programme — 211 R&D projects across 21 companies in four lines of business, drawn from a database built over nine years. Its empirical findings and its classification rules are treated on the sibling page, what distinguishes successful R&D projects. This page is about the framework that sits under them.
The framework's move is to read each condition backwards. Where a condition is not established, what remains is not a risk in general — it is a specific, named ignorance about a specific link in the chain.
THE FOUR SUCCESS CONDITIONS AND THEIR CORRESPONDING UNCERTAINTIES
| Success condition | Uncertainty source | The question it leaves unanswered | |
|---|---|---|---|
| 1 | A relevant business need is identified | Uncertainty about the relevance of the business objective | Are we solving a problem the business actually has? |
| 2 | A technical approach is matched to the need | Uncertainty about the fit between technical and business objectives | Will the approach we have chosen deliver the thing the business needs? |
| 3 | Results are transferable to an internal user | Uncertainty about the transfer of project results to an internal user | Is there a receiving function, and can it take what we hand over? |
| 4 | The user can produce, market, distribute and sell | Uncertainty about commercialisation of the product | Can the receiving function turn it into revenue? |
Close paraphrase of R6's framework. The decision rule attached to it: the more uncertainty on any of the four, the less likely the project is to succeed.
Why collapsing them into one number destroys the information
R6's stated procedure is to evaluate the project separately against each of the four sources. It gives two reasons, and the second is the one that matters operationally: doing so both quantifies how uncertain the project is and identifies the early-life activities that would reduce that uncertainty.
A combined score delivers only the first. Two projects can arrive at the same aggregate rating from entirely different positions — one with a well-understood market and an unproven technical approach, the other with proven technology and no identified receiving function — and nothing in the shared number distinguishes them. Yet almost nothing about what to do next is shared between those two projects.
What a single score supports
- Ranking projects against each other
- Signalling that a project is risky
- Comparing a portfolio's overall risk over time
- Triggering a review because a threshold was crossed
What only the disaggregated view supports
- Naming which link in the chain is unproven
- Identifying the specific early-life activity that would reduce it
- Working out which function has to do that work
- Testing at the next gate whether that particular uncertainty has fallen
Which of the four a project team can actually reduce
R6's continuation test is about movement rather than level: if uncertainty is not being reduced during the life of the project, the project is unlikely to succeed. That makes reducibility the practical question. The four sources are not equally within a project team's reach, and they are not reduced by the same kind of work.
What reduces each source, and who has to be in the room
Relevance of the business objective
Reduced by going and finding out — establishing that the need, problem or opportunity is one the business recognises. Largely within reach of the team, provided it is willing to have the answer come back negative. Requires the commercial functions, not the laboratory.
Fit between technical and business objectives
Reduced by work the team is best placed to do: testing whether the chosen approach can deliver what the need requires. This is the source most fully inside R&D's own control, and the one teams tend to over-weight because of that.
Transfer to an internal user
Reduced by arrangement rather than by investigation — identifying the receiving function early and involving it during the project rather than at handover. Within reach, but not by the project team acting alone.
Commercialisation by that user
Depends on whether the internal user can produce, market, distribute and sell. That is a capability of another part of the organisation. The team can establish early whether it exists and set expectations accordingly; it cannot usually build it.
Which source dominates depends on your business
R6 is explicit that the relative importance of the four sources is contingent on both the type of project and the line of business. It also gives the method for working out which one dominates: analyse your customer population and how your firm links to those customers.
- Who is the external customer?
- How does the firm link to them?
- Which sources are already low?
- Which sources predict success here?
The explanatory chain runs like this. First identify who the external customer is in your line of business — another industrial firm, or an end consumer. Then identify how firms link to that customer: direct interaction, marketing acting as a surrogate for the customer, or neither.
Where the customer interacts directly and originates project ideas, uncertainty about the relevance of the business objective is low, customer pull facilitates transfer, and sales uncertainty is low. In that setting, business-fit risk and technical-experience risk stop mattering. Where the customer is remote, those same risks become significant predictors of success.
Running the assessment
The procedure R6 describes
Establish the customer picture first
Identify the external customer for your line of business and how your firm links to them. This tells you which of the four sources is likely to dominate before you assess any single project.
Assess each source separately
Evaluate the project against all four in turn. Resist producing a combined figure at this stage; the separation is the point of the exercise.
Convert each into an activity
For each source carrying real uncertainty, name the early-life activity that would reduce it and the function that has to perform it. R6's stated purpose for the assessment is that corrective measures can be taken.
Reassess at each continuation decision
At the point of deciding whether to continue, assess explicitly the extent to which uncertainty is being resolved — source by source, against the earlier reading.
Read the trajectory, not the level
Uncertainty that has not fallen is the warning sign. R6's test is that a project which is not reducing its uncertainty is unlikely to succeed.
What the framework is not
R6 refuses to let its own framework be used as a kill screen. The framework is explicitly not a project selection or rejection tool — as the paper puts it, there are many reasons to undertake risky projects. Its purpose is to assess uncertainty and its sources so that corrective measures can be taken and expectations about success can be made realistic.
That distinction is worth holding, because the four sources look exactly like gate criteria and will be used as gate criteria unless someone says otherwise. A high reading on source 4 is a statement that the commercialisation capability is unproven, not a verdict that the project should stop. Termination is a separate decision with its own criteria and its own evidence — see making better project termination decisions and applying termination criteria by project stage.
One further limit belongs on any page built from R6. All its data are retrospective: respondents gave judgements about conditions at initiation only after the project had completed and after success or failure was known. The authors state that nearly all research-management studies share this limitation and that the results must be read with it in mind. Retrospective judgement is also the material that post-project reviews in R&D are made of, which is a reason to run them deliberately rather than from memory.
What to carry forward
- Four sources, not one: relevance of the business objective, technical-to-business fit, transfer to an internal user, and that user's ability to commercialise.
- Assess them separately. The separation is what converts an assessment into a list of activities that would actually reduce the uncertainty.
- The continuation test is a trajectory test. Uncertainty that is not falling over the life of the project is the signal, whichever source it sits in.
- Which source dominates is set by your line of business and by how your firm links to its customers — so borrow the framework, not another organisation's weighting.
- It is a diagnostic, not a kill screen. R6 states that there are many reasons to undertake risky projects, and declines to let the framework decide.
Frequently asked questions
Why not just combine the four into one risk rating?
Because the combined number cannot tell you what to do. R6's stated reason for assessing each source separately is that doing so identifies the early-life activities that would reduce the uncertainty. Two projects with identical aggregate ratings can be uncertain about completely different links in the chain, and the work required to fix them has almost nothing in common.
Which of the four should a project team work on first?
R6 does not rank them universally — it states that the relative importance of each source is contingent on the type of project and the line of business, and that the way to find out is to analyse your customer population and how your firm links to those customers. Where the customer interacts directly and originates ideas, several of the sources are already low.
What if the uncertainty simply cannot be reduced?
Then R6's continuation test is doing its job. The test is that a project which is not reducing its uncertainty over its life is unlikely to succeed. That is information for the continuation decision, but the framework itself is not a rejection tool — the paper is explicit that there are many reasons to undertake risky projects.
Source 4 is about another department's capability. Is it fair to hold the project to it?
R6's framework holds the project to it because the project's success depends on it, not because the team controls it. What the team can do is establish early whether the internal user can produce, market, distribute and sell the resulting product, and make expectations about success realistic if it cannot. Assessing that condition late is what turns it into a surprise.
Is risk brokering a rule I can apply?
No. It was proposed by the industry committee working with the study — the idea that more business-fit and technical-experience risk is acceptable when customer-fit risk is low. The authors state they cannot answer whether that is what is happening and pose it as a hypothesis for future study, so it carries no evidential weight.
Where do the study's actual findings live?
On the sibling page, what distinguishes successful R&D projects. That page covers the classification rules, the main effects and the second-order effects conditional on line of business, including the result about goal definition that most readers find counter-intuitive. This page deliberately stops at the framework so the two do not duplicate each other.
References and source attribution
- R6 - why R&D projects succeed or fail. Practitioner-facing report of a large multi-firm academic research programme, in a journal for research management, November-December 1986; 6 printed pages; 2 references. Database of 211 R&D projects across 21 companies in four lines of business, developed over nine years; eight questionnaires, four per project and four per firm. Sections used here: the four-source uncertainty framework and the customer-linkage interpretation.
- The published innovation life-cycle model used to select the four lines of business, and the two prior articles drawn from the same database, are cited within R6 and were not supplied to this library.
- Eleven copyrighted journal articles on R&D project management, supplied as a reading set for a literature review and profiled for this library. Front matter, abstracts, framework sections, tables and figures were read; article bodies were not reproduced, and all content here is paraphrase. The set is a reading list, not a systematic survey of the field.
- Supplied teaching source for this library (research methods and research process materials). Used here for page conventions and voice only; it does not treat R&D project uncertainty.
Suggested questions for Ask KEVOS
- Assess my project against each of the four uncertainty sources and keep them separate.
- For each source that is high, name the early-life activity that would reduce it and who has to do it.
- Work out which uncertainty source is likely to dominate given our customers and how we reach them.
- Compare this assessment with the one we did at the last gate and show me the trajectory.
- Draft the wording that stops this assessment being used as a go or no-go decision.
- Who is our internal user, and what evidence do we have that they can commercialise this?