An R&D project tracker is focused on the individual project — the specific development or improvement effort a team is working on. Where a broader R&D tracker organizes work across an entire organization, a project tracker zooms in on what should be recorded for each project so that the technical story, the people, and the costs are captured together. This page explains what to track at the project level and why each element matters. It is educational and is not individualized advice. For the broader concept, see our page on what an R&D tracker is.
The Project as the Unit of Record
In an R&D project tracker, the project is the unit of record. Each project represents a specific effort to develop or improve a business component — a product, process, software, technique, formula, or invention. Organizing information by project, rather than by department or task, helps connect activities and costs to something concrete. For more on the business-component concept, see our page on qualified research.
Objective
Every project record should capture its objective — what the work was intended to develop or improve. A clear objective statement answers: What business component is being worked on? What new or improved function, performance, reliability, or quality is being pursued? Recording the objective at the start of the project preserves the purpose in the team's own words, which is harder to reconstruct accurately later.
Timeline
A project tracker should record the start and end dates (or estimated end dates) of the project. The timeline helps establish when the work occurred, which can matter for determining which tax year's records are relevant and for organizing records chronologically. A timeline also helps distinguish ongoing research from work that has been completed or discontinued.
Technical Problem
Beyond the business objective, a project record should describe the technical problem being addressed. What specific technical challenge needed to be solved? What was not working, or what capability was missing? Describing the technical problem — not just the business goal — helps distinguish development work from ordinary business improvement.
Uncertainty
A project tracker should capture the technical uncertainty associated with the project. What was not known at the outset? Was it uncertain whether the desired capability could be achieved at all (capability uncertainty), how to achieve it (method uncertainty), or what the appropriate design was (design uncertainty)? Recording the uncertainty at the start of the project, in technical terms, preserves context that is difficult to reconstruct later. For more on the concept, see our page on documenting technical uncertainty.
Alternatives
A project tracker should record the alternatives that were considered — different designs, methods, materials, configurations, or approaches that could resolve the uncertainty. Documenting alternatives helps show that the work involved an evaluative process rather than a single predetermined path. For more on the evaluative-process concept, see our page on process of experimentation.
Experiments
For each project, the tracker should record the experiments or tests that were conducted — what was tested, how, and with what results. This may include modeling, simulation, systematic testing, or other evaluative methods. Experiment records connected to the project help show the progression of the work. For more on experiment-level documentation, see our page on R&D experiment logs.
Results and Iterations
A project tracker should record the results of experiments and the iterations that followed. What did the tests show? Which alternatives worked and which did not? How did the results inform the next step? Recording failures is as important as recording successes — a failed test of one alternative that informed the evaluation of another can help demonstrate a genuine evaluative process.
People
A project tracker should identify the people who performed or directly supported the work, and their roles. Who were the engineers, developers, or technicians doing the research? Who directly supervised or directly supported the work? Connecting people to projects helps organize the information that a wage analysis may need. For more on the wage framework, see our page on R&D tax credit employee wages.
Costs
A project tracker should connect costs to the project — wages of the people involved, contractor payments, and supplies used in the work. Where a cost supports both the project and other work, the tracker can help organize the information needed for a supportable allocation. For more on cost tracking, see our page on R&D expense tracking.
Supporting Evidence
A project tracker should link supporting evidence to the project — test results, design files, specifications, meeting notes, photographs, and similar artifacts. Organizing evidence by project, rather than leaving it in individual files, makes it easier to find and review later. For more on evidence organization, see our page on R&D evidence tracking.
Status and Outcome
A project tracker should record the status of the project — whether it is in progress, completed, or discontinued — and the outcome. Did the work achieve its objective? Was the business component successfully developed or improved? Was the project abandoned, and if so, why? Recording the outcome completes the project record and can be relevant for understanding the full scope of the development effort.
Why a Project-Level Record Matters
Organizing information at the project level helps connect the technical story, the people, and the costs in one place. This can make later analysis — whether for a tax credit, for internal review, or for professional review — more straightforward, because the relevant information is already organized by project rather than scattered across departments, files, and memories. For a practical template, see our page on R&D project documentation template.
Key Takeaway
An R&D project tracker should record, at the project level: the objective, timeline, technical problem, uncertainty, alternatives, experiments, results, iterations, people, costs, supporting evidence, and status. Each element helps preserve the technical substance of the work in a structured way. Tracking at the project level does not establish tax-credit eligibility, but it helps organize the information that such an analysis depends on. For a broader framework, see our page on how to build an R&D tracking system.