A partnership in a technology project is usually announced with enthusiasm and assessed with vagueness. An agreement is signed, the photograph is published, and two years later nobody can say what changed. Measuring the impact of a partnership means deciding, before it starts, what it is supposed to change.
Three different things called partnership
They are worth separating, because each has its own metric:
- Resource partnership — one side funds, the other delivers. Measured by delivery on time and on budget.
- Capability partnership — each side brings something the other does not have. Measured by what would not have been possible alone.
- Access partnership — one side opens up a field, a user base or a test environment. Measured by the quality of the validation obtained.
Confusing the types produces crossed expectations: whoever came in for access demands delivery, whoever came in for resources demands publication.
The impact that shows and the impact that does not
The visible impact is the product: the device that came into existence, the process that became cheaper, the paper that was published. That is what goes into the report.
The invisible impact is usually larger and rarely recorded: the company team that learned a validation method, the student who understood an industrial constraint, the network of contacts that makes the next project possible. That kind of return does not fit a delivery indicator, but it is what makes the second partnership better than the first.
What to agree before signing
Four points prevent most of the friction:
- Intellectual property — who owns the result, and what may be published, and when.
- Closing criterion — what marks the project as finished, including in the case of a negative result.
- Communication rhythm — how often and in what format each side reports.
- Confidentiality — what is sensitive, and for how long.
None of these points is hostile. Leaving them implicit is.
A negative result is a result too
A partnership that concludes, with evidence, that the proposed solution is not viable has delivered real value: it avoided a larger investment. That is only recognised if it was agreed beforehand that such a conclusion is acceptable.
When the contract admits only success, the team tends to dress up the result — and the cost shows up later, larger.
Getting started
If you are weighing up a technical partnership and want to discuss scope, feasibility and format before formalising it, talk to LIPS. That first conversation usually clarifies more than several exchanges of documents.