Award module
The award already knows what the proposal said
Award setup from the linked institutional proposal, budgets from either direction, report tracking that knows its own due dates, and subawards that generate their own FDP paperwork.
The failure this replaces
The award was set up by retyping the proposal.
It is the most ordinary thing in research administration and it is where a surprising number of problems start. The notice arrives, somebody opens the proposal in one system and the award in another, and types the sponsor, the budget and the personnel across by hand — usually in the week when three other notices arrived too.
What follows is not one dramatic error. It is a slow divergence: a budget line that never matched, a co-investigator who was added to one record and not the other, a report requirement that lived in an email. None of it surfaces until a closeout or an audit, by which point the person who typed it has moved on.
What it does
From notice of award to closeout
The award starts from the proposal
When a proposal is funded, the award links to its institutional proposal and populates from it. Nobody re-keys a budget, a sponsor or a personnel list at the exact moment everyone is in a hurry.
A complete history, notice through closeout
Every change from the notice of award to closeout lives on one record. The question 'what did this award look like in March' is a lookup rather than a search through an inbox.
Budgets you can start either way
Pull the budget across from the corresponding proposal and modify it, or build one from scratch inside the award. Which one is right depends on how far the sponsor moved the goalposts between submission and notice.
Report tracking that knows the due dates
Every report entered as a sponsor requirement on an award feeds the report tracking module, which turns them into lists with due dates and statuses. Three standard views run at the click of a button, and the queries can be re-sorted and grouped for whoever is asking.
Subawards, and the paperwork they generate
Outgoing subawards track the pass-through entity, the subrecipient contacts, the history of funds released and the anticipated amount to be funded — and hold the data needed to generate FDP subaward agreements and modifications rather than retyping them into a template.
Compliance attached to the money
Protocols and disclosures link to the award through the same Streams function the compliance modules use. When a sponsor asks whether approval covers the funded work, that is one record away.
Why it is not a separate purchase
The award is the proposal, later
An award is not a new project. It is the same project with money attached, and every fact it needs was already written down when the proposal went out. A system that makes you say those facts twice is charging you for the privilege of keeping two versions of the truth.
In Streamlyne the award links to the institutional proposal and populates from it, protocols and disclosures attach through the same Streams function, and reporting reads across all of it. That is the case for one codebase, made in the one place it is easiest to check.
- Proposal developmentWhere the budget and personnel were first entered
- Institutional proposalThe versioned master record the award links to
- AwardTerms, budget, history from notice through closeout
- Report trackingEvery sponsor requirement, with due dates and status
- SubawardsOutgoing agreements, FDP templates generated from the record
Questions
What post-award teams ask first
What does post-award management software actually do?
It holds the funded project: the award terms, the budget, the personnel, the reports the sponsor requires with their due dates, and the subawards going out the door. Its real job is answering two questions without a search — what do we owe this sponsor and when, and does the money we are spending match what we were given.
Does the award have to be re-entered after the proposal is funded?
No, and that is most of the argument for a single system. The award links to the institutional proposal and populates from it, then you modify and supplement. In a split stack somebody re-keys the sponsor, the budget and the personnel by hand at the point in the year when nobody has time to check the typing.
How does report tracking work?
Every report entered as a sponsor requirement on an award is captured by the report tracking module and turned into a list of what is due and where it stands. Three standard views are available immediately, and a query can be modified, sorted and grouped for a particular audience — a PI wants their own reports, a director wants everything overdue.
Can it generate FDP subaward agreements?
Yes. The subaward record collects what the FDP templates need — pass-through entity, subrecipient contacts, funds released, anticipated funding — and generates FDP subaward agreements and modifications from it. The alternative is a Word template and a careful copy-paste, which is where subaward errors come from.
Can we adopt post-award without pre-award?
You can, and some institutions do when post-award is where the pain is. Be honest with yourself about what you lose: the award populating itself from the proposal is the single biggest saving here, and it only happens when the proposal is in the same system. If you run pre-award elsewhere, budget for that integration rather than assuming it away.
Which interface does post-award use?
The award modules run in the classic Streamlyne interface today. We would rather you knew that here than found it in a demo. What you get is the full award lifecycle on the same records as everything else; what you do not get is the newer UI that proposal development has. If a modern interface is a requirement rather than a preference, raise it with us before you evaluate anything else.