Building the Portfolio Fact Base

2.1 Creating a Complete Inventory of R&D Programs

The first requirement is deceptively simple: establish a complete list of the programs that compete for portfolio resources. Many organizations do not have one. Finance may track cost centers, R&D leaders may maintain project lists, product teams may manage roadmaps, business units may sponsor local initiatives, and corporate technology groups may fund exploratory work separately. Each source can be internally accurate while providing an incomplete picture of the enterprise portfolio.

A useful inventory begins with an explicit inclusion rule. Leadership should determine which activities qualify as portfolio decision units rather than relying on whatever happens to be labeled a “project.” The rule might include all development efforts above a defined annual spend, all programs requiring designated technical resources, all initiatives expected to create commercial products or platforms, or all work requiring a formal stage-gate decision. Smaller exploratory efforts can be aggregated into discovery pools where individual tracking would create administrative burden without improving decisions.

The inventory should look beyond formally approved projects. Relevant work often exists in categories that escape normal portfolio reporting: technology demonstrations, unfunded but staffed concepts, customer-funded development, regulatory remediation that consumes development resources, acquired programs awaiting integration, platform investments, and projects nominally “on hold” that still use people or facilities. Shadow work matters because it consumes the same constrained capacity that leadership is attempting to allocate.

Completeness is best tested through reconciliation rather than a single data request. The portfolio team should compare several independent sources: project-management systems, finance ledgers, headcount assignments, laboratory or facility schedules, product roadmaps, capital requests, stage-gate records, and interviews with functional leaders. A program appearing in one source but not another should be investigated rather than automatically added or excluded. These discrepancies often reveal unclear governance or hidden commitments.

A basic inventory should assign every program a unique identifier and capture enough descriptive information to prevent duplicates. At minimum, record the program name, sponsoring business, accountable executive, program leader, technical domain, development objective, portfolio category, current stage, and status. Naming conventions matter. The same effort may appear under a technology name in R&D, a future product name in marketing, and an internal code in finance. The unique identifier allows those records to be connected without assuming identical labels.

Portfolio teams should also distinguish between programs and components. A platform program may enable five downstream applications; a drug candidate may support several indications; an industrial technology may feed multiple product-development projects. Listing only the umbrella initiative can conceal economically distinct decisions. Listing every work package independently can create hundreds of artificial “projects.” The decision unit established in Chapter 1 should determine the inventory structure, while parent-child fields preserve relationships among related activities.

Ownership must also be explicit. Every program should have one accountable sponsor responsible for its strategic case and one program leader responsible for its execution fact base. Joint ownership is often a sign that decision accountability is unclear. Cross-functional participation can be broad, but responsibility for maintaining the program record should not be distributed so widely that nobody owns data quality.

The inventory process is also an early diagnostic of R&D management discipline. If program lists cannot be reconciled, status definitions vary across units, or significant work has no identifiable sponsor, those issues should be documented rather than cleaned up silently. The fact-base exercise is revealing how the portfolio is governed today. Correcting the database without recognizing the underlying management problem leaves the organization vulnerable to the same inconsistency in the next review cycle.

Once assembled, the inventory should be frozen at an agreed cutoff date for the prioritization analysis. New projects and material developments can still be captured, but changes should be logged explicitly. Without a controlled baseline, programs can enter, disappear, or change scope while the review is underway, making comparisons unstable and encouraging teams to update assumptions selectively after seeing preliminary rankings.

2.2 Capturing Program Stage, Spend, Timing, Milestones, and Resource Requirements

A program inventory becomes useful only when each record contains comparable information about maturity, investment, timing, evidence, and resource requirements. The goal is not to capture every detail available to a project team. It is to establish a common set of fields that allows leadership to understand what has been invested, what remains to be invested, what the next funding increment buys, when meaningful evidence will arrive, and which scarce resources the program requires.

Program stage: Stage should describe where the program stands in its development pathway using a taxonomy that is meaningful across the portfolio. Organizations frequently discover that labels such as “development,” “validation,” or “Phase 2” are interpreted differently by different teams. A common stage dictionary should define the entry and exit criteria for each stage. Where different program types follow genuinely different development pathways, such as software, hardware, clinical assets, and advanced research, separate stage maps can be used while retaining enough common structure to support portfolio-level comparisons.

The stage should reflect actual evidence, not planned progress. A program scheduled to complete validation last quarter is not in the next stage simply because its original roadmap says it should be. The fact base should record the stage that has been earned based on completed evidence and the next decision point that must be reached.

Spend: Portfolio records should distinguish historical spend from future funding requirements. Historical spend provides context and may help explain organizational commitments, but forward allocation decisions should focus primarily on future cash and resources. Capture actual spend to date, current-period budget, forecast spending through the next milestone, and expected total remaining investment where that estimate is meaningful. Definitions should specify treatment of capital expenditures, external research, contractors, clinical costs, shared services, overhead, and partner funding.

For decision making, the most useful figure is often the incremental investment required to reach the next value-inflecting milestone. A program requiring $8 million to produce decisive technical evidence may be easier to assess than one presented only with a $70 million multiyear development estimate. This milestone-based funding perspective is particularly useful when integrating portfolio decisions with R&D investment planning.

Timing: The fact base should capture both the current forecast and the timing assumptions that matter economically. Relevant dates may include the next technical milestone, regulatory submission, prototype completion, pilot run, commercial launch, platform readiness, or customer validation. Teams should report current expected dates rather than original targets alone. Recording the original baseline alongside the latest forecast can reveal systematic slippage and help distinguish execution problems from normal development uncertainty.

Milestones: Milestones should represent evidence-producing events rather than generic activity completion. “Complete engineering work” is weak because it does not state what uncertainty will be resolved. “Demonstrate 95 percent reliability under specified operating conditions” is decision relevant. A good milestone changes what management knows about feasibility, value, risk, or readiness and creates a logical point for an advance, re-scope, hold, or stop decision.

The portfolio record should normally identify the next two or three material milestones, the target date for each, the evidence expected, and the decision the evidence is intended to support. Capturing dozens of detailed project milestones obscures rather than improves portfolio decisions.

Resource requirements: Financial budgets alone do not show whether the portfolio can be executed. Each program should identify demand for constrained resources in units that can be aggregated across projects. Depending on the industry, these may include full-time-equivalent scientists or engineers by specialty, laboratory capacity, testing rigs, clinical-development personnel, data-science teams, regulatory experts, prototype shops, pilot-plant hours, manufacturing engineering, or other scarce capabilities.

Resource estimates should be time phased. A program requiring ten specialist engineers for three months has a different capacity implication from one requiring three engineers continuously for two years. Monthly or quarterly profiles are usually adequate for portfolio purposes. Precision beyond what the organization can realistically forecast added workload without improving the decision.

Finally, all major data fields should carry a source, owner, and “as of” date. Portfolio teams should be able to distinguish audited actual spending from a program-manager estimate, an approved milestone date from an aspirational target, and committed headcount from requested staffing. Data provenance makes uncertainty visible and helps reviewers challenge assumptions without arguing about where a number originated.

2.3 Establishing a Consistent View of Technical, Commercial, Regulatory, and Execution Risk

R&D portfolios contain uncertainty by design. The objective is not to remove risk but to describe it consistently enough that leadership can compare fundamentally different opportunities. A common mistake is to collapse all uncertainty into a single “risk score.” That approach may simplify a spreadsheet, but it hides whether a program is threatened by an unresolved scientific hypothesis, weak customer demand, a difficult regulatory pathway, or execution capacity. Those risks have different implications and require different management responses.

Technical risk: Technical risk concerns whether the underlying science, engineering, architecture, formulation, algorithm, device, or process can meet the required performance. The assessment should focus on the most important unresolved technical hypotheses and the evidence available today. Useful questions include whether the core mechanism has been demonstrated, whether performance has been reproduced under relevant conditions, whether scale introduces new uncertainty, and whether key technical dependencies have alternatives.

Technical confidence should be tied to evidence quality. Expert optimism is not equivalent to experimental validation. A consistent scale might distinguish concept-level rationale, laboratory proof, prototype demonstration, relevant-environment validation, and production or clinical evidence. The exact taxonomy depends on the industry, but every rating should answer the same question: what evidence justifies the current level of confidence?

Commercial risk: Commercial uncertainty concerns whether the program will create sufficient customer, strategic, or economic value if technically successful. Assessment may include market need, customer willingness to adopt, competitive differentiation, pricing potential, addressable demand, launch timing, cannibalization, and the durability of advantage. Early research programs will naturally have greater uncertainty than products approaching launch. The purpose is not to force premature forecasts but to state what must be true commercially for continued investment to make sense.

Commercial assumptions should be separated from technical assumptions. A technically feasible program can fail because customers do not value the improvement enough to switch, because the opportunity arrives too late, or because the economics deteriorate at commercial scale. Conversely, strong demand does not compensate for technical infeasibility. Keeping the dimensions distinct prevents teams from using enthusiasm in one area to mask weakness in another.

Regulatory risk: For regulated industries, the portfolio fact base should identify the approval or compliance pathway, principal evidence requirements, unresolved regulator questions, likely submission timing, and dependencies on standards or policy decisions. Regulatory risk can affect both probability of success and investment requirements. A program may be technically promising but require clinical, safety, environmental, cybersecurity, or manufacturing evidence that substantially changes its economics and timeline.

Regulatory assessments should avoid treating “approval risk” as a single percentage without describing its drivers. Leadership needs to know whether uncertainty arises from an unclear classification, an untested endpoint, new safety evidence, jurisdictional differences, changing standards, or the organization’s limited experience with a particular pathway. Those distinctions determine whether additional analysis, regulator engagement, redesign, or external expertise can reduce the risk.

Execution risk: Execution risk concerns the organization’s ability to deliver the program even if its technical and commercial assumptions are sound. It includes capability gaps, resource bottlenecks, supplier dependence, manufacturing readiness, data availability, partner performance, project complexity, leadership capacity, and unrealistic schedules. Execution risk is often understated because portfolio reviews focus on the attractiveness of the opportunity rather than whether the organization can actually deliver it.

The four risk dimensions should be evaluated using defined scales with short evidence-based rationales. A rating without a rationale is difficult to challenge and easy to manipulate. For each material risk, the program record should state the driver, current evidence, potential consequence, planned mitigation, and next event expected to reduce uncertainty.

The fact base should also distinguish inherent uncertainty from controllable risk. Technical uncertainty may be intrinsic to a scientific hypothesis. A shortage of assigned engineers is a management choice. A regulatory requirement may be externally imposed; failure to schedule required testing may be an execution failure. Treating all four as equivalent “risk” can inadvertently reward under-resourced programs by portraying predictable execution problems as unavoidable uncertainty.

Where programs pass through formal reviews, risk evidence should align with stage-gate governance. The evidence required to advance should correspond to the uncertainties that matter at that stage. Early gates may emphasize technical feasibility and customer need; later gates may require validation, regulatory readiness, manufacturability, economic confidence, and launch preparation. This connection prevents the portfolio database and the development-governance process from becoming competing versions of the truth.

Finally, risk assessments should show direction of travel. A high-risk program may deserve continued investment if each milestone is systematically reducing uncertainty. A moderate-risk program may be deteriorating if repeated tests fail to resolve its core issues. Recording the prior assessment, current assessment, and evidence causing the change allows leadership to distinguish productive learning from persistent optimism.

2.4 Identifying Interdependencies, Platforms, and Shared Technology Foundations

Programs cannot always be evaluated as independent investments. R&D portfolios frequently contain technical, resource, commercial, and sequencing relationships that mean a decision on one program changes the attractiveness or feasibility of another. If these relationships are absent from the fact base, program-by-program rankings can produce recommendations that are individually logical but collectively impossible.

The portfolio team should begin by identifying several common forms of dependency. A technical dependency exists when one program requires a component, architecture, scientific result, dataset, or technology generated by another. A sequencing dependency exists when one milestone must be completed before another program can proceed efficiently. A resource dependency arises when several programs require the same constrained people or facilities at the same time. A commercial dependency exists when products share a launch platform, channel, ecosystem, customer proposition, or market-development investment.

Dependencies should be recorded directionally. It is not enough to note that Programs A and B are “related.” The fact base should state that Program B cannot enter validation until Program A establishes a particular interface, or that Programs C and D require the same pilot line during the third quarter. Direction, timing, and consequence are what make the relationship actionable.

Platforms require special treatment because their economics are often understated when assessed as standalone programs. A technology foundation, common software architecture, research platform, manufacturing process, data asset, or device platform may create value through several downstream applications rather than through direct revenue of its own. Its fact sheet should therefore identify enabled programs, common capabilities provided, expected reuse, and the consequences if the platform is delayed or stopped.

The reverse problem also occurs: teams may label investments “platforms” to protect them from normal economic scrutiny. A credible platform should have identifiable users or applications, a clear reusable capability, and an advantage relative to developing solutions independently. The portfolio team should distinguish a genuine shared foundation from an oversized project whose benefits have simply been described broadly.

Shared technology foundations also create correlated risk. If five high-value programs depend on one unproven technical architecture, the portfolio is less diversified than a list of five independent project values would suggest. The fact base should flag common failure points so leadership can understand concentration risk and, where justified, fund alternative approaches or earlier validation of the shared foundation.

A simple dependency matrix can complement program fact sheets. Programs are listed on both axes, with material dependencies classified by type and criticality. For larger portfolios, a network view may make clusters and single points of failure easier to see. The visualization is secondary; the objective is to identify decisions that must be made jointly rather than through isolated scoring.

Dependencies should also influence funding logic. It may be sensible to fund an enabling platform ahead of a downstream application even when the application has the more attractive standalone business case. Conversely, downstream programs should not consume full development resources while awaiting a prerequisite that remains uncertain. Making those relationships explicit allows leadership to stage investment and preserve options rather than funding entire dependency chains simultaneously.

2.5 Template: R&D Portfolio Program Fact Sheet and Portfolio Database

The fact sheet is the standard record for an individual program; the portfolio database is the structured collection of those records. They serve different purposes but should use the same definitions. The fact sheet gives decision makers a concise narrative and evidence summary. The database enables comparison, aggregation, scenario analysis, resource modeling, and reporting across the portfolio.

A strong program fact sheet should normally fit on one or two pages. If executives need a twenty-page presentation to understand each program, portfolio comparison becomes impractical. Detailed technical documentation can remain in underlying project files and be referenced when needed. The fact sheet should capture the information necessary to understand the investment case, current evidence, principal uncertainties, and next decision.

Program Fact Sheet

• Program identity: unique ID, program name, parent platform where applicable, sponsoring business, executive sponsor, program leader, and technical domain.
• Objective: concise description of what the program is intended to develop, demonstrate, improve, or enable and the customer or strategic need addressed.
• Portfolio classification: program type, strategic theme, time horizon, product or technology family, and relevant portfolio segment.
• Current stage and status: development stage earned, latest formal decision, current status, and date of the most recent review.
• Strategic rationale: specific strategic priorities supported and the role the program plays within the broader portfolio.
• Investment: spend to date, current-year budget, forecast to the next decision point, expected remaining investment, and significant external or partner funding.
• Milestones and timing: next material milestones, expected dates, evidence requirements, planned launch or deployment timing, and material schedule changes.
• Resource requirements: principal scarce capabilities, time-phased resource demand, facility requirements, and major external support needs.
• Risk profile: technical, commercial, regulatory, and execution ratings with evidence-based rationales, mitigations, and expected uncertainty-reduction events.
• Dependencies: enabling technologies, predecessor programs, shared platforms, external partners, critical suppliers, and downstream programs affected by the decision.
• Decision required: the next advance, accelerate, continue, re-scope, hold, partner, or stop decision; decision owner; timing; and evidence required.

Portfolio Database

The database should translate these elements into standardized fields. Each row will often represent a program, with controlled fields for categories that need to be aggregated. Free-text fields remain useful for rationales and evidence, but excessive use of narrative text makes analysis difficult. Wherever portfolio comparisons are required, values should use common units, taxonomies, and definitions.

Data governance should be lightweight but explicit. Each field should have a definition, source, owner, update frequency, and allowable format. Controlled lists should be used for stage, status, program type, portfolio category, risk rating, and decision recommendation. Financial fields should specify currency, period, and treatment of shared costs. Resource fields should use a common unit such as full-time equivalents, person-months, machine hours, laboratory slots, or another relevant capacity measure.

The database should preserve both current values and selected historical baselines. Overwriting prior milestone dates, risk ratings, resource forecasts, or budget estimates eliminates valuable information about how programs evolve. At minimum, retain the original approved baseline, the previous portfolio-review value, and the current forecast for fields where movement is decision relevant.

Quality control should focus on decision-critical data rather than attempting to perfect every field. Before analysis begins, portfolio leaders should test whether all in-scope programs are represented, spending reconciles sufficiently to finance records, stage definitions are applied consistently, resource demand can be aggregated, major milestones have evidence requirements, and risk ratings have documented rationales. Material exceptions should be flagged rather than hidden.

The database should also contain an explicit confidence indicator for important estimates. Early programs may have low-confidence commercial forecasts or resource plans, while late-stage programs may have highly developed estimates. Displaying confidence prevents uncertain figures from acquiring artificial authority simply because they occupy a spreadsheet cell. Where confidence is low, the implication may be to fund the next learning milestone rather than attempt to refine a distant forecast prematurely.

Finally, the fact base should remain a management asset after the initial prioritization exercise. The program fact sheet can become the standard input to recurring portfolio reviews, while the database provides the baseline for funding scenarios, capacity analysis, stage-gate decisions, and portfolio performance tracking. Maintaining it requires less effort than rebuilding the portfolio from scratch each planning cycle and, more importantly, creates continuity between the evidence presented, the decisions made, and the resources subsequently committed.