How to manage a university-industry research collaboration: the plain guide

Managing a university-industry research collaboration well comes down to six decisions made at kickoff and kept for the life of the project: who decides what, how often the sides meet, what a milestone means and who can move one, which body governs the partnership, how status is reported and where the shared record lives, and how disagreement is handled and how fast. Two jobs then run until the project ends: publication and IP review, and the decision to renew, redesign, or exit. If you have an agreement that was signed in the last 30 days, download the free Governance Charter first, which puts four of them (decision rights, the governance body, the cadence, and the escalation path) in one document that each party's project lead and executive sponsor sign.

This guide is written for both sides of the table: the principal investigator and the sponsored-programs officer on the university side, and the R&D lead, the alliance manager and the project manager on the company side. In the Helikon Method, this is the Steward phase. It is R&D project management, adapted for the fact that no single organization's management system can handle the whole project alone.

What changes the day after signing?

The people who negotiated the agreement are not the people who have to run it. The Helikon Method calls this the functional funnel: a partnership passes from counsel, business development, and sponsored programs, who have been living with it for months, to a PI and a company technical lead who were consulted twice and now have been handed a contract. The agreement records what was decided. It rarely records how the project will be run, because the people who wrote it were not going to run it.

What that handoff costs is well documented. Kale and Singh's review of the alliance research in Academy of Management Perspectives reports that between 30% and 70% of alliances fail, depending on the study, and that firms with a dedicated alliance-management function see about 70% of their alliances succeed, against about 40% for firms without one. The difference is not in the deal terms. It's in whether someone is dedicated to managing the partnership after signing. PMI's Pulse of the Profession 2018 makes the same point about projects in general. It compares organizations it calls champions, which finish at least 80% of their projects on time, on budget, meeting the business intent, and rate high on benefits realization, with underperformers, which manage 60% or fewer. Underperformers waste 29.1 cents of every project dollar against 1.4 cents for champions, about 21 times more, and their project success rate is 32% against the champions' 92%.

The corporate side of the same finding comes from Pertuzé, Calder, Greitzer and Lucas in MIT Sloan Management Review (2010): across 25 companies and more than 100 university projects, only about 20% showed an observable effect on the company, and two of the seven practices that separated those projects are decisions made in the first weeks, a project manager with the authority to carry the result across boundaries, and a standing communication link with the university team.

So before or at the kickoff meeting, the two sides need to settle six things. The rest of this guide takes them in order: decision rights, meeting cadence, milestone and gate rules, the governance body, status reporting and the shared record, and the escalation path. It then covers the two jobs that run until the end, publication and IP review and the renew, redesign, or exit decision, and closes with the tools that help.

Who decides what? Decision rights and a kickoff RACI

Even simple decisions can delay a research project when no one is sure if they're the one allowed to make them. Then they accrue and don't get resolved until the next quarterly meeting after a milestone has already slipped. Decision rights fix that. A decision right is a written statement of who can make a given class of decision without escalation, who has to be consulted, and who only needs to be informed.

The kickoff version is a one-page table. Down the side, the classes of decision a research project actually encounters: the order and method of experiments, a change of scope inside the budget, a change of scope that impacts the budget or the objective, adding or removing a team member, publishing a conference abstract or a manuscript, purchasing a new piece of equipment, a question that involves IP, a question that involves the agreement. Across the top, the named people: the PI, the company's technical lead, the two relationship owners, the steering committee, counsel, the executive sponsors.

This table is called a RACI: for each decision class, record who is responsible for making it, who is accountable for the result, who must be consulted first, and who is informed afterwards. The rule that keeps it useful is to make exactly one role as accountable per row. Where two people are accountable, nobody is.

The point of doing this at kickoff is that every example is hypothetical in the beginning. In month six, with a real scope change on the table, the same conversation becomes a negotiation. At kickoff, it's a form. Our free Governance Charter includes the RACI pre-filled with common decision classes, most partnerships can change three or four rows and sign.

How often should partners meet? The four-level cadence

Partnerships that meet only when someone calls a meeting are only reacting to problems. Partnerships that put everything into one quarterly steering meeting spend that meeting on operational triage and never get to the strategic questions it exists for. The cadence that can address the right mix of operational and strategic collaboration is set in advance at four levels, each with its own attendees, agenda, and output.

Operational: weekly to monthly. The working teams on both sides: the PI's group and the company's technical team. Agenda: what was done, what is blocked, what is needed from the other side, any risk flags. Output: a short written status, the same template every time. Weekly for an intensive joint project, monthly for a sponsored project with a quarterly deliverable.

Management: quarterly. The two relationship owners plus the project leads, with the steering committee where there is one. Agenda: milestones against plan, the decisions queued from the operational level, budget, prototypes or publications in the pipeline, anything that needs a decision above the project leads. Output: decisions recorded, the status both sides will report upward.

Strategic: semi-annual. The sponsors of the partnership on each side: the department chair or research dean, and the company's business-unit or research leadership. Agenda: is the partnership still aimed at the right objective, what has changed on either side, what should the next phase look like. Output: direction for the next six months.

Executive: annual. The people who signed the agreement. Agenda: renew, redesign, or exit, and the partnership's place in each organization's portfolio. Output: a decision about the next year.

The meeting cadence is also where measurement lives. Kaplan, Norton and Rugelsjoen, writing in Harvard Business Review (2010), describe a pharmaceutical company and its contract-research partner that adopted a joint balanced scorecard and strategy map for their alliance and cut clinical-study cycle time by about 40%, a gain the authors attribute to shared objectives and joint accountability rather than to any new technique. A scorecard is only joint if both sides read it on a schedule, and the management level of the cadence is where that happens. Our Field Note, How often should research partners meet? covers how to tune the frequencies to the project's size and duration.

How do milestones coexist with academic freedom? The research-adapted stage-gate

This is the tension every university-industry project carries. The company needs predictable milestones and a decision point before the next tranche of money. The research group needs the freedom to follow the results that came up last Tuesday, because that's where the scientific method leads. Traditional project management treats these as irreconcilable. They're not, but the standard tools need adapting.

Translation Box: milestone

On the academic side: a publication submission, a thesis defense, or a working prototype that demonstrates proof of principle. The date is a target, but the scientific method decides the actual date.

On the industry side: a deliverable with acceptance criteria, which releases the next tranche of funding or triggers a go or stop decision. The date is a commitment.

In this guide: a gate review that checks technical readiness and commercial relevance together, with both sides in the room and a decision at the end.

The model to adapt is stage-gate. Robert Cooper's process divides a project into stages separated by gates, where the work is reviewed against criteria and someone (or a committee) with the authority decides whether it continues. The research by Cooper, Edgett, and Kleinschmidt found formal stage-gate processes deliver 63 to 78% new-product success against a 25 to 45% baseline (summarized here), and the model is used by 75 to 80% of North American product developers (Cooper, 2008). The research adaptation has three parts, drawn from Cooper's own later work on gates under uncertainty (Cooper, 2014).

Two-criterion gates. Every gate asks two questions, scored separately: is the science ready? (technical readiness), and does the result still matter to the company? (commercial relevance). A project can pass one and fail the other. A result that is technically complete but no longer relevant should stop, a result that is relevant but not yet ready should continue with a revised date. Scoring them together hides which one is the problem.

Fuzzy gates. A conventional gate is a hard stop: nothing in the next stage starts until the gate is passed. A fuzzy gate is conditional: the next stage can begin on the strength of a partial result, with the condition written down and reviewed at a set date. Research needs fuzzy gates because the clean result often arrives after the next experiment has to be planned.

Go, Kill, Hold, Recycle. Every gate ends with one of four decisions, recorded. Go: continue to the next stage. Kill: stop the line of work and redeploy the resources. Hold: pause, with a date and a condition for restarting. Recycle: go back to the previous stage with a changed question. The vocabulary matters because "we'll see how it goes" is not a decision, and a project with no recorded gate decisions has no milestones in any sense a sponsor can use.

Hybrid approaches of this kind are now ordinary rather than exotic: PMI's Pulse of the Profession 2024 found project teams performing equally well with predictive, hybrid, and agile approaches, with hybrid adoption rising from 20% of projects in 2020 to 31% in 2023. In practice, a research-adapted stage-gate for an 18-month sponsored project has three or four gates, each aligned with a management-level meeting, each with the two criteria written in the project charter before the work starts. The PI keeps freedom inside each stage. The company gets a real decision at each gate.

Which governance model fits? Three archetypes

Governance is the supporting structure for all of the above: the body that holds the decision rights the project leads do not have hears escalations and makes the renew-or-exit call. Three archetypes cover almost every university-industry partnership.

The steering committee. Equal representation from each partner organization, meeting on the management or strategic cadence, holding the decisions above the project leads. Stoppels, Bosch-Rekveldt, Mooi and Bakker, writing in Project Management Journal (2026), describe the steering committee as the body that links the permanent organizations to the temporary project, made up of senior managers who each represent a stakeholder group and who carry the authority to commit their organization. It's the right model for a single substantial project or a small portfolio with two or more partners, and it's the default in the Governance Charter.

The liaison model. Industry representatives embedded with the research program without voting authority over the science, plus a formal board that sets priorities. The authoritative instance is the industry advisory board of an NSF Industry-University Cooperative Research Center: each member company has one representative, the board elects a chair, reviews the research portfolio, and votes on project selection, while the university runs the research. It's the right model for a consortium, where several companies fund a shared program and no one of them should direct it.

The advisory board. Senior people from both sides meeting annually or semi-annually to give strategic guidance that's not binding on the project, with named relationship managers carrying the day-to-day on each side. The pattern suits long-running strategic alliances between one company and one university that span many projects, where the value is in the relationship rather than any single deliverable, and where the executive-level cadence needs a body of its own.

The decision between them turns on four things: the size of the partnership, the number of partners, how IP-intensive the work is, and how long it will run. Our Field Note, Steering committee, liaison or advisory board?, has the decision table.

How should status be reported? The "no surprises" rule

Bamford and Ernst, surveying more than 500 companies for McKinsey in 2002, found that fewer than one in four alliances were adequately measured, and that 30 to 60% were underperforming. The two findings are related. A collaboration that cannot see its own status cannot act on it, and the gap between the stakeholders' perception of the project widens until a sponsor report or a renewal decision forces it into the open.

Our rule that prevents this is simple: no surprises. Any problem is reported at the operational level the week it's noticed, in written status, whether or not it's solved. A slipped milestone is reported as slipped, with the new date, not held until the recovery plan is ready. A result that undermines the project's premise is reported the week it's confirmed. The sponsor hears about problems from the status, never from a meeting called to explain them.

Three habits put the rule into practice. First, a status template used every time at the operational level: accomplishments, blockers, decisions needed, risk flags, the same four headings every week or month. The best-documented university-industry program in the project-management literature, a 54.7 million euro collaboration of about 500 researchers studied by Fernandes and O'Sullivan, ran standardized progress meetings across all its projects to show comparable status updates to the program office across the entire portfolio. Second, a single shared view of milestones and open issues that all stakeholders can read without asking anyone, so the quarterly sponsor report assembles itself from the record rather than from a weekend of email archaeology. This matters more on the academic side than sponsors realize: principal investigators already report spending more than 40% of their federally funded research time on administration (FDP Faculty Workload Survey, 2018), and a reporting structure that adds to that is a structure that will delay information transfer. Third, the three-sentence test: once a month, each relationship owner writes the partnership's status as they think the counterpart would describe it. If you can't, you've found the surprise before it finds you.

What happens when something stalls? Escalation written into the charter

The first real test of a partnership is rarely technical. It's the first disagreement: a scope change one side wants and the other doesn't, a manuscript the company wants delayed, a milestone the PI considers met and the sponsor doesn't. Partnerships with a pre-agreed path through disagreement resolve these in days. Partnerships without one improvise, and improvised escalation gets perceived as a tactic, which makes the dispute worse.

An escalation protocol has three parts: who hears the issue first, how long they have to resolve it, and who hears it next. Our default protocol runs in whole weeks. One week to the project leads: the PI and the company's technical lead try to resolve it between themselves. Four weeks to the steering committee: if it's still open, the relationship owners bring it to the governing body with a written statement of each side's position. Eight weeks to the executives: anything still open goes to the sponsors who signed the agreement. Tailor the windows to your partnership, but write them into the charter at kickoff, before anyone needs them. The charter also records the one rule that makes escalation safe to use: raising an issue is not a breach of the relationship, and nobody is penalized for escalating on time. It's not a failure.

In our Field Note, Escalation before you need it, we give a one-page version of the protocol.

How do you handle publication and IP review during the project?

The agreement should set the rules for publication review and IP disclosure. The Steward phase has to operate them, and this shouldn't be left to chance until the first surprise. A working process has four parts:

A manuscript log. Every paper, poster, thesis chapter, and conference abstract that will come out of the project is listed from the moment it's planned, with its authors, its expected submission date, and its review status. The company reads the log at every management-level meeting. Nothing in it should be news.

Review clocks that start. The agreement gives the sponsor a review window, typically 30 to 60 days, to check a manuscript for proprietary or confidential information and patentable results. In a survey of 107 academic medical centers, 96% accepted sponsor review of manuscripts before publication, 44% capped the window at 60 days and 31% at 90, and more than 85% refused a sponsor veto (Mello, Clarridge and Studdert, 2005). The positions are settled, the failure is operational. If nobody starts or watches the clock, it expires in a dispute. The log records the date the manuscript was sent and the date the window closes.

An owner on each side. One person at the university who sends manuscripts and tracks the clock, one person at the company who routes them to IP, export control, and technical reviewers and returns a decision inside the window.

Invention disclosure in the cadence. A standing item at every management-level meeting: has anything been found that might be patentable, and has it been disclosed to the technology transfer office? Discovering an invention in a manuscript's review window is a surprise that most often turns into an IP dispute.

Our free Contract Red Flags Kit covers the publication and IP clauses that set these rules at the agreement stage.

How does the partnership end? Renew, redesign, or exit

Every partnership ends, and the ending is a decision the executive-level meeting should make at least once a year with three options on the table.

Renew. The objective still holds and the partnership is delivering. Renewal is the moment to revisit the charter, the cadence, and the decision rights for the next phase, since all three were set for a project that has now matured.

Redesign. The relationship is worth keeping but the project is not: the objective has moved, the team has changed, the results point somewhere else. Redesign means a new project charter, often a new agreement, inside an existing relationship. It can be a common outcome in long partnerships and overlooked as a discrete decision, because it doesn't look like success or failure.

Exit. The objective has been met, or won't be. A well-run exit has a closing conversation, a final report, a record of what was learned on both sides, the IP and data disposition the agreement requires, and a door left open. A partnership closed respectfully returns a reference and a future partner. One left to lapse looms overhead for as long as nobody closes it.

The point of making this an annual, scheduled decision is that the default otherwise is drift: the project continues because ending it would require a decision that nobody owns.

Which tools, in plain words?

None of the above requires new software to start, and all of it works better with a shared record. Five jobs need doing, and the question for any tool is whether it does them across the boundaries of multiple organizations.

A shared record. One place all sides can access that shows the project as it is: the people, the roles, the milestones, the files, the log of what changed. Email cannot do this, because every inbox holds a different subset. A spreadsheet can, for a while, if one person keeps it current and all project members can reach it.

Milestones with reminders. Dates with an owner, a status, and a nudge before they slip. The reminder is the part spreadsheets lack. A date in a cell reminds nobody.

Files with an audience. The signed agreement should be visible to everyone on the project, the draft manuscript visible to its authors until it's ready. Most shared drives give everyone everything or nothing.

Discussion with the record. Decisions made in a thread that the next person to join can read, rather than in an email chain they weren't included on.

Meetings that reach every calendar. A meeting proposed from the project, with an invite that lands in each participant's calendar whichever system they use.

The limits of email and spreadsheets were significant in our primary research. In Flowers and Roadman (2024), presented at the R&D Management Conference, the faculty we surveyed described tools that were "insufficient" and processes "adapted around... desktop applications and email... rather than strategically designed." The processes weren't necessarily bad, they were never designed at all.

Our platform's projects workspace does these five jobs for an R&D collaboration: members with roles (admin, editor, collaborator, viewer), invited by email from any organization; milestones with an assignee, a due date and a status, with reminder emails before and after a milestone is overdue; files with folder tags and a per-file audience; a threaded discussion with @mentions; an activity log; meetings proposed from the project that send a calendar invite file to every participant; and the NDA, IRB and contract dates recorded on the project with their expiry and the evidence document. The Free plan provides two active projects with three members each; Pro expands to ten with unlimited members and private visibility.

The tutorial Set up an industry-sponsored project walks through it step by step.

Where to start

If the agreement was signed in the last 30 days, complete our free Governance Charter at the kickoff meeting. It records the decision rights, the governance body, the four-level cadence, the escalation protocol and the review date in one document that each party's project lead and executive sponsor sign, and it takes one meeting.

If you want a shared record in place the same week, set up the project on the Helikon platform with its milestones, reminders, files, and compliance dates.

If you want the whole management design done together with our help, on your live partnerships, our half-day workshop Stewarding the Partnership: Project Management for R&D Collaborations builds the decision-rights table, the cadence, the research-adapted stage-gate, and the sponsor reporting structure with your team, and includes the Research Project Management Toolkit.