Skip to main content
Helikon Labs

← Back to the Research Blog

You signed the research agreement. Now what? How to run the project from day one

Andrew T. Flowers ·

The day after a research agreement is signed, the partnership passes from the people who negotiated it to the people who have to run it, and almost nothing in the agreement tells them how. Four things change: who is accountable for common decisions, how often the two sides talk, what counts as progress, and how disagreements get escalated. Partnerships that decide and record these in the first month tend to deliver. Partnerships that leave them to habit drift, one unmade decision and one unshared assumption at a time.

That's the short version. The rest of this post is the evidence for it and the smallest design that holds.

Why does the signed agreement feel like the finish line?

Because for most of the people involved, it was the hardest part. The agreement took months. It had counsel on both sides, rounds of redlines on IP and publication, and last-minute questions about indirect costs. When it's finally executed, the kickoff call happens, everyone says the right things, and then everyone goes back to their day jobs.

The strategic-alliance literature puts alliance failure anywhere between 30 and 70%, a range Kale and Singh cite in their Academy of Management Perspectives review of the alliance research. The same review locates the difference in an unglamorous place: not deal terms, not partner prestige, but whether anyone manages the alliance as ongoing work after it's signed. Firms with a dedicated alliance-management function succeed about 70% of the time against about 40% for firms without one. Thirty points of outcome, attributable to management.

In the Helikon Method this phase is Steward, and it's R&D project management under another name: the longest and most consequential phase of a research partnership, and the one with the least ceremony attached to it.

What does an unmanaged partnership look like from the inside?

Nobody decides to run a partnership unmanaged. It happens by omission, and from inside it looks normal.

Status lives in email threads, so assembling the real picture takes a day and happens only when someone senior asks. Meetings happen when someone calls one, which means they happen after problems rather than before them. Decisions queue for the quarterly steering committee meeting, if there is one, including decisions that needed an answer in week two of the quarter. Each side has someone who informally owns the relationship, in the gaps between their actual duties. And both sides hold expectations the other has never heard stated out loud.

I managed against this pattern for years on the industry side, running R&D portfolios that depended on university partners, and the faculty we surveyed for our primary research described the same condition from the university side. In Flowers and Roadman (2024), an exploratory survey of faculty at public research universities, the processes behind their collaborations were described as "adapted around... desktop applications and email... rather than strategically designed."

None of this looks like a crisis on any given day. It compounds. The partnership doesn't fail in a single meeting, but over months of passive management.

Translation Box: status report

On the academic side: a narrative of experimental progress, what the last result suggested and what the group will try next. Dates are approximate because the scientific method decides them.

On the industry side: a one-page view against plan. Which milestones are on track, which have slipped, what the slip means for the decision the sponsor has to make next quarter.

In a research partnership: both, on one page, on a schedule. The narrative explains the plan, and the plan gives the narrative a frame the sponsor can act on.

Does structure change outcomes?

The case that explicit project management structure drives outcomes doesn't rest on consulting intuition. Three evidence streams are worth knowing.

The stage-gate record. Robert Cooper's research on product development found that companies running formal stage-gate processes achieve new-product success rates of roughly 63 to 78%, against industry baselines of 25 to 45% (Cooper, Edgett and Kleinschmidt's Stage-Gate research, summarized here). The model is used by 75 to 80% of North American product developers (Cooper, 2008). The mechanism is forced decision points: structured moments where the work is reviewed against criteria and someone with the authority decides to continue, redirect, or stop. Research collaborations need that mechanism even more, because no single organization's management system can see everything.

The designed-program case. The best-documented university-industry program in the project-management literature is a 54.7 million euro collaboration of about 500 researchers in Portugal, studied by Fernandes and colleagues in the Journal of Technology Transfer. Their analysis produced the PM.UIC framework: 29 transversal practices every project in the program used, and 30 contingent practices applied where the project needed them. The transversal practices are what you'd expect and what most partnerships skip: a program office staffed by both partners, documented decision rights at each level, charters signed by both the academic and the industry lead, and progress meetings that produce comparable status across every constituent project. What seemed like luck was design.

The corporate-side record. In a three-year study of 25 companies and more than 100 university projects, Pertuzé, Calder, Greitzer and Lucas found in MIT Sloan Management Review (2010) that about 20% of all the projects showed an observable effect on the company. The practices that separated the ones that did aren't deal terms: a project manager with the authority to carry the results across boundaries, a standing communication link with the university team, and internal support for the work until the result could be implemented. All of them are habits, and all of them start the week after signing.

Most partnerships need a fraction of what that Portuguese program built, but every partnership needs a deliberate answer to the questions asked next.

Who decides what, and how do disagreements escalate?

This is the section most kickoff meetings skip, and the one that decides the first bad month.

Decision rights. Many delays in a research collaboration aren't necessarily hard decisions. They're decisions nobody was sure they were allowed to make. A one-page table fixes that: which decisions the project leads can make alone (the order of experiments, a change of method, minor changes that don't impact budget or timeline), which need both relationship owners (a scope change inside the budget, a new team member, a publication outside the agreed review clock), and which go to the steering committee (a change of objective, money, IP, anything that affects the agreement). Write it at kickoff, while every example is hypothetical and nobody's defending a position.

Escalation. The first real test of a partnership is rarely technical. It's the first disagreement, and partnerships with a pre-agreed path through it spend days on what costs others months. The path needs three things: who hears it first, how long they have, and who hears it next. Our default runs in whole weeks: one week to the project leads, four weeks to the steering committee, eight weeks to the executives. Tailor the windows to your partnership, but write them down before anyone needs them, because a protocol proposed during a dispute reads as a tactic.

Both of these live in a document that sits beside the agreement and can be amended without reopening it. We publish ours as the free Governance Charter: parties and scope, the governance body, a RACI for each class of decision, the four-level meeting cadence, the escalation protocol, a review date and signatures. It takes a kickoff meeting to complete, and it's the single document most partnerships wish they had in month eight.

What's the minimum project management design?

Here's the Steward-phase structure we install in engagements, scaled for a single project or a small portfolio. Five components.

1. Named relationship owners, with time. One person on each side owns the partnership's health, distinct from owning the research. The role needs hours attached to it. A title without time changes nothing. When this role is unfilled, the missing alliance-function failure rates above are describing your future.

2. A meeting cadence set in advance. At minimum, two tiers: a short operational sync (weekly to monthly) where the working teams raise issues, and a management review (quarterly) where the institutional stakeholders decide directional questions. Longer partnerships add a semi-annual strategic review and an annual executive one. The failure this prevents: operational issues waiting 11 weeks for the steering meeting, and steering meetings consumed by operational triage.

3. Decision rights below the steering level. The RACI matrix from the section above.

4. Status both sides can see. A single shared view of milestones, deliverables and open issues, updated on a schedule, visible without asking. A shared spreadsheet kept current beats a sophisticated tool nobody updates. This is also where a purpose-built workspace earns its place, once the habit exists: our Helikon platform's projects workspace holds the milestones with owners and reminders, the files, the discussion and the log, in one record both sides can access.

5. An escalation path with a clock. The protocol from the section above, signed.

A note on reporting, because research partnerships have a sponsor on at least one side: the reporting burden should fall on the structure, not the researchers. If the shared status view is real, the quarterly sponsor report assembles itself from it. Where reporting requires a quarterly scramble, that's a symptom that component four is missing, not a reason to add more reporting.

The monthly habit I recommend alongside all five: write a few sentence status of the partnership as your counterpart would describe it. If you can't, that's your early warning.

If you'd rather build all five components on your live partnerships with your team, together with our help, our half-day Stewarding the Partnership workshop produces the working versions: the milestone and status frameworks, the decision-rights table, the cadence and the sponsor reporting structure. It includes our Research Project Management Toolkit.

Why is publication and IP review a project management problem?

One Steward-phase issue deserves its own paragraph because it's one often left to chance: the standing tension between the university's need to publish and the company's need to protect. The agreement sets the rules (review windows, redaction rights). The Steward phase has to operate them: a log of manuscripts in the pipeline, review clocks that actually get started, and an owner for the process on each side. IP disputes caused by publication surprises or last-minute reviews can be prevented by a working pipeline log.

Where should you start?

If you have an active partnership with none of the five components, start with one and four. An owner and a shared status view, installable in a week, remove the largest share of the drift.

If you're forming a partnership now, complete the Governance Charter at kickoff, within 30 days of signature, while the relationship is fresh. Governance agreed at formation gets perceived as prudence. Governance proposed in month eight reads as an accusation.

If you want the full picture, the plain guide to how to manage a university-industry research collaboration covers the cadence, the research-adapted stage-gate, the three governance models, and the close-out options in one place.

Whichever you start with, the habit is easier to keep when both sides work from the same record. On our Helikon platform, a project holds the members from both organizations with their roles, milestones with an assignee, a due date and reminder emails before a milestone is due and after it's overdue, the files, a threaded discussion and an activity log. A project needing an NDA, IRB approval, or a contract signature or renewal gets flagged while that date is missing, so the agreements and the work stay in step. The free plan gives you two active projects with three members each, enough to run your first partnership this way, and our step-by-step tutorial walks through setting one up.

Start free on Helikon Labs

If you'd rather talk through your own partnership first, book a free 30-minute scoping call.

Sources

ShareXLinkedInEmail

Related posts