Governing Innovative Relationships

INTRODUCTION

Over the 2023-24 Christmas and New Year break, the United Kingdom was captivated by a 4-part TV dramatization about a long-running dispute between the Post Office and hundreds of sub-postmasters who had been wrongfully convicted of stealing from their Post Office branches. At the heart of the dispute is a software system. A lengthy, judge-led public inquiry into what exactly went wrong is ongoing, and hundreds of convicted sub-postmasters have had their convictions overturned in unprecedented UK legislation.

The Post Office Inquiry is a timely moment to reflect on key elements of governance in a project to develop an innovative solution. In particular, the implementation of appropriate governance regimes, creating processes so that parties can track and be held accountable for their project inputs, and the importance of reporting and communication between project participants.

In this article, we discuss the importance of implementing the following three key elements of “governance practice” in innovation relationships:

• development and testing methodologies;
• traceability and assurance practices; and
• reporting and communication mechanisms. 

Development and Testing Methodologies

Parties should tailor their governance regime to the specific project, which will ultimately depend on the collaborating parties and the scale of the project. For instance, parties may implement an agile development methodology where the innovation relationship relies on flexibility and adaptability. This may be seen in early stage product development arrangements, perhaps with relatively small suppliers, where the anticipated outcome is often quite general. In this case, the flexibility afforded by the agile development methodology may suit the project, as a detailed governance structure involving many checkpoints could otherwise reduce the ultimate benefit of the project due to the higher costs and resource requirements. That being said, the added flexibility also presents challenges for the parties to consider—such as the added flexibility possibly leading to unpredictable project timelines and associated costs. Alternatively, implementing a waterfall development methodology—comprised of sequentially delivered project “phases”—may present a more appropriate governance practice in more established development arrangements where parties can clearly foresee project milestones.

While the general framework of interactions between the parties might be set out in an overarching Master Services Agreement and subsequent Work Orders, an effective governance process for a particular development is likely to require appropriately skilled representatives (for example, agile development specialists for an agile development project) of each party to interact on an agreed basis. In addition, there will also need to be an escalation process and control of the budget. A previously agreed general governance structure may be impractical if it is not aligned with the people and processes that the parties will actually bring to the project.

Additionally, where the final output of the development is described by reference to general terms rather than specific requirements, it can be difficult to determine exactly what will be considered a satisfactory result for the development project. For instance, in the UK Post Office Inquiry, there was a contractual requirement that the software be “robust.” The counsel to the Inquiry spent time examining what exactly was meant by the general term “robust.” In the end, no clear meaning emerged. Where it is not possible to define performance levels or other objective standards at the outset of the relationship which can be tested throughout the project lifecycle, best practice may be to set out a governance process around the development activities which leads to the parties having sufficient knowledge to define and align on an acceptable standard of performance and understand the residual risk, if any, in the end product of the development process.

Traceability and Assurance Practices

For innovation projects, the parties will want to understand and address the intellectual property and data risk. Some risks may be difficult to measure—for example, if a third party has a patent application covering the innovation and, at the time of the adoption of the innovation, it is not possible to identify the existence of the application—but many other risks can be identified and addressed. Each party may contribute owned intellectual property and data—of which, ultimately, the contributor will want to retain ownership—and licensed-in intellectual property and data. If that is done informally, in joint working sessions, it can be difficult to know who has what rights to the end product. 

If the governance model of the relationship creates effective traceability and assurance, the necessary rights can be secured and documented more easily. Doing so can help the parties to track where intellectual property and data contributions came from, as well as the basis upon which the developer and the customer are free to use them. Failure to do so can present challenges, both to the contributor and the development project as a whole—such as being able to identify which third-party rights have been introduced into the development, who is accountable for those inclusions and the subsequent impact this information has on the enforceability of the contractual protections agreed between the parties. Practically, associated challenges can be demonstrated in the following two examples:  

• Third-party infringement risk: Contributors introducing licensed-in intellectual property or data to the project must have appropriate sublicensing rights from the third-party owner. Introducing the licensed-in intellectual property to the project without the sublicensed right may constitute a breach of the license – potentially exposing the parties to the project to an infringement claim from the third-party owner if, say, the final output is a good/service using third-party intellectual property/data. Parties can seek to limit their risk exposure in this instance through ensuring appropriate third-party intellectual property/data infringement warranties and representations, or even indemnity protection—which is something commonly sought in the United States.  
• IP/data rights dilution: The value (be it practical and/or commercial value) of intellectual property generated by the project may be diluted where the intellectual property/data rights contributions to the project cannot be effectively traced. For instance:
• Open source: Assuming a scenario where the development project generates a software solution which is intended for external supply, governance measures should include tracing what, if any, open source software has been introduced into the software solution—in particular whether any viral copyleft open source code has been introduced in a manner requiring the developed source code to be made publicly available.
• Registered IP requirements: Tracing contributions to existing intellectual property rights may be a pre-requisite to obtaining registered intellectual property protection in certain jurisdictions. For instance, in the context of patent applications for AI inventions, where courts in the United Kingdom, United States, European Union, and Germany have each held in recent years that a patent’s inventor must be a “human,” hence underscoring the importance of being able to trace individual contributions in the development arrangement. 

Reporting and Communication Mechanisms

A cornerstone of a successful innovative relationship will be the ability of the parties to report on project progress and generally communicate to one another in an open and collaborative manner. Through introducing established reporting and communication channels into the project governance framework, the parties can mitigate negative impacts of changes to the success of their projects and allow them to plan contingencies and safeguards. Governance practices which facilitate reporting and communication channels and which parties may consider include:

• Regular reporting mechanisms: Requiring a party to deliver regular reports facilitates the exchange of information and allows the participants to work through unanticipated problems and provides them with an opportunity to recognize, and discuss pursuing, new opportunities which become apparent after the development begins. The mechanism can be implemented in a number of ways, such as scheduled reporting obligations (either based on a cyclical basis or on completion of milestones). The regular updates allow both parties to track the progress of the project, including performance, against any pre-defined deliverables/project milestones, in a uniform manner.
• Oversight and decision-making: In certain circumstances, it might be appropriate to appoint specified individuals (either named or by reference to their position) to exercise management oversight and to hold decision-making power in respect of the project or its aspects. Doing so allows the parties to better understand which individuals need to be informed of progress and contacted when issues are identified. Negotiating a chain of command at the outset of the relationship may also assist parties in making clear, authoritative, and timely decisions down the line. The size of the oversight structure will depend on a variety of factors, including:
• the geographic reach of the project—where local representation may be required from a language, as well as local regulatory, perspective, and
• the subject matter of the project—where the project involves particular risks or touches on regulated aspects of the business, such as data privacy, cybersecurity, consumer rights, or supply chain risk. In such cases, the parties may want to ensure that appropriate specialized personnel is involved in the oversight and decision-making structure to steer through any issues involving their expertise.

A governance process for innovation should also consider all relevant stakeholders, not just the core project management team. As an example, in the UK Post Office Inquiry, a key forensic report into potential problems with the software implemented by the UK Post Office concluded that there was no effective forum for end users to raise concerns about the new software. In this example, good governance would have included meaningful engagement with the end users. Projects of a different nature may necessitate seeking feedback from suppliers or customers. The parties should consider if any external partners are relevant to the development and decide on an appropriate level of their involvement in the governance structures.

Conclusion

While the final report from the UK Post Office Inquiry is not expected until 2025, the interim reports and the evidence heard from individuals suggest that weak governance may have contributed to the unlawful prosecutions and convictions. What once was described by the developer of the software at the heart of the UK Post Office Inquiry as the “largest non-military IT contract in Europe,” ultimately allowed “one of the greatest miscarriages of justice,” as described by the former UK Prime Minister Rishi Sunak.

There may be no “one size fits all” approach for governing an innovation arrangement, but through implementing appropriate governance practices organizations can position themselves and their projects for success. As discussed in this article, these governance practices may include implementing appropriate testing and development methods to allow the parties to track progress and decrease the risk of a dispute, establishing mechanisms to trace what intellectual property or data contributions in the project to mitigate third-party infringement risks and maximize value of the project’s intellectual property outputs, and establishing communication and reporting channels to ensure the regular, structured exchange of information and facilitate the ability of the project to adapt and develop through established oversight and decision-making structures.