Implementing IP Management Software (Part II): Best Practices for an Improved Implementation

As discussed in Part I of this series, the process of implementing IP management software (IPMS) poses many complexities and dangers. To ensure as successful an IPMS implementation as possible, companies and law firms should apply best practices early on. The earlier they begin taking these steps, and the more deeply they dig into the issues, the greater their chances of avoiding the most common implementation pitfalls.

Consider these best practices:

1. Choose the right vendor.

Your choice of IPMS vendor is vitally important. A highly competent, engaged vendor will help drive innovative problem solving and effective project management during both steady and rough times.

When vetting a vendor, pose questions such as the following:

a. How customer-centric and visionary is the vendor? What is its product roadmap, and what is its track record in evolving its IPMS offering?

Unless perhaps you’re seeking basic, no-frills IPMS functionality, be wary of a vendor that struggles to articulate a product vision and plan to improve its IPMS, and that has little to show for years in business but incremental product evolution. Otherwise, later you may be met with shrugged shoulders and apathy from the vendor when you raise reasonable concerns and plead for their resolution, and when you request the development of new or enhanced functions.

Speak with multiple existing customers of the vendor to infer the vendor’s innovation culture, its passion (or lack of passion) for understanding its customers’ needs, and its capacity to consistently deliver excellent customer service.

b. How does the vendor structure its teams relative to IPMS stages, and how are its team members’ performance measured and rewarded?

If the vendor’s teams largely operate in silos (e.g., the sales team is distinct from the implementation team), you may experience a fitful handoff between IPMS stages. Team members may lack a holistic and deep understanding of their IPMS and your needs. Vendor missteps, communication disconnects, and other forced errors may result.

The vendor’s internal compensation incentives also may be lurking in the background. For instance, if the sales team is paid a commission based only upon signing up a new IPMS customer, they likely won’t be incentivized to go the extra mile to contribute to success during implementation and beyond.

c. Where is the vendor in its corporate lifecycle? What internal dynamics may impact service delivery to you?

It’s no secret that the IP software and services industry continues to consolidate. IPMS vendors may have recently acquired, or been acquired by, a company, or may be preparing for acquisition activity, which may motivate their near-term actions and affect their long-term suitability as a partner.

Also, like any organization, IPMS vendors progress through growth stages. Although early on, a vendor may have relentlessly sought to create innovative solutions, it may, upon reaching a certain size or maturity, employ a business model that entails signing up as many new subscribers for its core or standard offerings as possible. If so, it may not be the right vendor for every potential customer, irrespective of what its sales teams profess. More fundamentally, its solutions may lag behind the emerging state of the art.

2. Choose the right IPMS.

The IPMS selection process should encompass more than your team preparing a checklist of desired features and a matrix of pros and cons for candidate IPMSs. It should aim to delve deeply into an IPMS, shining a light on critical issues that might not be top of mind to non-experts in the IPMS space. Explore the following exemplary questions:

a. What is the standard or typical customer of the IPMS, what IP operations does that customer outsource and insource, for what purposes does it leverage the IPMS, and how do its team members and other stakeholders interact with the system on a daily basis?

It’s essential that you accurately assess how much the IPMS is being used by others in the ways you aim to use it. If your use cases differ considerably from those of most current customers of the IPMS, you may experience inertia when trying to use the system as you wish, or when seeking the vendor’s support in helping you to realize your vision.

For example, if your company intends to use the system for management of an IP portfolio whose prosecution is outsourced to outside counsel, you may not need docketing functions per se; nevertheless, a given IPMS may be architected chiefly as a docketing system for companies that insource their prosecution work.

Confirm the sales team’s assertions that portfolio management and workflow functionality are fully baked in, rather than clunky or underdeveloped bolt-ons to a system that only really excels at docketing.

b. Is the IPMS built on a proprietary or closed philosophy, or one that promotes interoperability with other vendors’ solutions?

Some IPMS vendors want to lock you into their system. This may make it technically difficult and quite costly, if not impossible, for the IPMS to interface with other systems to promote efficiency and achieve other operational and functional synergies.

Interoperability is a key issue to explore, especially if your aspirations include using the IPMS in a larger ecosystem of internal and external IP tools, legal operations systems, and finance systems, among others. Ask the vendor to describe the data formats used by its IPMS, identify whether they are proprietary, and confirm whether its API (application programming interface) is open and free for use by third parties.

Also ask the vendor to specifically enumerate systems with which it is compatible, the nature of the compatibility, how long the compatibility has been available, its extent of use across IPMS customers, the technical steps and costs required to leverage the compatibility, and who is responsible for taking such steps (e.g., the vendor or a third party).

Don’t forget to consider contingency planning. Inquire with the vendor how readily you can extract your IPMS data if the vendor ever ceases operations. Determine whether the IPMS database can be periodically backed up to a location you control.

c. How will the IPMS facilitate (or not facilitate) you keeping IP asset data up to date?

Data currency is a crucial requirement for most enterprises. The question thus arises: after the vendor migrates existing IP asset data into the IPMS for go-live, how will updates be made to the associated records, and how will new assets be captured in the system, on a go-forward basis?

Law firms with a large stable of clients, as well as corporations that insource prosecution work, may be ready and willing to field a docketing team to manually enter data in the IPMS. On the other hand, companies with budget-constrained or intentionally lean IP departments may not have the luxury or desire to staff up.

Investigate the relative capabilities of the IPMS. Does it have an open API that enables automated docketing via third-party solutions, avoiding needless manual data entry? To what extent can it keep data current by tapping into data feeds from patent and trademark offices around the world, or from other data aggregators?

Does the IPMS allow for batch uploads or importing of data via spreadsheets (e.g., supplied by outside prosecution counsel) as an alternative to manual data entry? Are those spreadsheets in standard format (e.g., Excel) or in proprietary or non-standard format (e.g., XML) that will require costly conversion efforts to be undertaken before the data can be ingested? How much manual labor is required to effect the uploads?

Answers to these questions will help you assess how administratively burdensome and expensive it will be for your team to keep your IPMS data current after go-live.

d. How does the IPMS manage security? Does the vendor or its cloud service provider’s deployment architecture raise data protection, privacy, or export control issues?

Involve information technology teams and relevant legal subject matter experts in your related diligence on these questions. Engage in fulsome questioning, rather than accepting summary statements from the vendor such as “Yes, we do that,” or “That’s not a problem. We can address that during implementation.”

e. How much customization is needed, who customizes, and at what cost?

Some IPMSs are highly configurable or customizable. To customers looking for an adaptable or bespoke solution, this sounds promising. Getting down to brass tacks is imperative, however. You need to understand whether you can self-configure the system, how easily you can do this, and the associated limitations. If the vendor can customize aspects on your behalf, what are those aspects, and how much will it charge?

f. Does the IPMS function on par with, better than, or worse than modern desktop software?

The philosophy of software design, especially user experience (UX), matters greatly in an IPMS. What is the point of implementing an IPMS if IP team members view it as a cumbersome tool that reduces their efficiency?

In assessing the UX of an IPMS, a good rule of thumb is whether the software provides similar functionality to the modern computer desktop suite. Consider these questions:

• Can you drag and drop information?
• Can visible information be configured quickly?
• Can information be processed easily, ideally with a single click to accomplish a task?
• Are security permissions, workflows, and reports easy to set up and configure?
• Can you hand off tasks quickly?
• Can you modify, import, and export information easily?

If the answer to these questions is “no” or “not really,” you may want to turn your attention to a different IPMS.

g. Besides the enterprise’s core IPMS users, how can internal and external stakeholders interact with the IPMS? What are the limitations?

Some IPMSs enable multiple classes of internal and external users to access the system. In so doing, vendors claim that, using their IPMS, customers can exploit the full power of their collaborative ecosystem, providing upstream and downstream benefits to all concerned.

For instance, a law firm customer may grant its clients limited access to its IPMS, or a corporate customer may grant its outside counsel access to IPMS records under their care. Or an IP team in a corporation may allow internal clients, such as product management, engineering, or marketing personnel, to access information in the IPMS.

Although such functionality sounds alluring, you should drill down to explore the nature of such access and associated limitations. Require your vendor to supply detailed answers to questions such as these:

i. Can classes of users or individual user logins be added by the customer at will? Can a user receive access to all records, specific records, portions of records, and/or types of records (e.g., records associated with a given organization, technology, brand, or business unit)? What level of access is available (view/read only, read-write, record creation, modification, and deletion, etc.)?

ii. What reports are available to users? Are reports specific to one user or class of users? Can a user create and share reports for access by core IP team members or other internal or external users?

iii. Can someone access information in the IPMS (e.g., click on a hyperlink to peruse an IPMS report or dashboard) without having a login?

iv. What user interface is presented to non-core users of the IPMS?

v. For enterprise customers with multiple divisions or business units that intend to provide each division or business unit with partial, but not full, visibility to the records or information of another, what are the options? Can visibility be provided to records, reports, or neither? Can the customer’s IPMS administrator or superuser selectively configure which subsets of data are visible?

3. Demand that the vendor undertake a detailed discovery process.

Hindsight has shown unwitting IPMS customers the glaring limitations of a high-level sales and implementation process in which a vendor emphasizes features delivered by the IPMS, not its alignment with solutions needed by the customer.

Accordingly, you should require the vendor to conduct a robust discovery process structured to elicit pertinent insights about your enterprise’s vision, perceived needs, and ecosystem. A vendor whose teams are unable to furnish evidence of a structured process should raise red flags.

The discovery process should include detailed, probing written questions on a multitude of issues, including those pinpointed herein, and should be built upon the vendor’s past experiences with other customers. Through such a process, the vendor can develop wide-ranging insights on your needed, desired, or unappreciated use cases. The vendor also can anticipate the future implications of decisions.

How the vendor documents and applies learnings from the discovery process may illuminate whether it’s likely to provide capable leadership going forward, rather than you having to constantly prod it to act. Press the vendor to show you the documentation it’s developing and to explain in depth its processes for handing off information to vendor team members. If the vendor lacks stringent recordkeeping and strong hand-off processes, you and colleagues at your enterprise likely will bear responsibility for educating and orienting new vendor personnel at each subsequent IPMS stage.

Conversely, when these elements are in place, information gathered by the discovery process can directly feed into planning for implementation and can facilitate collaborative, coherent efforts by vendor participants across the IPMS stages.

Ultimately, a robust discovery process helps the vendor and you to more realistically determine whether the IPMS likely can deliver what your enterprise is seeking. It also can tease out a host of issues that will need to be surmounted through implementation, preempting many of the surprises and other troubling scenarios discussed above.

4. Negotiate IPMS contracts with care.

An IPMS contract that sets a clear framework for the customer-vendor relationship, addressing both fundamentals and contingencies, will help reduce misunderstandings between the parties and enable smoother, more constructive resolution of issues arising during the IPMS journey.

In addition to customary commercial terms, make sure that your contract is tightly crafted in areas such as:

• Define in detail the technical scope of what is to be performed and delivered by the vendor.
• Clearly enumerate the fees and the allowability of, and bases for, fee increases during the contract term. Delineate precisely between types of fees, such as implementation and subscription fees.
• Define go-live or going live to mean the date on which (a) implementation has been completed and (b) you the customer actually can begin productive use of the system.
• Subscription fees should become due only when go-live status is attained.
• What time commitments is the vendor making regarding getting to go-live status, and what happens if it misses the target date? Are financial penalties, credits or refunds, or other recourse available to you?
• Address the implications of other material project delays.
• Include crisply defined milestones for payments, including associated deliverables or criteria for evidencing they’ve been met.
• Build in termination options tied to poor vendor performance, failure of the vendor to deliver what was promised to you, or material omissions made during the sales process.
• Address how additional software or services will be scoped and contracted for (e.g., through change orders).

5. Form a cross-functional team.

In view of the many potential challenges ahead, you’ll be in a much stronger position by involving various stakeholders and subject matter experts along the IPMS journey. These include IP professionals, information technology professionals, general legal advisors, sourcing or procurement leaders, and finance directors within your company or law firm. Besides internal collaborators, you also may want to consider hiring an external project consultant to supplement experiential or knowledge gaps.

The more eyes on the IPMS stages, the more you can counter the complexities. Likewise, a collaborative approach can temper the effects of optimism bias and other cognitive biases that may infect your ability to think through the project in its many dimensions and depths.

6. Manage your team’s expectations.

Embarking on the IPMS journey is not for the faint of heart. As such, consider bracing your team for bumpy terrain. Overcommunicate with your team and other organizational leaders on project status, challenges, and actions you’re decisively taking to meet those challenges. Periodically reemphasize your vision and the benefits that the IPMS will deliver. Then redouble your efforts to get to go-live status.

7. Collaborate closely with the vendor.

An enterprise, not its IPMS vendor, knows its business best. Therefore, expect to do some heavy lifting educating your vendor and tackling numerous tactical and strategic aspects of the implementation that only you can really manage.

Investing in the relationship with your vendor best positions you for a successful outcome. The right vendor will meet you more than halfway and help you find your way through initially dark corridors.

Never hesitate to pursue ongoing dialogue, to push the vendor to act, and to escalate issues within the vendor’s organization when your messages are not apparently being received and acted upon.

8. Stay abreast of the IPMS market and related solutions.

It’s incumbent upon you to keep a watchful eye on trends in the IPMS space.

Technologies are constantly evolving, ever more powerful functionality is coming to the fore, and customers are becoming savvier in their IP operations. There seems to be a growing recognition that no single proprietary system can meet a customer’s every need; thus, vendors are exhibiting a greater appetite for enabling interoperability with third party systems and data sources.

By remaining informed, you can identify the optimal mix of IPMS and related solutions for maximum positive impact on your enterprise.

Apply Best Practices Collaboratively

Like the family building a home with a homebuilder, companies or law firms implementing IP management software with a vendor face myriad risks along the journey. Unlike that family, such enterprises may have the wherewithal to form larger collaborative teams to apply the best practices discussed above. In so doing, they have a very real chance of achieving less turbulent IPMS implementations that will have a greater impact.