Research strategy
Research Information Management and Institutional Reporting
Create research records that people can maintain and leaders can use with confidence. Research information management connects publications, projects, funding, affiliations and other relevant activity through clear definitions and responsibilities. Outlier Science can help institutions review fragmented records, design reporting processes and specify the requirements for an appropriate information system.
The starting point can be an existing platform, several spreadsheets or a reporting process that has grown around repeated manual requests. The aim is a workable information model before additional technology is introduced.
On this page 7 sections
01
Clarify what the institution needs to know
Research information should serve defined users and decisions. A research office may need a view of active proposals, finance may need award identifiers, and academic leaders may need a departmental portfolio. These are related requirements, but they are not the same report.
The review can identify which questions recur, which fields are collected more than once, and where staff disagree about definitions. Common distinctions include submitted versus awarded funding, accepted versus published manuscripts, and the department responsible for a project versus the affiliations listed on an output.
The scope should also distinguish management reporting from public profiles. Internal records may contain provisional, commercially sensitive or personal information that does not belong on a public page. Designing the intended use of each field helps establish appropriate access and approval responsibilities.
A useful first output is a reporting requirements catalogue. It explains who needs each report, why it is needed, which source supplies it and what decision it supports. Reports with no clear use can then be reconsidered.
02
Build consistent identifiers, definitions and ownership
A reliable information model describes how people, organisational units, projects, awards and outputs relate to each other. It also defines who can create or correct records and how changes are reviewed. A shared project identifier, for example, can help connect proposal, award and output records without requiring every team to maintain the same spreadsheet.
External identifiers may support that model. ORCID provides identifiers for individual researchers, while ROR identifies research and funding organisations. Their use should be planned alongside local identifiers and validation processes; an identifier alone does not make a record complete or accurate.
Data-quality work can examine missing values, duplicate records, outdated affiliations, inconsistent naming and conflicting dates. Correction rules should preserve provenance so that the institution knows what changed and why. Historical records may require a different treatment from current organisational structures.
Ownership needs to be practical. Researchers can confirm scholarly details, administrative teams can maintain project status, and designated data owners can approve definitions. The model should avoid assigning maintenance work to people who lack either the information or the authority to do it.
03
Specify technology from the workflow
A system requirements exercise can map how records enter the institution, how they are reviewed and how they are used. It can then identify necessary functions such as import, matching, permissions, approval, search, reporting and export. Existing tools may meet some of these requirements once the process is clearer.
If a new platform is being considered, the specification should separate essential functions from desirable features. It should address data migration, integration, accessibility, user administration, maintenance and the ability to retrieve institutional records in usable formats. Demonstrations should be evaluated against real scenarios rather than feature lists alone.
The service can produce requirements and evaluation materials without assuming a particular vendor or an existing integration capability. Technical implementation, hosting, licences and ongoing administration require their own confirmed scope. Procurement authority remains with the institution.
When reporting difficulties arise from unclear roles, research-office development can address the operating model alongside the information requirements.
04
Illustrative deliverable: a report definition record
This example describes a proposed report specification. It is not a demonstration of an installed product or live institutional data.
Field | Illustrative definition |
|---|---|
Report | Active research projects by responsible unit |
Purpose | Review workload and support requirements |
Included records | Projects meeting an agreed active-status definition |
Key identifiers | Project ID, responsible unit and named institutional owner |
Source | Approved project register with a recorded update date |
Validation | Owner confirmation and checks for duplicate or stale records |
Review interval | Frequency agreed with the decision-making group |
Access | Authorised internal users appropriate to the information |
A sample row can then be traced back to its source. If a project appears in the wrong unit, the issue is corrected through the defined record owner rather than by silently changing a chart. If the meaning of “active” changes, the effect on historical comparison is documented.
This small discipline makes a dashboard more useful. Users can distinguish a real change in research activity from a change in reporting rules, and future analysts can reproduce the institution’s definitions.
05
Plan a manageable implementation and handover
The engagement can begin with a limited set of priority reports or one faculty. A pilot tests whether the definitions are understandable, whether information can be maintained and whether the proposed outputs answer the intended questions. Lessons from that work inform wider rollout.
Possible deliverables include a data inventory, a field dictionary, source-to-report mappings, a data-quality issue register, ownership rules, system requirements and a staged implementation plan. Training and user guidance can be designed around the actual tasks different roles perform.
Migration should include reconciliation and acceptance checks. A technically successful import is not enough if essential relationships are missing or users cannot interpret the records. The institution should define which checks must pass before the new process becomes authoritative.
Timing and cost depend on the number of sources, their condition, integration needs and the amount of process change involved. A requirements review can be scoped separately from migration or implementation. The quotation should identify software costs, vendor work and institutional tasks that sit outside the advisory deliverable.
06
Questions about research information management
Is this only for institutions buying a new system?
No. Many improvements concern definitions, responsibilities and data quality rather than a new purchase. The work can help an institution use its current systems more consistently or determine whether a new platform is justified.
Can you clean all our historical records?
Historical preparation can be considered as a defined workstream. Feasibility depends on volume, source quality, matching complexity and permissions. Some records may remain uncertain; the deliverable should record those cases rather than guess missing information.
Will the system automatically produce correct publication totals?
Automation still depends on source coverage, affiliation rules and validation. A reporting process should make those assumptions visible and give authorised staff a way to correct errors. No platform removes the need for institutional data ownership.
Can this include public researcher profiles?
Yes, requirements can cover profiles and approval processes. Public display should be based on information suitable for publication and the relevant permissions. A profile project also needs a clear plan for ongoing updates and correction requests.
Do you supply or resell research software?
This service is framed around information design, reporting and procurement requirements. Any software supply, implementation or vendor relationship must be specified separately. A requirements engagement does not itself include licences or imply a partnership with a platform provider.
07
Discuss your reporting problem
Describe the reports you need, the records you currently maintain and the steps that consume the most staff time. A sample description of the workflow is enough for an initial inquiry; live personal or confidential records are not needed at that stage.