You are looking for the most flexible and affordable deal for your organization, while the vendor representative is looking to maximize your investment in the vendor’s service offerings. While renegotiating existing agreements is familiar territory, there is some discovery to be done when it comes to a new software product, and even more where the vendor is new. There are many articles on the Web dealing with vendor negotiation, but on review, they are very generic.
Most of our existing and new customers come to us because they are in industries that rely heavily on specialized engineering and scientific software, for which we provide both software license management & optimization solutions and advice. We are not going to advise you to select several vendors and make them compete against each other; although, if there is an opportunity to do this, do capitalize on the opportunity. Aside from the fact that many of the specialized software tools out there have no competitors to speak of, there are also critical considerations to take into account, such as whether there is a ready supply of skills in your marketplace who know the proposed software, what the learning curve is, and how much institutional knowledge there is of the product. If you have years of work invested in Bentley or Autodesk, for instance, what is the real cost of migrating to a competitor product?
How to Negotiate a Better Contract with Vendors
So, where to get started? We suggest the following process, which can be adapted to fit the complexity of both the product and your business model and business case.
- Form a team
- Understand why the product is needed
- Understand the product architecture
- Analyze the pricing model
- Prepare the environment
- Negotiate from a position of strength
This could be overkill for a case where only a handful of employees will be using the software, but sometimes in such cases, a single license could have a six-figure price tag, so it pays to do your homework.
Form a Team
While it is obvious that you will expect your IT asset management (ITAM) and software asset management (SAM) resources to handle the bulk of the effort, you definitely need at least one superuser to provide subject matter expertise on how the product is expected to perform and what the critical success factors are. This should be communicated to a business analyst, who can draw up the software requirements, which can be translated into an RFI or RFP based on the business need. If you envisage running the new product in a cloud IaaS or PaaS environment, input from FinOps on the implications of BYOL (“bring your own License”) is needed, as well as possible ramifications of running in a container, and the choice of an on-site or SaaS approach (or a combination of both).
Understand why the Product is Needed
Traditionally, procurement of software is executed via the IT Division, who often are not users of the products they acquire for the business unless they are traditional office software. This is even more the case with specialized software, where there is a reluctance to spend on software that is mission-critical for the engineer or scientist. Anyone involved in the product lifecycle needs to understand the business benefit of acquiring it and the business risk of it not being available. There must also be a clear understanding of whether this is a one-off acquisition for a specific project, or a long-term addition to the organizational software portfolio. The different user categories should also be identified, from casual users to those who will work with the product for hours per day, as well as what functions are critical and which are “nice-to-have”. Also, if there are competitor products, in spite of what we said earlier, they need to be included in the purchasing decision, which may include a full proof-of-concept evaluation if the complexity and cost of the acquisition merit it. For instance, in an automotive case, does one select PTC Creo, Dassault’s Catia, or Siemens NX? It is also important to keep the CFO informed and educated as to the preferred choice, so that he is comfortable with the expenditure.
Understand the Product Architecture
How the product was designed determines the vendor’s pricing model, especially where there are multiple applications and features involved. This is very much where IT takes over, identifying both the product architecture and how it fits into the overall IT environment. If the company has adopted IaaS and/or PaaS and is running most of the environment on one of the hyperscalers (AWS, Google or Microsoft Azure), will the new software work optimally? This is a question only the FinOps team can answer, as each of these public clouds has its own architecture and rules.
Analyze the Pricing Model
By this stage, there is enough product and vendor knowledge on hand to evaluate the pricing model, based on the required functions and features, as well as the expected number and categories of users. The total cost of ownership (TCO) must also be unbundled, ensuring that maintenance, implementation and training costs are itemized separately. It is important that the vendor is candid and transparent about how these costs are arrived at upfront, so that the ITAM/SAM team can implement mitigations and early warning systems to avoid these “true-up” costs. You can also expect that prices will rise, and the vendor must put their cards on the table for this, ideally for the next 5 years.
The ideal configuration for the agreement could involve a mix of licenses, such as named user licenses for the superusers, concurrent licenses for the average user, and possibly a few subscription licenses to ensure that peak usage can be managed.
Another point to consider is how simple or difficult it will be to migrate to another vendor’s product in the future, or whether you are locked in. If it is a unique offering now, it does not mean that there will not be contenders in the future.
Prepare the environment
This is background work that can be done before and while the contract is being negotiated. You need to prepare your ITAM and SAM environments to bring in the new product and be able to manage and measure it, as well as define and allocate the correct user entitlements. Any changes to policy and procedures must be made as well as a communication outreach that keeps everyone informed as to the status and availability of the new software, and any business rules, such as license harvesting and chargebacks that will be applied.
Unlikely as it may be, if you do not have a software license management (SLM) solution that will be able to monitor and manage the new licenses, please acquire one. If you do not have your own ITAM/SAM/SLM software, you are reliant and dependent on the vendor’s assessment of license usage and cannot defend your position in the case of a true-up or similar dispute. It is also possible that you do have ITAM/SAM/SLM software, but it is not geared towards scientific and engineering software, which is probably why you are reading this article. We are not claiming to be the one and only solution out in the market, but we do have 20 years of experience and a large cohort of cross-industry business leaders as customers. We also are happy to offer advisory and consulting services, when it comes to vendor negotiations. Sign up for a one-on-one discussion with a subject matter expert.
Negotiate from a position of Strength
At this stage, there is enough evidence to negotiate with the vendor and obtain the optimal configuration and contractual agreement tailored to the organization’s current and future business needs. We wish you every success with this new acquisition!