A manufacturer with a modest development budget usually has more ideas than money: an improvement customers keep asking for, a new model for a bigger market, a sensor add-on that could become a service, a cheaper material that might work. Each idea has a champion, and each looks worthwhile on its own. The budget will not stretch to all of them, and the outcomes will not be known for months or years.
Research and development is unusual among business investments because its outcomes are deeply uncertain by design. If the result were predictable, it would not be R&D. That uncertainty causes three common problems. Projects are approved on enthusiasm rather than a clear view of what they are meant to find out. Portfolios drift towards safe, incremental work because it looks successful in the short term. And decisions are judged by their results, so a sensible bet that did not pay off is treated as a mistake, while a lucky one is treated as wisdom.
This article sets out a practical way to choose and govern R&D projects in a small or medium business: frame each project around the question it must answer, weigh value against probability and cost, stage spending so that early work buys the information needed for later decisions, keep the portfolio balanced, judge decisions by their quality rather than their outcome, and learn from finished projects. It is general information. Accounting treatment and government incentives for R&D have their own rules, and your accountant or adviser can explain how they apply to you.
R&D buys information
A useful way to think about any R&D project is that it buys information. Before the project, the business cannot tell whether a design will work, whether a material will survive, whether customers will pay or whether a process can be made reliable. A successful project is one that answers its question well enough to make the next decision. That might be a decision to launch, to invest further, to change direction or to stop.
Seen this way, a project is defined by two things: the question it is trying to answer and how hard the business attacks that question, meaning the people, equipment and money it commits. The budget is one attribute of the project, not the project itself. Two projects with the same budget can be completely different investments if one is aimed at a question that matters and the other is not.
This framing has practical consequences:
- Write the question down. “Develop a remote monitoring add-on” is a description of activity. “Find out whether a low-cost sensor can survive inside our pump housing for two years and whether at least five existing customers will pay for monitoring” is a question that can be answered.
- Count a clear negative answer as success. Learning early that an idea will not work saves the money that would have been spent finding out later. A project that ends with a clear “no” has done its job.
- Prefer projects that answer more important questions for the same cost and probability, or the same question more cheaply or more reliably.
Separate the quality of the decision from the outcome
A good decision can have a bad outcome, and a poor decision can be rescued by luck. R&D makes the difference unusually visible, because results arrive years after the decision and depend on markets, competitors and events nobody controlled. If decisions are judged only by results, people learn to avoid risky work, and a business that avoids all risky R&D eventually has nothing new to sell.
A widely used decision quality framework assesses the decision itself on six dimensions, all of which can be examined on the day the decision is made:
| Dimension | The question it asks | What a weak decision looks like |
|---|---|---|
| Frame | Is the project clearly defined, with goals agreed by engineering, sales, operations and finance? | Different functions describing the same project differently |
| Alternatives | Were genuinely different ways of reaching the goal considered? | One option presented for a yes-or-no approval |
| Information | Is the information reliable, with honest ranges of uncertainty about customers, competitors and technology? | Single-point forecasts nobody can explain |
| Values | Are the business’s priorities clear, including its required return, appetite for risk and non-financial aims? | An argument about the required return erupting inside a project review |
| Logic | Do the numbers combine correctly, so the conclusion follows from the inputs? | A spreadsheet that cannot be checked or reproduced |
| Commitment | Will the people who must act accept the result? | A careful evaluation filed away while the real decision is made informally elsewhere |
The first five are analytical. The sixth is organisational, and it is often where good evaluations fail. An analysis that the people who must act on it do not trust is not worth much.
Weigh value, probability and cost together
R&D projects differ in three ways that matter: how much they would be worth if they succeed, how likely they are to succeed, and how much they cost. Looking at only one of these leads to poor choices. Ranking by value favours long shots. Ranking by probability favours safe, small projects. Ranking by cost favours whatever is cheapest.
A simple way to combine them is the expected value: the value if the project succeeds multiplied by the probability that it does. “Success” here should mean both technical and commercial success, since a product that works but does not sell creates no value. “Value” should be the present value of the extra profit contribution the project would generate, after the costs of launching it.
Dividing expected value by the remaining cost gives a productivity index: expected value per dollar still to be spent. Ranking projects by this index and plotting cumulative expected value against cumulative cost produces a productivity curve. The curve usually rises steeply at first, then flattens, and often reveals a tail of projects whose expected value is less than their cost. Those projects consume more than they are likely to return, and each deserves a hard look.
Two cautions apply. The probabilities and values are estimates, often rough ones, so treat the ranking as a basis for discussion, not a verdict. And the index works best for comparing projects competing for the same constrained budget, which is the normal situation in R&D.
The financial techniques and their limits
Finance teams and lenders often expect familiar measures. Each has a role:
| Technique | What it calculates | Strength | Limitation |
|---|---|---|---|
| Sales-to-development ratio | Forecast early sales divided by development cost | Quick early screen | Uses sales as a stand-in for profit, which only works where margins are typical |
| Payback period | Time to recover the investment from future earnings | Simple and intuitive | Ignores everything after payback; thresholds are often habit, not analysis |
| Net present value (NPV) | Sum of all future cash flows, discounted at the business’s required rate of return | Theoretically sound | Accepting every positive NPV project is impossible when the budget is fixed |
| Benefit-to-cost ratio | Present value of benefits divided by present value of costs | Shows value per dollar | Sensitive to how benefits and costs are classified |
| Internal rate of return (IRR) | The discount rate at which the project’s cash flows have zero present value | Familiar to anyone who reviews capital spending | Can mislead when comparing projects of very different sizes or timing |
There is a practical argument for presenting R&D cases in the same terms the business uses for other capital spending, such as new equipment or premises. R&D competes with those uses for the same money, and a case presented in an unfamiliar way is easy to dismiss. Whatever measure is used, the probability of success must be built in. An NPV calculated as though success were certain overstates the value of every risky project.
Accounting treatment versus investment thinking
Accounting standards generally require research costs to be recorded as an expense in the year they are incurred, and allow development costs to be carried as an asset only when strict conditions are met. That means R&D spending usually reduces this year’s reported profit, while the benefits arrive later. If R&D is managed only through the profit and loss statement, the natural reaction to a tight year is to cut it.
The investment view asks a different question: is this a wise use of money, given what it might return and when? Both views are correct. They answer different questions. Managing R&D well means keeping both in mind, and being explicit when the business chooses to cut future options to protect current profit.
Stage spending to buy information cheaply
Most R&D projects should not be approved in full at the start. Break them into stages, each designed to answer the most important remaining question as cheaply as possible, with a decision point at the end of each stage. At each decision point, the options are to continue, change the project, pause it or stop.
Staging works because the early stages of a project are usually much cheaper than the later ones, and they resolve the biggest uncertainties. Spending a small amount to find out whether a key assumption holds is often the best value in the whole portfolio. Set the criteria for each decision point before the stage begins, so that the decision is not made by whoever argues hardest at the time. The stopping projects well article covers setting exit triggers and closing projects properly.
Keep the portfolio balanced
A portfolio can be efficient project by project and still unbalanced as a whole. Four balances deserve attention:
- Risk and return: a mix of safer, smaller projects and riskier, more valuable ones.
- Short and long term: work that pays off this year and work that builds future capability.
- Research and development: exploring new knowledge and turning existing knowledge into products.
- New and incremental: new products or capabilities, and improvements to what already sells.
A common trap is a portfolio loaded with high-probability, incremental projects. It looks successful for several years, because most projects deliver. Then the business finds it has no new products coming through. Current R&D success can be a misleading signal of future health.
A simple portfolio grid, with probability of success on one axis and value if successful on the other, makes balance visible. Projects with high probability and high value are the ones to protect. Projects with low probability and low value are candidates to stop. The other two quadrants, safe but small and risky but valuable, should both be represented in proportions the business chooses deliberately. The saying no to good projects article covers opportunity cost and balance across all kinds of business projects.
Forecast the pipeline on expected, not potential, revenue
When a business adds up the revenue its development pipeline could produce, it often uses potential revenue: the revenue if every project succeeds. That assumes a success rate nobody would claim for R&D, and it can make the pipeline look several times healthier than it is. Use expected revenue, with each project’s revenue weighted by its probability of success. Expected revenue is less exciting, and far more useful for planning budgets, hiring and capacity.
Organise for decisions that stick
The decision quality framework’s sixth dimension, commitment, depends on how the business organises its R&D. A few arrangements help:
- Cross-functional project teams that include engineering, operations, sales and finance from the start, rather than a chain of handovers.
- Authority and resources together. A team given a goal without the people and budget to reach it has been set up to fail.
- Clear ownership of stage decisions, with the criteria written down.
- Functional experts as a source of capability, supplying people and knowledge to projects, without a veto over every project’s direction.
Two governance habits cause particular damage. The first is cutting every project by the same percentage when the budget tightens. It feels fair and weakens everything; dropping or deferring the least productive projects protects the rest. The second is judging R&D leaders by short-term results alone, which rewards a safe portfolio over a healthy one.
Learn from finished projects
A post-project review is a structured look at a finished project to find lessons for future ones. It is different from a closure meeting, which settles the project’s own deliverables, accounts and handover. Practices that make reviews useful include:
- Treat the review as a small project, with a goal and a tangible output.
- Use a facilitator who was not on the project team, so team members can concentrate on the content.
- Ask people to prepare, including noting what surprised them most.
- Choose the timing deliberately: soon enough that memories are fresh, late enough that results are known.
- Look forward as well as back: what should the next project do differently?
- Record actions with owners, and check later that they happened.
Lessons often travel best with people. Moving experienced team members between projects can carry more learning than any report.
A worked example
This is an illustration. A 30-person business that designs and makes industrial pumps has an R&D budget of $500,000 for the year, including staff time. Six projects are proposed. For each, the team estimates the remaining cost, the probability of technical and commercial success, and the value if successful, expressed as the present value of extra contribution after launch costs.
| Project | Cost | Probability | Value if successful | Expected value | Expected value per dollar |
|---|---|---|---|---|---|
| A: improved seal for current range | $60,000 | 0.8 | $300,000 | $240,000 | 4.0 |
| B: new larger pump model | $250,000 | 0.5 | $1,200,000 | $600,000 | 2.4 |
| C: remote monitoring add-on | $150,000 | 0.3 | $1,500,000 | $450,000 | 3.0 |
| D: qualifying a lower-cost casting supplier | $40,000 | 0.7 | $150,000 | $105,000 | 2.6 |
| E: new impeller material | $120,000 | 0.25 | $400,000 | $100,000 | 0.8 |
| F: special variant for one customer | $80,000 | 0.9 | $60,000 | $54,000 | 0.7 |
Ranked by expected value per dollar, the order is A, C, D, B, E and F. Funding A, C, D and B uses exactly $500,000 and produces a combined expected value of $1,395,000. Projects E and F have expected values below their costs.
The team does not simply fund the top four. Project C is the most uncertain, so it is staged. A first stage costing $30,000 tests whether the sensor survives inside the pump housing and whether five existing customers will commit to a paid trial. If either test fails, the business stops having spent $30,000 rather than $150,000.
Project F is a commercial question rather than an R&D one. The customer is important, so the owner asks sales to price the variant to cover its development cost, rather than funding it from the R&D budget. Project E is deferred, with a note to revisit if a supplier offers to share testing costs.
The balance check shows two safe incremental projects (A and D), one major new product (B) and one long-term capability (C). The owner is comfortable with that mix.
When the team adds up the pipeline, potential value is $3,150,000 if all four funded projects succeed. Expected value is $1,395,000. The business plans its capacity and hiring on the expected figure, which is less than half the potential one.
Four months later, C’s first stage shows that the sensor survives, but only three customers will commit to a trial. At the stage decision, the team narrows the project to a monitoring kit for one customer segment, with a revised probability and cost, and continues. When project B is completed the following year, a facilitated review finds that late involvement of the production team caused tooling changes. The next project brings production in from the first stage.
How this applies to a small Australian business
- Write each project as a question to be answered, not an activity.
- Estimate value, probability and cost for each project, and rank by expected value per dollar.
- Stage risky projects, with decision criteria set before each stage.
- Check balance across risk, time horizon and newness.
- Forecast the pipeline on expected value.
- Judge decisions on their quality, not only their outcomes.
- Give project teams authority and resources together.
- Review finished projects and act on the lessons.
- Ask your accountant about the accounting treatment of R&D spending and about any government incentives, which have their own eligibility and record-keeping rules.
Common mistakes
- Approving activities instead of questions.
- Treating a negative answer as failure.
- Ignoring probability, so every project looks valuable.
- Approving large projects in full at the start.
- Cutting every project equally when money is tight.
- Forecasting on potential revenue.
- Rewarding safe portfolios that leave nothing for the future.
- Skipping reviews, or holding them with no actions.
Questions to ask
- What question is each project trying to answer, and what decision will the answer inform?
- How likely is each project to succeed technically and commercially, and how do we know?
- Which projects return less than they cost in expected terms?
- What is the cheapest way to resolve the biggest uncertainty in each risky project?
- Is our portfolio balanced in the way we intend?
- Are we judging past decisions on what was known at the time?
- What did our last finished project teach us, and what changed as a result?
Bringing it together
R&D buys information under uncertainty, so manage it that way. Frame each project around the question it must answer, combine value, probability and cost into expected value per dollar, and stage spending so the cheapest work resolves the biggest uncertainties first. Keep the portfolio balanced, forecast on expected rather than potential revenue, and judge decisions by their quality on the day they were made. Then review finished projects and carry the lessons forward. A business that does these things will still have projects that fail, but it will fail cheaply, learn quickly and keep new products coming.
Source: KEVOS notes, drawing on earlier KEVOS research handbooks on R&D project selection, decision quality, financial techniques for project selection, portfolio displays, R&D governance and post-project reviews. Examples and figures in this article are illustrations. This article is general information and does not constitute financial or accounting advice.
