Implementing IP Management Software (Part I): Identifying Complexities and Dangers During Implementation

Success is not delivering a feature; success is learning how to solve the customer’s problem.

~ Eric Ries

Imagine that your family has decided to build a new home. You’ve got the vision, but you need to call in the pros—a well-established, highly expert homebuilder with a cadre of architects, designers, contractors, and tradespeople.

You’re relying upon the builder’s expertise to thoughtfully scope the project and prepare you for what lies ahead. This includes (a) helping you understand what financial and other commitments will be required of you; (b) educating you on challenges you’ll face along the way; and (c) highlighting available offerings that align with your vision.

You’re impressed by what the builder’s sales team promises to deliver, so you sign a contract. The price tag is substantial, but you feel you owe it to your family’s future well-being to move forward.

The sales team hands off the project to the builder’s design and construction teams. It’s then that a sobering reality begins to settle in, marked by a litany of unfulfilled promises, delays, surprises, cost overruns, uneven performance, and unresponsiveness.

The only way to salvage the project is for your family to make up the difference, all at incredible sacrifice to daily life. You essentially take a leadership role in the project, do many tasks you thought you’d contracted for, and chip in more money to get the work done. You also give up on the builder fulfilling all contract items.

Now imagine that your company or law firm has decided to implement intellectual property management software (IPMS) with a vendor.

In a worst-case implementation scenario, you may feel like you’re reliving the above homebuilding saga.

Indeed, IP teams often embark on the IPMS journey with great optimism. Once in the thick of implementation, however, they may experience a turbulent journey.

Armed with knowledge of what can go wrong, your enterprise can take proactive steps to drive stronger vendor performance and successfully leverage the power of your chosen IPMS.

IP Management Software

Well known to IP professionals, IP management software provides functionality related to IP assets (e.g., patents and trademarks), disputes, operations, and/or tasks. Other descriptors for such software include IP management system, IP asset management system or software, IP portfolio management software or solution, IP lifecycle management software or solution, and IP docketing system.

IPMS vendors, providers, or developers abound in the IP software and services industry.

In its most basic sense, an IPMS is a database of IP records of an enterprise (e.g., a corporation) or multiple enterprises (e.g., multiple clients of a law firm or multiple business units of a group of corporate affiliates). Besides storage of IP asset data, an IPMS may provide docketing functions to enable the tracking of legal and organizational deadlines and related tasks.

IPMS software has come a long way from its docketing-centered roots. Similar to other enterprise teams such as finance, product management, engineering, marketing, and sales, IP teams are increasingly seeking workflow tools that (a) reduce time-consuming administrative tasks; (b) enable more collaboration within the IP team, with other stakeholders in the enterprise, and with external parties; and (c) help their operations to become data-driven.

The IP software and services industry has taken note. Many IPMSs now provide functionality related to portfolio management, invention disclosure submission, workflows to automate or semi-automate actions, document management, patent annuities, trademark renewals, analytics, invoice submission and processing, and the like. Vendors also are starting to introduce new connectivity (e.g., to cloud services) and modern interfaces to support more optimized workflows, digital transformation, and intelligent automation.

Your company’s or law firm’s decision to buy, implement, and use an IPMS may be quite consequential. Implementation and subscription costs may be high. You may need to commit substantial time and other non-monetary resources to support implementation and ongoing productive use.

No two IPMSs and no two enterprises are the same, resulting in significant variability among implementations and implementation projects.

For example, an enterprise using one IPMS may opt to switch to a new, different IPMS. The new IPMS vendor must migrate data from the current system to the new system.

When an enterprise doesn’t have an existing IPMS, datasets must be created from scratch or aggregated from multiple disparate sources. In one such scenario, a corporation’s IP asset data historically has exclusively resided in respective docket systems of its outside patent or trademark counsel. Now, the corporation wishes to implement its own IPMS to provide a full view (e.g., “shadow docket”) of its IP portfolio, or perhaps to begin insourcing IP work.

Another paradigm involves a corporation comprising multiple distinct business units, divisions, or other subgroups that apply different processes, procedures, and ways of viewing their associated IP. The corporation has decided to implement a singular IPMS that permits customization by business units or standardization of operational practices across such units.

Journey to a Live IPMS

An enterprise’s IPMS journey generally fits within four stages:

• The evaluation stage. The enterprise may examine one or more candidate IPMSs, evaluating their worthiness for adoption based on criteria such as functionality, cost, and reputation. The vendor’s sales team interfaces with representatives of the enterprise, touting the merits of the IPMS via informational meetings, demonstrations, other dialogue, and the provision of test or trial environments.
• The negotiation stage. After the enterprise zeros in on an IPMS, contract negotiations begin. Negotiations may be brief, wherein the enterprise signs the vendor’s contract with no or minimal back and forth. Or, extensive, protracted negotiations occur. Detailed scopes of work for implementation may be developed, presented, and refined. Commercial, technical, and legal terms may be highly negotiated, such as related to cost, subscription term, functionality being licensed, and system performance.
• The implementation stage. Upon contract execution, the vendor’s implementation team takes over, with an objective of getting the IPMS up and running for use by the enterprise. This is sometimes termed getting to “go-live” or “going live.” During this pivotal stage, implementation tasks may be performed by multiple vendor team members and necessitate interactions with, and involvement of, many enterprise team members. Exemplary activities under the implementation umbrella include data and document migration, data validation, system configuration, user acceptance testing (UAT), and user training.
• The subscription stage. When go-live is reached, the enterprise becomes a subscriber or user of the IPMS, and its customer account may be handed off to another vendor team. Notably, its journey has only just begun: Life as a subscriber may usher in a plethora of new challenges, including (a) the need to revamp the enterprise’s internal procedures to enable use of the system; (b) recognition that IPMS configuration changes may be needed based on current and evolving IP team processes; (c) upheaval associated with upgrading to new IPMS versions; and (d) inconsistent vendor performance. Beyond subscription fees, the vendor may charge for development work related to new projects, such as projects to customize the user’s experience or deliver other requested functionality. Whether the vendor and its IPMS deliver what the enterprise is seeking may not become clear initially, and the parties’ relationship may be tested over time.

The Complexities of Implementation

Some IPMS implementations may be relatively compact and straightforward. An enterprise may have a small portfolio of IP assets; it may have an existing IPMS containing clean data that merely needs to be migrated to another IPMS; or it only requires an entry-level IPMS for basic docketing functions.

Other IPMS implementations may be complex or extremely complex. In particular:

• An enterprise may have thousands or tens of thousands of IP assets that require corresponding records in the new IPMS. Data may currently reside in a single system whose data fields and formats diverge widely from those of the new IPMS, or in many disparate systems with similar divergence. In either event, data may not be clean or complete.
• Metadata about the IP assets may need to be inputted or corrected. Organizational data may need to be created for corporate legal entities and law firms managing IP prosecution. Product, technology, brand, or billing data may need to be confirmed and associated fields populated, sometimes manually on an asset-by-asset basis.
• Massive amounts of document data may need to be migrated to and ingested by the IPMS.
• Security policies, workflows, and other IPMS configurations may need to be devised and programmed.
• Conversion programs may need to be developed to enable unidirectional or bidirectional data transfer with third-party systems, such as billing systems.
• Many vendor and enterprise participants may be involved in the implementation, with other projects or duties vying for their bandwidth.
• A vendor doesn’t intimately know the enterprise’s business. Nor is the enterprise likely expert in, let alone moderately experienced with, IPMS implementations.

The list of complexities goes on.

Troubling Scenarios During Implementation

What can go wrong during implementation? Potentially many things. Enterprises may experience turbulence such as:

1. Lackluster project leadership and execution

An enterprise may discover that its vendor approaches implementation principally as an exercise to migrate data and provision IPMS features, rather than as a project to deliver solutions closely aligned with the enterprise’s vision and needs.

For instance, the vendor makes no meaningful attempt to ascertain the enterprise’s current organizational, competitive, and IP ecosystem; its imagined future state; or other pertinent fundamentals. The vendor says things to the effect of, “Our software does this,” versus “What are your pain points?”, “What do you want to accomplish?”, and “This is how we can help you get there.” It seems to lack the desire or capacity to truly lead the project; passion for innovation and high service delivery are in short supply.

As a result, the enterprise expends significant energies just trying to be heard by the vendor. It feels that it must take the lead to compensate for the vendor’s lack of direction.

In addition to demonstrating poor leadership, a vendor may struggle mightily with execution of its implementation plan. A project team that acts passively, reactively, or incompetently is undesirable in any IPMS context. However, in particularly complex implementations, the enterprise’s troubles will be substantially compounded by the vendor’s shaky performance.

2. A Pandora’s box of unwelcome surprises

Surprises can arise in every implementation. In an implementation gone south, an enterprise may confront numerous surprises that seemingly could have been avoided but for the vendor’s action or inaction. Examples include:

1. The IPMS doesn’t do what the sales team said it can do.
2. The IPMS theoretically can do what the sales team said it can do, but the vendor won’t actualize the relevant functionality unless the enterprise pays for custom software development or other services not contracted or budgeted for.
3. The sales team neglected to highlight an aspect of the IPMS that renders it undesirable to the enterprise or incompatible with its technology or operational infrastructure or other intended use cases.
4. The sales team glossed over technical challenges or limitations related to the IPMS or its interaction in the enterprise’s ecosystem, assuring the enterprise that they could be easily surmounted.
5. The sales team grossly underestimated or underrepresented the time it would reasonably take to complete the implementation stage.
6. The parties’ contract doesn’t clearly address, or is silent on, a troublesome situation that the vendor could have foreseen based on its work with other customers yet neglected to factor into its contract template.

3. Revisionist storytelling

As implementation problems arise, go-live seems ever distant, and it’s unable to collect subscription fees, a vendor may take strained positions in hopes of bringing money in the door.

For example, contrary to a negotiated contract and the clear understanding of the parties, a vendor suddenly asserts that it’s owed subscription fees despite not having completed the implementation stage and delivered the IPMS for the enterprise’s use. The enterprise is asked to accept the notion that go-live means to provide a test environment or perform implementation tasks.

4. Poor relationship management

The implementation stage may reveal flagrant weaknesses in how the vendor approaches its customer relationships. The vendor may consistently stumble in such foundational areas as managing expectations, fostering healthy communications, and resolving major and minor problems. These deficiencies erode the enterprise’s trust and hamper the parties’ ability to navigate the turbulence of implementation.

5. Massive allocation of enterprise resources

An implementation may require significantly more commitment from the enterprise than the vendor stated would be reasonably required. Internal stakeholders, including IP team or practice group members, must dedicate precious additional time, effort, and money to support the implementation and bring it to fruition.

Dangers of an IPMS Implementation Gone Wrong

Many of the above scenarios stem from the vendor. Simply put, it overpromised and undelivered. Others may be unavoidable, a byproduct of complexity or other realities that the parties did or could not anticipate despite their best intentions.

Whatever the cause, a troubled IPMS implementation brings dangers to the enterprise beyond delays and extra costs.

The enormous time devoted to the project takes team members away from other activities and disrupts ongoing work. Added costs and prolonged project completion may undermine the credibility of enterprise leaders who championed adoption of the IPMS. Team morale may suffer.

Moreover, a plagued implementation may sabotage a team’s efforts to deliver visionary, disruptive changes to the enterprise.

To avoid these dangers, companies and law firms should take proactive steps to ensure as successful an IPMS implementation as possible, which we will explore in Part II of this series.