Getting a Software Asset Management (SAM) RFP right the first time
In this post, we discuss how to best structure and run your SAM/ITAM RFP to reduce time, costs, and ensure you select the right services partner for your needs.
RFPs and RFIs – What’s the difference?
An RFP or Request for Proposal is a procurement-led process where a business defines a set of products and/or service requirements and distributes them to a selection of potential vendors. These vendors may respond detailing their abilities, outlining their offering, and providing their proposed fees. This should not be confused with an RFI or Request for Information which should precede the RFP and is a formal process for gathering information from potential vendors. RFIs are written by the business and sent to these potential vendors. An RFI is typically the first and most broad series of requests intended to narrow down a list of potential vendor candidates. Actioning an RFI first will provide an outline for the RFP process and shorten the Question & Answer’s (Q&A’s) by providing ample background information about requirements. It will also provide a deeper understanding of prospective vendors and their capabilities, and often highlight additional considerations for the forthcoming RFP.
It sounds straightforward enough but get this wrong and you could suffer a costly mistake that may negatively impact your business for years.
Seeking expert help
Using an external service provider to support the RFP and RFI process will allow you to draw from their experience in outlining what should be included in the RFI/RFP. They will have knowledge of the vendors that should be included in the process and experience working with them. Service providers in the IT Asset Management industry work on and respond to many RFI/RFPs for software asset management or ITAM tools and services and will have best practice recommendations. Their advice may well uncover vendors that would not have otherwise been included, for example, Gartner’s® Magic Quadrants™ or other industry analysis reports. Seeking support like this will shorten the whole RFP process and ultimately, save you time and money.
Building a business case
As a prerequisite to the RFP process, we strongly recommend you first build a Business Case and establish an approved budget range based on realistic expectations. Leaving this to the end will slow the delivery of a solution and may cost your business (and vendors involved) critical time, negatively impact your relationships, and result in a solution that ultimately doesn’t solve your in-scope business problems.
Writing your RFP for Software Asset Management
We recommend the following areas be considered and included in your RFP process so that, when executed effectively, you can make a faster, more streamlined decision and ultimately, achieve the best outcome.
Stakeholder involvement
The most crucial step will be making sure all the right internal stakeholders are involved in preparing the RFP and participating in the selection process. Requirements from all applicable business areas impacted by the SAM/ITAM tool or service must have their needs and requirements brought to the table and met from the start; otherwise, they may not accept and/or adopt the new solution (yes, we still see situations where key stakeholders are blindsided by a new solution or service). Their needs and requirements should be documented and evaluated along with prioritizing the ‘must haves’, ‘nice to haves’ and potential future requirements. Failing to do so will likely result in push-back during the final decision-making stage. If a particular department’s needs are not met, it is likely they will not buy into the change, contribute to funding, or adopt the solution, making completion of the RFP long and drawn out with unhappy stakeholders. Starting a strategic initiative with this disjointed alignment and friction may leave your project ‘dead in the water’ before it even begins.
Defining requirements
Clarity and transparency with vendors participating in your RFP are key, and putting in the work to succinctly define your RFP requirements will pay long-term dividends in the timeliness and success of your project. The lack of critical information at this stage of an RFP may result in a lengthy Q&A and/or Discovery phase and possibly add weeks, or even months to your RFP response review and evaluation efforts. This lack of defined requirements will also likely result in wildly different proposals from the respondents, each with their own interpretation and view on what you might ‘actually’ need, which may completely miss the mark and make it nearly impossible to compare responses in a like-for-like manner and select the ‘right’ proposal. The inability to compare like-for-like will, again, require more time and effort from you and your stakeholders to make sense of the responses and try to match the vastly different responses to your loosely defined requirements. We unfortunately see this occur far too often, which usually results in canceled or delayed RFPs as organizations feel obligated to redefine and restart the lengthy RFP process. More importantly, this means organizations continue to miss out on the needed solution benefits and remember, “Time is money.”
Don’t be afraid that overproviding details on your requirements will result in a higher price, after all, you get what you pay for, and a lower price often means a reduced scope or insufficient solution. This will likely mean that needs will not be met, or the solution won’t meet defined Service Level Agreements (SLAs). Do your best to anticipate and preempt vendor questions in the Q&A phase and provide this information in your RFP materials issued to vendors. As previously shared, organizations who fail to properly define their requirements at the start often cancel or restart the RFP again because a poorly defined RFP results in proposals missing the mark – get it right the first time!
We recommend you start by defining the required outcome you are looking to achieve. This should include how the outcome will be measured and what success looks like to your organization. Success may look different to different organizations, so as noted earlier, be sure to include your stakeholders as you define success. We also recommend you clearly define KPIs so the vendors participating in the RFP have a clear understanding of your expectations and definition of success. It is advantageous for you to define success and not leave it up to the vendors responding to the RFP. This keeps the RFP focus on identifying the right vendor that best helps you achieve your defined outcomes vs wasting cycles to define your needs and solution scope in the middle of the RFP process.
Perform due diligence on which vendors to invite to participate in the RFP. This will ensure that you include all potential vendors that are the right fit for your business. Explore their experience and available case studies from their websites or existing relationships and contacts. An external service provider’s support may be particularly valuable at this stage, so you don’t overlook the right partner or solution.
Be clear in the RFP about who (internally) is involved in the RFP process from your business, including individual’s roles and responsibilities. Outline their involvement and how they will be evaluating the proposals and ultimately working with the solution, service provider or product. For example, this is especially important if you have a global team of stakeholders looking for a SAM/ITAM service, but the provider is only capable of servicing a single geographical region, or if the SAM/ITAM service provider lacks local resourcing for activities requiring on-site support. If there are ‘deal breakers,’ then you should clearly communicate them in the RFP materials with reasoning to support and justify the requirements. This saves you time and ensures only the right partners continue in the RFP process while allowing the wrong partners to exit early.
In the same vein, consider compliance, legislation & policies. Your organization may have strict security regulations (e.g., government or defense contractor), data protection laws, or require vendors to achieve specific certifications or obtain clearances to work with you. By drawing attention to these requirements early in the process, it will further prevent wasted time (for you and the respondents) and give providers as much time as possible to put these requirements in place prior to a project start date.
It is important to include all dependencies in the RFP documentation. Provide detailed information about your IT environment size and other service providers that are involved in your operations, as there may be conflicts of interest impacting a provider’s ability to respond or work with your organization. Include a detailed tech stack regarding the ITAM tools in use, explain how this is a dependency to the provider, and to what extent the provider will have access or be expected to utilize existing tools vs bringing new tools into your environment. You should also clearly identify all incumbent systems with which the solution must be integrated. Doing so may avoid costly tool expenses and/or scope/fee creep during the project if these areas are not clearly defined up front and included in proposals.
Technical requirements and specifications must also be provided with as much information as possible. This is vital to protect your business from a service failure and/or the provider being unable to deliver on their committed services, and/or for unbudgeted fees to be added to the service scope after the fact. This also establishes a clear measuring stick with which your service provider will be held accountable if your contracted service and/or product needs are not met.
Define the RFP timeline and process that you will follow to manage participant expectations and ensure timely provider selection. Set reasonable, yet achievable response times to ensure that providers will have time needed to ask questions and still provide a ‘fit for purpose’ proposal in a timely manner. This will avoid extensive back-and-forth delays across numerous providers and high volumes of unnecessary correspondence, all while drawing resources away from your important BAU tasks. Make every effort to stick to the defined timeline and process so that your stakeholder’s time is reserved and optimized as they evaluate the participant’s proposals.
Our experts have created an example RFP template for SAM/ITAM services as a base on which you can start to build out your own SAM/ITAM RFP. This example highlights details that you may not have considered or planned to include in your RFP. You can download the RFP Template here.
Making Your Selection
Before starting the solution selection effort, it is important to develop an ‘Administration, Analysis and Adjudication’ process to ensure you are choosing the right solution for the right reasons. Agree on what criteria your selection will be based upon and how you will capture and record the response ‘scores.’ Make sure the final decision is aligned to your established criteria and that stakeholders are not swayed by preconceived ideas or favorites from their past. A decision not based on your criteria means you have allowed emotion or subjectivity to decide rather than the facts. Remember, your organization may be forced to make do with the wrong provider and pay the price of a poor RFP process if your Administration, Analysis, and Adjudication process is not followed.
Once all the RFP participant’s responses have been received, following this process will speed up the decision process and provide a clear ‘short list’ of providers for final evaluation.
With regards to SAM/ITAM technology, it is common practice for businesses to request a POC (Proof of Concept) but this can be a costly and time-consuming step that may not be necessary. Instead of a POC on battle-tested systems, we recommend you require the involvement of the vendor’s technical or product team, who are far better equipped to answer the important technical questions and typically avoid the high-level jargon that is difficult to decipher. This is an opportunity for you to move beyond the ‘marketing speak’ and dig into the reality-based details of the ‘how?’ There are always tradeoffs, and this approach will help you determine what vendors can and can’t do. Be sure that any of the requirements they can’t deliver are not ‘deal breakers’ and if there are any future requirements they will not be able to satisfy. You can use this time to ask what extras they can offer that might satisfy future requirements. This is another stage at which leveraging support from an external provider will pay dividends as they will are familiar with the SAM/ITAM technologies, use them daily, and understand strengths/weaknesses of the leading technologies in the market. They can help you think through future challenges and understand the tradeoffs of the proposed solutions.
Once you are ready to make your RFP selection, ask the vendors to provide references from clients that represent a similar market, size, objectives, and IT complexity. Take time to learn from other’s experiences with the vendors and ensure they can deliver on their promises.
Your final deciding factor, and one that should not be overlooked, is – Do you like them? Can you work with them? Make sure they suit your organization’s personality and ethos. You will have close contact throughout the product implementation and/or ongoing service for the length of the contract, so fit really does matter. Anglepoint’s experts recommend starting an open communication with the vendors early on in the process. This will allow you to get to know them and establish a relationship before work starts.
How can Anglepoint help?
Anglepoint’s experts have supported many clients with this process, shortening the timeline by months, speeding up the time to value. This Canadian financial services client is just one example –Read the full case study.
You can also check out this podcast with Anglepoint’s Kris Johnson, Chief Product Officer, and Steve Hastings, VP of Global Business Development as they clear up some misconceptions about the RFP process and provide advice for approaching it in a way that enables you to make the most informed decisions.
When Anglepoint works with a client to help them choose the right solution for their business needs, we facilitate all the groundwork in defining the requirements, outcomes, and establishing all the internal stakeholders involved. Our extensive knowledge of the ITAM industry, its service providers, and their solutions and capabilities mean we can provide independent advice and support to select a solution. Working with our team means that the process is supported by industry experts rather than a procurement team with less industry knowledge. This method is underpinned by our unique approach to understanding our client’s needs and ability to deliver true business value.