At a glance

An Intellectual Property Management System transformation can provide the step change in IP operations efficiency and strategic capability that your organization needs. Many organizations, however, fail to plan appropriately for this task, and risk going over budget, over time, or ending up with a solution that is a poor fit for the organization. This white paper outlines 6 pitfalls identified by Konsert when helping clients update their Intellectual Portfolio Management Systems:

  1. Going in with an unclear IP operating model: Before you move into an IPMS implementation, you need a clear picture of your IP operating model and how your IPMS will support it.
  2. Not upgrading your external agent and service provider model: Use the opportunity when implementing your IPMS to also review and streamline the way you work with external agents and service providers.
  3. Not making the business case for your IPMS: Make sure to clarify what the business rationale for implementation is, and what the expected business outcomes will be.
  4. Not involving the relevant stakeholders: Consider all relevant stakeholders in the full process, and don’t build your IPMS only for the IP department.
  5. Being unsystematic regarding what is important to you: No IPMS implementation will stick to the plan 100% - know how, when, and where to compromise.
  6. Assuming that the vendor knows best: Remember that the vendor’s best practice will be a best practice for their system, but not necessarily for your organization’s needs.

A first step in implementing or upgrading an IPMS is to be aware of and plan for these 6 pitfalls, and how to avoid them. By envisioning how they might apply in your organization, you can prepare your own IPMS implementation with a full understanding of what it will take and a risk-avoidance strategy.

Show moreHide


There are several reasons to implement or upgrade an intellectual property system (IPMS), which can be a step change for IP departments, R&D, and executive management. This is often driven by changing IP landscapes that require more active IP management, or organizations that evolve and outgrow their old IP processes. Traditional docketing systems are replaced by collaborative platforms that integrate IP business interests, IP intelligence, and a global IP portfolio. Advances in modern IT and productivity tools alone mean that upgrading aging systems is an attractive proposition, allowing for far better integration with the productivity tools of your organization. Still, many organizations are saddled with outdated systems that limit their IP management effectiveness.

The primary obstacles to upgrading your IPMS are cost, time, and the strain that implementing a new system can place on your organization. As with any enterprise system, a transition to a new IPMS can be a massive undertaking, taking years and potentially costing hundreds of thousands of Euros. Proper implementation requires in-depth alignment with your processes, adjustment of both the system and your ways of working, and a large dose of education and integration. Making the wrong choices or failing to appreciate and plan for the task appropriately can be a costly mistake that impacts your organization for years to come, either through a drawn-out and painful implementation process, or through being saddled with an inefficient, misaligned system for years to come.

This white paper has been prepared by Konsert to help you recognize some of the main pitfalls we have identified in this process. We have helped customers through the entire process – from identifying needs and organizational limitations, to designing and carrying out the procurement process, to setting up and staffing the IPMS implementation project, all the way to migration, configuration and integration of the IPMS on a global level. In this process we have gathered deep learnings on typical challenges and pitfalls, and have put together this white paper to help your organization successfully identify and avoid them.

Pitfall 1: An insufficiently clear IP Operating Model

Make sure your IP operating model is clear and strategically consistent before implementing an IPMS to support it

An IPMS can only be as effective as the IP operating model it is intended to support. Upgrading or implementing your IPMS when your operating model is unclear can lead to an inefficient and drawn-out implementation, and at worst, an IPMS that is in direct conflict with the goals you set for your IP operations. If you ensure that your strategy, processes and way of working with IP are clearly outlined and documented before beginning the selection of an IPMS, you will have a much clearer guide for the whole IPMS journey, and are likely to create value for your organization beyond successfully implementing an IPMS.

Many organizations have built their IP operating model ad hoc as their companies have grown and moved into new product areas or geographies. The end result is a model that many times is hampered by legacy and creates unclear roles and responsibilities:

  • Not harmonized across the organization, with different, sometimes incompatible processes springing up in different departments or with different external agents and IP service providers;
  • Not codified in a clear and understandable fashion, with a high risk that the persons who built and know the way of working best have left the firm, with no record of the process or logic behind it;
  • Not implemented in practice, meaning that many times management has a certain set of beliefs about the IP operating model that are in fact not reflected in how daily operations are carried out.

The result of this lack of clarity is an IP operating model that has no alignment with business needs, is difficult to change or update, and is generally no longer the most efficient way to work with IP. Sometimes the decision to implement an IPMS is a direct response to this, brought on by a hope that a new system will drive the development of a clearer, more structured operating model. This is almost never the case, and beginning an IPMS implementation project without first clarifying the operating model will fail to improve the operating model and lead to one of two likely outcomes:

  • Implementation is significantly delayed or fails, as you lack clear direction or answers to major questions about why, what and how to implement;
  • Implementation is significantly flawed, as the vendor pushes you to implement a system with “out-of-the-box” workflows which rarely fit any organization.

Your IPMS implementation should always take its starting point in an up to date review of the current IP organization, whether this is something that you do periodically or if it’s the first time you review your processes, goals, operations and strategy. This review will always add value, regardless of implementation outcomes, and many of the improvement points you identify might be possible to address outside of the implementation project. Going into the implementation project with a clear view of your current roles and processes, your key performance indicators and your IP objectives, and the way that IP aligns with business strategic priorities (or should align) will be the foundation for your IPMS project. This foundation should remain stable throughout the project. If your organization does not already carry out structured, comprehensive reviews of the IP operating model, it is highly recommended to begin codifying and documenting this process.


Exhibit 1

A clear operating model sets the direction for the IPMS journey

Source: Konsert Strategy & IP

Pitfall 2: Failing to address all stakeholders

An IPMS is not only a platform for the IP department, and the other stakeholders should be involved early on

A key ambition for almost every IPMS upgrade is to more efficiently integrate IP operations with the rest of the company – R&D, sales, marketing, legal, and top management. Expecting these departments to actively work with the IPMS, however, requires you to consider them as stakeholders in the IPMS implementation process, and to ensure that their expectations and requirements are part of the process. If you see the IP department as the only stakeholder, you will get an IPMS that only the IP department uses.

Ideally, your IPMS will bring a common language to IP operations – remember, to many people the language of IP is an impenetrable wall of jargon. If you want them to see and understand your portfolio, you need to find the level of communication that can reach colleagues and management who work less than 5% of their time with IP, and you need an intuitive and sensible platform to let them gather information and contribute to IP work. We have identified some of the typical stakeholders in your IPMS and their main drivers.

  • R&D Department: Typically looks for:
    • Ease of submitting and tracking their invention disclosures through the system, as well as making and following up requests to the IP department (e.g. freedom to operate search requests, design application requests, infringement notifications etc.);
    • Ease in collaborating with the IP department throughout the IP lifecycle (patentability assessment, drafting, responding to office actions etc.); and
    • Overview and insight into the existing portfolio of IP rights – making clear what they have, what their co-workers are developing, and what the organization as a whole is focusing on.
  • Top management: Typically looks for:
    • Ease of making or signing off on IP decisions, e.g. filing decisions, nationalizations, portfolio reviews etc.
    • Overview and insight into the existing portfolio of IP rights – making clear what they have, what their co-workers are developing, and what the organization as a whole is building, and
    • Easy to access and digest information about the state of the IP portfolio through dashboards and KPIs, including operating efficiency and effectiveness.
  • Legal department: Typically looks for:
    • Security – being able to store strictly confidential information, and guarantee both internal and external security;
    • Document management – efficient ways of handling the document trail of your IP, including agreement repositories and electronic signatures.
  • External agents: Typically look for:
    • Collaboration functionalities that allow them to directly work and communicate with you in a way that doesn’t disrupt their way of working and doesn’t open up for conflicting input, e.g. document management and collaborative case management.

By clarifying your IP operating model (see Pitfall 1) you will be able to identify the stakeholders of most importance to your operations, and how to prioritize their perspectives. One part of a clear IP operating model is an overview of the relevant functions, mandates and roles that will be integrated with your IPMS, and may need to be represented – this should be your starting point and your checklist for making sure that the right stakeholders are integrated in the process.

Exhibit 2

Include all stakeholder perspectives for an efficient integration of IP operations with the rest of the company

Source: Konsert Strategy & IP

If the various relevant stakeholders don’t participate in your implementation project, you are unlikely to be able to unlock the full potential of your new IPMS. You might end up with a system that meets the current requirements of the IP department but not of any other stakeholders, leaving the IP department as the only persons able to use the system effectively. The end result is that IP understanding is not disseminated in your organization, the IP department becomes isolated, and IP remains an under-used and sub-optimal asset in your organization. This is the case with most traditional docketing systems – the company IP portfolio is a black box which is seen as the sole responsibility of the IP department.

Limiting your stakeholder participation is also likely to lead to inefficiencies. Instead of being able to integrate the IPMS in their own way of working, other departments will turn to the IP department for all their IP questions, creating a bottle-neck that’s difficult to bypass. It also means that there’s a significant amount of duplicated effort, as the IP department has to work to translate requests from other departments into tasks and information requests in the IPMS. Ideally, each relevant stakeholder should know what they can get out of the IPMS, how to interface with the IPMS, and how it integrates with their own way of working.

Pitfall 3: Missing the opportunity to upgrade your external agent and service provider model

Review, revise and update your external agent and service provider model together with your IPMS implementation.

Even if you have reviewed and begun to detail your internal way of working, many organizations fail to recognize the opportunity they have to also review and update the way that they work with external agents. External agents are often tasked with the bulk of a company’s specific IP actions such as drafting and prosecution, but their ways of working are defined by historical circumstance or outdated ad hoc decisions. When you implement an IPMS you are likely to want your external service providers to be able to use it as a platform to collaborate directly with you in the system, but even if you do not, there are several reasons to revise your service model.

  1. “The way you work with external IP agents is one-sided or reactive.” Most companies have developed their service provider relationships over time, based on history, personal relationship, or geographic differences. The larger process of implementing an IPMS gives you an umbrella under which to also take the full view of your service provider model and align it with your way of working.
  2. “Your external agent and service provider relationship has not been continuously renegotiated for best price.” Upgrading the way of working with your IPMS is likely to change the tasks you wish to outsource to external service providers, and can lead to more or less responsibility being outsourced. You should take the opportunity at this stage to consider which tasks are costing your organization the most, and consider which tasks should be negotiated at a fixed fee, or procured from other service vendors. Many times you can also improve your external agent overview and follow up on the use of external resources by building cost tracking features directly into the IPMS.
  3. “Your current service provider overlaps the services offered by your IPMS vendor.” Many IPMS vendors also offer customers the option to outsource administrative IP activity to the vendor, directly integrated in the IPMS service – primarily annuities payment and administration thereof. This can be an attractive option, but it requires you to have the full overview of your current working relationship with service providers, to understand if this is an option for you.

In most cases, reviewing and updating your model does not necessarily mean changing the external agents you work with, but it does mean re-thinking the way you work with them. Ideally you will be able to design a more collaborative, flexible, and more integrated way of working and be able to leverage your existing external agent relationship more effectively. It is also a relevant opportunity to renegotiate your existing service agreements.

Exhibit 3

Before embarking on an IPMS change journey, companies should take the opportunity to assess current way of working with external service providers

Source: Konsert Strategy & IP

Pitfall 4: Failing to make the business case

If you are not able to show the business case for implementation, your upgrade process won’t get off the ground

No matter what the IP processes of your organization look like, your IPMS implementation needs a clear business case that is well aligned with the culture of your organization. Even if IP is not yet a profit center in your organization, the expense of implementing an IPMS has to be carefully motivated and justified on a business logic. Failing to make the business case might mean that you never get approval to even start the IPMS selection process, but it also might mean that even if you do get started, you lack access to the necessary resources, personnel, and management support to complete the implementation fully. If you don’t make and anchor the case that your IPMS implementation will create value, the only driver for your implementation will to be to keep costs low, and to cut corners when needed. The result can be an anemic, sub-optimized implementation.

To give you an understanding of the scope of the business case you need to make, the following are examples of some of the costs you may need to justify, and have a clear resource plan for:

  • Basic vendor implementation: a one-time investment of 100 000-500 000 EUR to pay for the configuration and data migration to the new IPMS
  • Internal IP resources: senior internal attorneys and counsels who are experts on the process and whose input will be needed. This is often an underestimated cost of an implementation, if this time is not tracked and charged per hour.
  • Internal IT resources: even though most modern systems are cloud based, internal IT resources are needed, e.g. to integrate the IPMS with other in-house systems such as AD, HR and Finance systems.
  • Vendor license cost: most modern systems are intended to operate as a service agreement, thus cost more to license than older “docketing systems”.

Many times the budget for your IPMS implementation will not be covered solely by the IP department, which makes it even more necessary to clarify and justify the business case for your implementation.

When making the business case, it can be difficult to know which parameters to consider that will let you reach an objective price figure. The following are some parameters to consider that can help you clarify your case. 

Exhibit 4

Checklist for making the IPMS upgrade business case

Source: Konsert Strategy & IP

Pitfall 5: Being unsystematic regarding what is important to you

No IPMS implementation will stick to the plan 100% - know how, when, and where to compromise

By addressing the pitfalls we describe, you should be able to establish a reliable foundation for your IPMS transformation. Part of this planning will be to identify and understand when and how you should be able to compromise. In your review and alignment process you are bound to come across unexpected developments or strong arguments against your proposed transformation.

You may discover that there are needs or boundary conditions you hadn’t considered, that your resources are under-dimensioned for the task, or that the vendor solution you have selected does not actually provide the features you initially thought. It is possible, however, to be prepared for these unforeseen events, if you know ahead of time when and where you are able to compromise, and have identified they key issues where compromise isn’t possible.

Exhibit 5

Structured requirements listing and evaluation makes compromise decisions easier

Source: Konsert Strategy & IP

The starting point for identifying your points of compromise should be your intended way of working, and what it will take to get there from your existing processes and governance models. Identify the processes that you believe will be necessary for your intended way of working and determine what it will take to implement this in your IPMS. For example, one goal of your implementation might be to allow business area heads to participate in the filing decision process, to ensure alignment with portfolio development. If your IPMS can’t integrate multi-stakeholder decisions out of the box, you should already know that this is something you cannot compromise on, and that you will need to the system provider to either develop this feature, or you need a different system.

CASE EXAMPLE: “No compromise approach”

At one extreme, lacking a plan for compromise can lead to a drawn-out, expensive development process and each desired feature becomes a must-have implementation, as one company discovered:

  • Went into the implementation project unready to compromise at all on their specifications: “the system should be built completely around our processes;”
  • Spent 4 years (normal is 1-1,5 years) in implementation project with vendor, making several customizations to the system;
  • The final system was overloaded with customizations and tailor-made solutions, requiring four to five full time equivalent position to keep up to date and functional;
  • In hindsight, they confess that they should have been more willing to compromise along the way


An important step, after reviewing and codifying your IP operating model, is to assess the functionality you want or expect in your IPMS, to determine both how important they are to you, and how difficult it will be to implement them. The difficulty can range from minor configurations of an existing set of templates to hard-coded customization or development, or changes to your IP operating model. If you find, early on, that functionalities you consider cosmetic or ‘nice-to-have’ are much more difficult to obtain than initially thought, you will be able to adjust your implementation road map accordingly, and confidently compromise rather than agonize over lost opportunity.

When you make your assessment of potential points of compromise, it is important to apply some of the other steps recommended in this paper. Don’t, for example, solely consider the needs of the IP department when ranking the importance of different features but try to reflect their importance to the different stakeholder groups you want to connect in the IPMS.

CASE EXAMPLE: "Having to cancel/restart after years of work"

At another extreme, not identifying your requirements can lead to discovering that your chosen system is unable to deliver functionality that is actually necessary, as a different company learned:

  • Went through the procurement phase without systematically having verified all requirements required for their IP operating model;
  • Well into the implementation phase (2 years after initiating the IPMS project) realizing that the selected vendor would not be able to meet all the requirements;
  • In the end they had to cancel the project and look for a new vendor, resulting in the loss of years of progress, hundreds of thousands of Euros, and motivation and morale of the staff.

Pitfall 6: Relying on vendor best practice

Vendors can be expected to be experts in their systems, but not your way of working; don’t expect them to provide all the answers

A close collaboration with your vendor is a key success factor for implementing your IPMS, and the level of service and expertise they can provide before, during and after your implementation should be a deciding factor in your procurement process. A common pitfall, however, is to assume that their best practice will also be your best practice.

It is easy, especially if you haven’t had sufficient time to detail your own way of working, to allow the demonstrated best practice of the vendor to dominate your planning and implementation process. Vendors are usually more than happy to provide detailed test cases and demo processes, as this streamlines their implementation process (often sold at a fixed fee) and makes it easier to sell additional features. Further, only going by the vendors’ best practice demonstration makes it difficult or even impossible to compare offers when procuring the right vendor for your organization.

If you properly detail your way of working, it will be far easier to negotiate and procure vendor services, and less likely that you end up with a solution that is a poor fit for your organization. If not, you are likely to end up with a system with out-of-the-box workflows, that are not necessarily right or useful for the way you want to work. The goal of your implementation project is not to throw out your existing processes and replace them with vendor-recommendations, but to find ways to leverage the way of working you have while removing bottlenecks or inefficiencies.

Finally, most vendors are not at a point where they are able to recommend a truly business-aligned way of working – at least not without your detailed input. If you want to have a system that enables business-driven IP management, you will need to adapt the system – using vendor recommendations may offer a quick implementation, but won’t let you build a competitive advantage. Additionally, the quick implementation is usually followed by far more work handling change management when you approach go-live, and a much higher risk of dissatisfaction with the new system.

CASE EXAMPLE: “No own vision”

When an IPMS project is modeled entirely on vendor recommendations, the end result can be an efficient, painless implementation that is nevertheless a poor fit for the actual organization it is intended to serve, as one company discovered:

  • The company into the implementation project without a strong vision about their own IP operating model;
  • The implementation project followed its time plan and the client went live at the planned date – a seemingly successful implementation;
  • At and after go-live, there was a very high level of dissatisfaction with the new system – people perceived that the system did not support their way of working and forced them to jump through unnecessary hoops;
  • 2 years after go-live, the client decided to scrap their newly implemented system and procure a new one (this time hopefully with a stronger vision of their IP operating model)


Implementing or upgrading an IPMS should be seen as any Enterprise Resource Planning system implementation and should be taken just as seriously. Failing to approach the implementation as a significant, company-wide upgrade project can mean that your implementation takes months or years longer than expected, outpaces your budget, or worst of all, results in an inadequate or failed implementation, with poor user adoption and misalignment with your way of working. Most companies typically cannot afford to replace their IPMS more than once every 5 years, so a failed implementation can be a serious impediment to the IP operations efficiency.

Identifying the potential pitfalls while planning your IPMS project will help you set a roadmap that is realistic and reliable, and will make sure you have contingency plans in the event that the pitfalls become a reality in your project. All of the pitfalls in this paper are taken from real-world observations and case studies, but you need to adapt them to your organization to understand how each pitfall would be expressed in your context. This will also help you communicate and set expectations internally and in vendor discussions, and plan different scenarios based on expected reactions.