Diagnosing Current R&D Performance

2.1 Building the R&D Fact Base: Spend, People, Portfolio, Pipeline, and Capabilities

The first step in diagnosing R&D performance is to create a common fact base. In many organizations, the necessary information exists but is distributed across finance systems, project-management tools, human-resources records, laboratory systems, engineering databases, product roadmaps, and business-unit presentations. Definitions also vary. Finance may classify R&D spend differently from the technology organization, and individual business units may define projects, development stages, or full-time-equivalent resources in inconsistent ways. A diagnostic cannot rely on comparing numbers that appear similar but measure different things.

The fact base should answer five fundamental questions: how much the organization spends, where people are deployed, what programs are being funded, how those programs move through the pipeline, and which capabilities support the work. These dimensions need to be connected at the project or program level wherever possible. Knowing that a business spends $200 million on R&D is much less useful than knowing which strategic priorities, technology platforms, product families, and stages of development consume that $200 million.

R&D Spend

Start with a reconciled view of spending over at least two or three years. Include internal labor, external engineering or scientific services, contractors, prototypes, testing, software and computing, clinical or regulatory development where relevant, and other directly attributable development expenses. Capital spending on laboratories, pilot plants, specialized equipment, or development infrastructure should normally be tracked separately rather than mixed into operating expenses.

Spend should then be segmented using dimensions that support management decisions. Useful cuts include business unit, product family, technology platform, geography, development stage, innovation horizon, strategic objective, and type of activity. The last category is particularly valuable. Organizations often discover that substantial technical capacity is consumed by maintenance, customer support, regulatory changes, defect correction, sustaining engineering, or low-value customization that senior management had assumed was available for innovation.

Reconcile the analytical view back to finance totals. A 95 percent complete database that reconciles is more credible than a theoretically comprehensive model containing unexplained gaps. Where precise attribution is impossible, document allocation assumptions rather than creating false accuracy.

People and Resource Deployment

Headcount should be analyzed by capability as well as organization. Titles and reporting structures do not necessarily reveal what people actually do. Identify major skill families, seniority levels, locations, and approximate allocation to programs. Scarce capabilities deserve special attention because they often determine portfolio throughput. Ten delayed projects may appear to represent a general capacity problem when all ten actually depend on the same three specialists, testing facility, software architects, statisticians, or regulatory experts.

Use actual effort where reliable time data exists. Otherwise, structured estimates from team leaders can be sufficient for strategic diagnosis. Do not spend weeks trying to achieve accounting-level precision if the objective is to distinguish material patterns such as 20 percent versus 50 percent of capacity devoted to sustaining work.

Portfolio and Pipeline

The project inventory should identify every material R&D initiative, including projects outside formal governance if they consume meaningful resources. For each program, capture its objective, sponsor, business unit, strategic theme, expected commercial outcome, development stage, start date, anticipated launch or completion date, current staffing, cumulative spend, forward funding requirement, key milestones, major uncertainties, and current status.

Pipeline data should show movement rather than merely the number of projects in each stage. Record when programs entered and exited stages, when key decisions occurred, and whether schedules changed. This creates the basis for cycle-time and throughput analysis in the next section.

Capabilities

The capability fact base should identify technical disciplines and enabling assets required to deliver the portfolio. These may include scientific expertise, systems engineering, artificial intelligence, regulatory development, user research, prototype manufacturing, modeling, data platforms, test infrastructure, laboratories, or external partner networks. For each strategically important capability, assess scale, proficiency, utilization, concentration risk, and likely future demand.

Capability assessment should distinguish between a shortage of people and a shortage of usable capacity. A team can appear adequately staffed yet remain unavailable because its time is fragmented across too many programs or consumed by unplanned support. Conversely, a small specialist group may be highly productive because demand is tightly prioritized.

Joint ventures, alliances, and collaborative development arrangements require particular care. Resources may sit outside the parent company’s headcount, intellectual property may be shared, and decision authority may cross organizational boundaries. The fact base should therefore identify who funds the work, who provides technical resources, who controls key decisions, and where dependencies on partners affect timing or capability access.

The finished fact base should be treated as a decision model rather than a data repository. Leaders should be able to move from total R&D spend to a particular strategic objective, examine the programs supporting it, understand the capabilities those programs consume, and see what outcomes are expected. That connected view creates the foundation for diagnosing performance.

2.2 Assessing R&D Productivity, Throughput, Cycle Time, and Commercial Output

R&D productivity cannot be reduced to a single ratio. Technical organizations convert uncertain ideas into knowledge, products, processes, platforms, and commercial options over different time horizons. A company that measures productivity only through immediate revenue will undervalue long-cycle research. A company that measures only activity, such as patents or experiments completed, can mistake technical motion for economic progress. The diagnostic therefore needs several complementary lenses.

Productivity asks how effectively resources are converted into valuable technical and commercial outcomes. Throughput asks how much work successfully moves through the development system. Cycle time measures how long that movement takes. Commercial output examines what reaches customers or creates economic value. These measures are related but not interchangeable. A pipeline can move quickly while producing weak products, and a commercially successful launch can emerge from an inefficient development process.

Productivity Measures

Begin by defining the outputs appropriate to the business. Relevant measures may include launches, approved assets, technical milestones, platform releases, cost savings, gross-margin improvement, successful applications, customer adoption, intellectual-property positions, or risk-adjusted portfolio value. Then relate those outputs to major inputs such as spending, technical headcount, development capacity, or time.

Ratios should be interpreted carefully. Revenue from products launched in the last three years divided by R&D spending may provide a directional indicator in some industries, but it ignores development lags, acquisition history, product lifecycle differences, and the commercial organization’s contribution. Its value lies primarily in trend analysis and comparison among genuinely comparable units, not in declaring an absolute productivity standard.

A stronger diagnostic often combines input, process, and outcome metrics. Input metrics include spend and FTEs. Process metrics include milestone attainment, queue time, rework, project termination rates, and decision speed. Outcome metrics include successful launches, adoption, margin contribution, cost savings, or portfolio value. Together they show whether weak output reflects inadequate investment, inefficient execution, or poor project selection.

Throughput and Attrition

Pipeline throughput should be analyzed as a flow. Measure the number of initiatives entering each stage, progressing, stopping, and reaching commercialization over a defined period. The objective is not to maximize survival. Healthy R&D systems terminate weak projects before they consume disproportionate resources. A pipeline in which nearly every program advances may indicate weak challenge rather than exceptional innovation quality.

Attrition should therefore be examined by stage and reason. Early technical failures may be appropriate if the organization tests uncertain hypotheses quickly and cheaply. Late failures are more costly and may indicate poor early evidence, weak governance, changing requirements, inadequate customer validation, or technical risks that were not addressed soon enough.

Analyze cohort behavior where possible. Rather than looking only at today’s pipeline, take programs entering development in a prior year and determine what happened to them. How many advanced, stopped, launched, changed scope, or remained stuck? Cohort analysis avoids the distortion created when a static snapshot combines projects with very different ages.

Cycle Time

Total development time should be decomposed into active work, waiting time, rework, and decision time. This distinction frequently changes the diagnosis. Engineers may be executing tasks efficiently while projects remain idle awaiting testing, customer input, a steering-committee meeting, regulatory guidance, or resources from another function.

Measure cycle time by project type. A platform redevelopment should not be compared directly with a simple formulation extension. Establish meaningful archetypes and examine both median performance and variation. Extreme variability often signals unclear development pathways, inconsistent governance, or unpredictable dependencies even when average cycle time appears acceptable.

Schedule slippage also deserves attention. Compare current milestone dates with the dates originally approved and record why they moved. Recurring causes such as specification changes, resource conflicts, late technical discoveries, supplier delays, or slow decisions indicate systemic issues that strategy and governance may need to address.

Commercial Output

Commercial output should ultimately connect R&D activity to business value. Examine launch frequency, revenue from recent innovations, realized versus forecast economics, adoption, product margin, customer retention, cost reduction, or other measures appropriate to the strategy. For research-intensive businesses, also examine intermediate value creation such as technical proof points, regulatory milestones, or increases in the probability-adjusted value of pipeline assets.

Use time lags explicitly. Current commercial output may reflect R&D decisions made several years ago, while today’s spending will affect future performance. A diagnostic should avoid attributing historical launch weakness entirely to the current organization or treating a recent increase in spending as evidence of productivity before results could reasonably emerge.

The most useful output from this analysis is a small number of productivity hypotheses supported by evidence. For example, “development capacity is adequate, but projects spend too long waiting for cross-functional decisions,” or “commercial output is weak because resources are concentrated in low-value extensions rather than because engineering execution is slow.” Such hypotheses turn performance measurement into strategic diagnosis.

2.3 Diagnosing Portfolio Fragmentation, Bottlenecks, and Resource Dilution

Many R&D performance problems are portfolio problems disguised as execution problems. Teams appear slow because they are simultaneously supporting too many initiatives. Projects miss milestones because specialists are reassigned repeatedly. Managers compensate by adding meetings, escalation mechanisms, or project-management resources when the more fundamental issue is that the organization has authorized more work than its critical capabilities can support.

Portfolio fragmentation occurs when investment is spread across numerous programs that each receive insufficient resources or management attention to progress effectively. It is not simply a large project count. A company can manage many small, independent initiatives efficiently. Fragmentation becomes damaging when projects compete for the same scarce people, facilities, decision-makers, test environments, customer access, or capital.

Start by examining resource concentration. Calculate how many programs account for most of the spending and how much funding is distributed across the long tail. Then repeat the analysis for headcount and scarce capabilities. A portfolio may appear financially concentrated while specialist resources remain fragmented across dozens of projects.

Project staffing patterns are particularly informative. Count how many initiatives key individuals or teams support simultaneously. Excessive multitasking creates switching costs, reduces accountability, and extends elapsed time even when nominal utilization is high. In technical work, partial allocation can be especially damaging when tasks require deep concentration, experimental continuity, or detailed system knowledge.

Identifying Bottlenecks

A bottleneck is the resource, activity, or decision point that limits overall system throughput. Common R&D bottlenecks include specialist engineering disciplines, laboratory capacity, validation equipment, clinical operations, software integration, cybersecurity review, regulatory expertise, prototype tooling, customer trials, data access, and executive decisions.

Do not identify bottlenecks solely by asking which teams feel overloaded. High utilization does not automatically mean a resource constrains portfolio output. Trace project flow and determine where work queues accumulate. Ask which dependency most frequently delays critical-path milestones and what would happen if its capacity increased. If relieving one constraint merely causes work to queue somewhere else, the original issue may not be the primary bottleneck.

Queue time is often more revealing than task duration. A test may require only two days of work but have a six-week wait for equipment availability. A governance decision may take one hour of executive time yet add a month to the schedule because the committee meets infrequently. The diagnostic should distinguish the time required to perform work from the time projects wait for permission or capacity.

Finding Resource Dilution

Resource dilution occurs when priority programs do not receive the staffing implied by their strategic importance. Compare stated priorities with actual resource allocation. If leadership describes five programs as critical but the best technical talent is distributed broadly across legacy activities, customer requests, and lower-priority initiatives, the portfolio is not aligned in practice.

Examine unplanned work as well. Sustaining engineering, quality investigations, urgent customer requests, regulatory changes, security remediation, and executive-sponsored special projects can consume large amounts of capacity without appearing in portfolio plans. Measure the gap between planned and actual allocation. Persistent divergence suggests that the organization is systematically underestimating non-discretionary work or lacks mechanisms for protecting strategic programs.

Dependencies across projects can amplify fragmentation. Multiple products may depend on one platform release, common technology module, or shared dataset. In these cases, treating each product project independently can obscure the importance of the enabling work. Dependency mapping helps identify where concentrating resources on one platform could accelerate several downstream programs simultaneously.

Programs should also be examined for strategic redundancy. Separate business units may be solving similar technical problems without sharing work, or multiple teams may be pursuing overlapping technology approaches because no one has authority to consolidate them. Duplication is not always wasteful; parallel paths can reduce technical risk. The question is whether the redundancy is intentional and whether leadership understands its cost.

The diagnostic should distinguish three remedies. Some problems require portfolio reduction: fewer projects should be active. Others require resource concentration: the same portfolio may be feasible if critical programs receive dedicated capacity. Still others require system redesign: workflow, decision rights, facilities, or governance must change. Treating all three as a generic “capacity issue” leads to poor interventions.

A useful final visualization is a portfolio congestion map showing active programs, critical shared resources, major queues, and dependencies. Combined with data on program value and strategic priority, it reveals where stopping, sequencing, or accelerating work would release the greatest amount of productive capacity.

2.4 Benchmarking R&D Investment and Performance

Benchmarking can sharpen an R&D diagnostic, but it is easy to misuse. Executives often ask whether the company spends too much or too little relative to peers. The comparison can be informative, yet a benchmark cannot determine the right R&D budget without considering strategy, portfolio maturity, development model, industry economics, and what the company expects innovation to accomplish.

The most common benchmark is R&D spending as a percentage of revenue. It is useful for understanding broad investment intensity, particularly when compared over time and against carefully selected peers. However, the ratio is affected by revenue growth, accounting classifications, outsourcing models, acquisitions, business mix, and development stage. Two companies pursuing different strategies can rationally have very different ratios.

Peer selection therefore matters more than database size. Use companies with comparable products, development economics, technology intensity, regulatory requirements, and strategic position. Segment diversified peers when possible. Comparing a specialized growth business with the consolidated R&D ratio of a mature conglomerate can create more confusion than insight.

Benchmarking should extend beyond spend intensity. Depending on available data, useful comparisons may include R&D spend per technical employee, technical headcount as a percentage of total employees, development cycle time, launch frequency, new-product revenue contribution, patent quality, portfolio attrition, external development spend, platform reuse, milestone performance, and organizational layers.

Internal benchmarking is often more actionable than external benchmarking. Compare business units, sites, platforms, or project archetypes operating within the same company. Internal comparisons reduce differences in accounting definitions and strategic context. If similar programs in one division consistently move through validation faster than those elsewhere, the organization can investigate specific practices rather than debating whether an external peer is genuinely comparable.

Interpreting Benchmark Gaps

A benchmark gap should trigger a question, not a conclusion. If R&D spending is above the peer median, possible explanations include excessive cost, deliberate investment for growth, a pipeline near peak development intensity, duplicated infrastructure, weak productivity, or differences in accounting. The diagnostic must determine which explanation applies.

Likewise, spending below peers is not inherently positive. It may indicate efficiency, but it can also reveal underinvestment that has not yet appeared in financial results. An aging product portfolio with low current R&D intensity may look efficient until the competitive position deteriorates several years later.

Normalize metrics when material structural differences exist. Consider acquisitions, divestitures, unusually large programs, outsourcing, currency movements, or changes in capitalization policy. For cycle-time comparisons, use similar development archetypes and comparable starting and ending points.

The best benchmark analysis combines three perspectives: external peers indicate what appears possible in the market; internal comparisons reveal where performance differs under similar corporate conditions; and historical trends show whether the company’s own system is improving or deteriorating. Agreement across all three creates stronger evidence than any single benchmark.

Present benchmarks as ranges rather than false points of precision. Management needs to know whether performance is materially outside a reasonable range and why. A sophisticated benchmark discussion should leave leaders with a better hypothesis about the business, not simply a percentile ranking.

2.5 Current-State Diagnostic Scorecard and Management Interview Guide

The diagnostic should culminate in an integrated view that management can use to set priorities. Large collections of charts and metrics are rarely sufficient. Executives need to understand which aspects of the R&D system are healthy, which constrain strategic performance, how confident the team is in the evidence, and what questions require deeper analysis.

A current-state scorecard provides that synthesis. It should assess a limited number of dimensions that together describe the R&D system. Ratings can be numerical, such as one through five, or qualitative, such as strong, adequate, weak, and critical. The rating scale matters less than the evidence and management implications behind each rating.

Recommended Diagnostic Scorecard

• Strategic alignment: Degree to which spending and technical resources support stated corporate and business-unit priorities.
• Portfolio quality: Strength of the portfolio based on strategic value, commercial potential, technical feasibility, risk, and balance across time horizons.
• Resource concentration: Extent to which priority programs receive sufficient dedicated funding, talent, and management attention.
• Pipeline flow: Ability of programs to progress through development without excessive queues, rework, or avoidable delay.
• Decision quality: Clarity, speed, and evidence basis of continuation, termination, funding, and escalation decisions.
• Development productivity: Relationship between resources consumed and meaningful technical or commercial outputs produced.
• Capability strength: Availability and quality of technical capabilities required by the current and future strategy.
• Commercial conversion: Ability to translate technical programs into launches, adoption, margin improvement, cost reduction, or other intended business outcomes.
• External leverage: Effectiveness in using partners, suppliers, universities, licensors, contractors, and other external sources of innovation where appropriate.
• Performance visibility: Quality of data, metrics, and management information used to understand portfolio health and make decisions.

Each dimension should include four elements: the rating, two or three supporting facts, the principal implication, and the confidence level of the assessment. Confidence is important because weak data should not be disguised as certainty. A low-confidence red rating may indicate an urgent data problem rather than proven poor performance.

Scorecards should not mechanically average into one overall R&D score. Some dimensions matter far more than others. A severe capability gap in a strategically essential technology can outweigh several green ratings elsewhere. The objective is to focus executive discussion, not produce a league table.

Management Interview Guide

Quantitative analysis should be complemented by structured management interviews. Interviews help explain why the observed patterns exist and reveal decisions, informal processes, and organizational behaviors that data rarely captures. They should not become broad conversations about everything respondents dislike about R&D. Use a consistent question set, test claims against data, and actively seek contradictory perspectives.

Interview the R&D leader and senior technical managers, but also include business-unit executives, finance, product management, commercial leadership, operations, regulatory or quality leaders where relevant, and selected program leaders. The gaps between their perspectives are often diagnostic. R&D may believe priorities change constantly, while business leaders may believe R&D ignores market needs. Finance may see uncontrolled spending where program teams see chronic underfunding. These differences point to issues in governance, planning, or decision rights.

Core interview questions should include:

1. Strategy: What are the three most important outcomes R&D must deliver over the next three to five years? Where does current activity not reflect those priorities?
2. Portfolio: Which programs would you increase funding for today? Which would you stop or reduce if resources had to be reallocated?
3. Resources: Where are the most consequential capacity constraints? Which teams or specialists are spread across too many priorities?
4. Pipeline: Where do programs most often lose time? Which development stages generate the most rework, waiting, or late surprises?
5. Decisions: Which decisions take too long? Are weak programs stopped early enough? Who can actually terminate a project?
6. Capabilities: Which capabilities will become more important to the strategy? Where is the organization dependent on a small number of individuals or external partners?
7. Commercial connection: Where does the handoff between R&D and product, commercial, manufacturing, or other functions work well or poorly?
8. Performance: Which measures do you trust when assessing R&D effectiveness? Which important outcomes are currently not measured?
9. Management system: What recurring meeting, governance process, or budgeting mechanism most helps performance? Which one creates the greatest friction?
10. Priority intervention: If one structural change could materially improve R&D performance during the next year, what would it be?

Interview findings should be coded into themes rather than reported as a collection of quotations. Note how frequently an issue appears, which stakeholder groups raise it, whether evidence supports it, and whether opposing interpretations exist. A belief repeated by ten managers is still a hypothesis until the facts confirm it.

The final diagnostic should identify a small number of root causes. Examples might include “the portfolio contains 40 percent more active programs than critical engineering capacity can support,” “projects lose an average of eight weeks awaiting two governance decisions,” or “more than one-third of technical capacity is absorbed by unplanned sustaining work that is absent from strategic resource plans.” These statements are more useful than broad conclusions such as “prioritization needs improvement.”

Root causes should then be separated from symptoms. Missed milestones are a symptom. The root cause might be unstable requirements, specialist bottlenecks, resource switching, technical uncertainty, or delayed decisions. Low innovation revenue is a symptom. The underlying issue could be poor portfolio selection, weak commercialization, long development cycles, insufficient investment, or an aging pipeline. Strategy should address causes rather than visible effects.

A management-ready diagnostic normally ends with a concise set of implications for the R&D strategy: where resources appear misaligned, which portfolio choices require reassessment, which capabilities constrain the strategy, what performance issues warrant operating changes, and where further analysis is needed before decisions are made. It should avoid prescribing the full solution prematurely. The purpose of Chapter 2’s diagnostic is to establish a shared, evidence-based understanding of current performance so that subsequent investment, portfolio, capability, roadmap, governance, and operating-model decisions begin from the same facts.