#8 – How to Control Technology Procurement Outcomes | Part 3
Though the procurement and negotiation of contracts is not as “scientific” as other phases of the lifecycle of business technology, it is no less important. Many technology leaders feel like they don’t have control over the outcomes or experience they need. This series is dedicated to covering the 5 steps you need to know to negotiate the lowest possible price for the technology services and contracts you require.
Part 3 – Gathering Data
As one is defining their actual specifications, there will undoubtedly come a point where information needs to be gathered. Most buyers consider the gathering of organizational data (use cases, quantities, integration requirements etc.) to be an entirely separate process from the gathering of information from providers (product functionality, service levels, pricing, etc.). It seems quite natural to divide internal from external. There is, however, a more nuanced way to segment data gathering that reduces confusion, time, and migration risk. Simply put, we must also dissect the information across a different axis: technical data vs pricing data. This is because we are extremely likely to need to get information from the providers while we are defining our spec. After all, if we don’t know what our solution is, attempting to specify it is a paradoxical problem. Now, we still need the Internal/External axis, but by adding this further distinction, we can provide more structure to the discovery and eventual negotiation process. First, we will address gathering technical information, and then we will move into requesting pricing.
Certainly, there is a good amount of understanding that comes from within one’s own organization. We must be certain to gather all that information first. We must ensure we’ve followed the previous steps so far, and that we can clearly quantify the desired outcomes. Ultimately, the art of defining a specification is answering the formula of “(what we are doing today) + (the changes we need to make) = (where we want to be).” In many cases, identifying the results the necessary changes need to produce is extremely easy, while defining how they will achieve the results seems like a Gordian knot. This is a direct result of the aforementioned paradox. So, to solve this, we will identify what we can internally, and gather input from various providers and manufacturers about the capabilities of their solutions (completely independent of pricing). By merging these two data sets, we’ll be able to directly tie a technological component with a change in results, allowing us to have all the information we need to complete our formula of specification.
It is beyond the scope of this article to provide an exhaustive list of all the information you might be able to gather from your own organization for any number of technologies. However, as we proceed to discuss how we gather information from technology service providers, we must remain ready to gather new info when we determine it is necessary. If we don’t know how to define our specification, then we certainly can’t know that we have all of the factors properly considered. As we mingle in the data gathered from providers, we must be open to reevaluating our own data, particularly when we receive information that changes the very way we evaluate.
When turning to a provider for information, the first request should be a Request for Information (RFI). This is the best starting place when your requirements are either not well defined or not well understood. This is typically an informal and non-standard process that leaves much in the hands of the responder to determine the level of response given. However, if properly leveraged, it can open a meaningful dialog with a provider. At the very least, the provider’s response to your RFI will tell you a lot about their culture as a technology service provider. There are two approaches to crafting an RFI. One is to focus on asking about specific product benefits and seeing what naturally fits your needs, while the other is to state your problem and desired outcome, and encourage the provider to recommend a solution that gets you there. The first method allows you to play your cards close to the vest, but puts you at risk for missing an option you didn’t know to ask about. The second method keeps the conversation focused on what you really care about (the results), but also leaves you at the mercy of the awareness and understanding of the provider(s) you request information from. However, you go about structuring your RFI, the key takeaway is that you have to take the information you receive and merge it with your internal data set, and assess the merged results. If you do not have all of the information that you need to clarify the remainder of your specification, then identify whether that data comes from your own organization or from follow-up questions to the providers. Continue merging in all the data you gather until you have what you need to define your specification.
Once your specification is defined, it is time to move from the technical realm to the pricing realm. As with the technical data, pricing data must be gathered from both internal and external sources. Internally, this will always be a matter of budget and your organization’s spending policies. From the service provider perspective, this is where most shopping experiences go off the rails. Some organizations will try to tell the story over and over again to each prospective bidder, allowing inconsistencies in the way things are repeated to drive differences in interpretations that grow wider apart over time. Some organizations will attempt to build a highly structured format for comparing options, failing to achieve a great objective for lack of clarity on how to hold providers to that format. In fact, when shopping on your own, an official Request For Pricing (RFP) process will be your most effective path to getting the next stage of information you need to evaluate, but it will require an investment of time upfront. A lot of time and effort can be saved here when you work with a resource that can represent you through an RFP process.
The success of an RFP depends largely upon how clearly you write out what you want to achieve. It’s easy enough for a provider to fill out a pricing table that tells us how much a group of particular products cost, but that doesn’t allow significant opportunity for the provider to understand how you will measure success, and ensure that their proposal is fine-tuned to drive the KPIs you’re focused on. Therefore, the most important aspect of an RFP is that it is written clearly and completely. This often results in lengthy documents, as many feel compelled to include endless details, but really what is needed is thoroughness in defining the business needs and objectives that are being dealt with by this RFP. Defining the implementation and lifecycle milestones, along with measurable production results will allow engineers to recommend alternative configurations where they see significant value.
The second most important factor to an RFP is ensuring that you define the format by which all respondents must submit their answers. Being lax here only leads to confusion later when you don’t have comparable responses. Consider providing a table of expected bodies of work, and require the respondents to identify which party will be responsible for each body. On this point, in particular, ensure that no provider assigned “joint” responsibility or ownership of any part of their proposal. Only one side can be truly responsible. The definition of roles must be clear and accurate, as well, so that all of the necessary responsibilities are adequately assigned. This includes identifying when the vendor will pay for components and when you will. On the topic of cost, declare your pricing structure, and require all respondents to adhere to it. Ensure you’ve provided breakouts for all of the components of your cost- not just rates, but fees, discounts, procurement costs, implementation costs, and support costs. Since we’re talking about what your costs will be, it’s also important to ensure you define how the commission dollars from your purchase will be spent, should you sign with a given provider. An important part of your clearly defined RFP will be the Year One commitment position we developed earlier. This will be key to establishing limits in proposals, and allowing the provider to have a realistic view of what you are actually bringing to the table. Make sure your Year One commitment position includes your requirements for and risks associated with quantities and deployment schedules, system integration, and training and adoption.
The third most important factor to a successful RFP is to build your vendor scoring matrix prior to distributing your RFP and accepting any responses. This means identifying the metrics by which you will judge not only each bid, but the vendors themselves. This includes marking down your assessment of their “Y factors”: capability, transparency, accessibility, flexibility, creativity, reliability, and so on. Being able to record and compare the “Y”s will help you answer the “Why”s.
If you are attentive to these three aspects, you will be able to develop an RFP that results in consistent and normalized responses from vendors that are easy for you to digest and compare. If you’ve made it this far, then you’ve accomplished the hardest part of this whole process. From here, we are in a position of extreme clarity and visibility, having studied and documented our objectives and requirements, and now having gathered the necessary technical and pricing information to solidify our path. The next step will be reviewing the responses to determine who we will begin negotiations with.
