Many aspects of business technology can be boiled down to a matter of science. However, most would agree procuring and negotiating contracts does not fall under the term “scientific”. It is often at this phase of the technology lifecycle, they feel they’re at the mercy of salespeople or a process that hinders optimal outcomes. We believe there is, in fact, a way to standardize your evaluation and contract procurement giving you control of your technology purchases. The following segments cover the 5 steps you need to know to negotiate the lowest possible price for the services you need.

Part 4 – Evaluating and Selecting Vendors

With a clearly defined specification, a pricing response format, and your vendor scorecard, you’re ready to begin the actual evaluation process, which means you can now open your RFP for responses. For some organizations, this is an extremely formal event, with legally mandated periods for accepting and developing responses, question and answer periods, and billing structures. For other organizations, this could be as simple as calling a number of carriers yourself, or hiring a professional service to help you evaluate. However you execute the mechanics of the evaluation, the most important part of this process is the scorekeeping. In many situations, different providers will recommend different technologies to solve the same problem. In such cases, it’s unproductive to try to compare the pricing against the technology being provided. The key here will be standardizing your scoring on what you will be experiencing as a customer of this provider.

In terms of how to describe the experience you are seeking, this would be where we list out the KPI results we ratified earlier. You may have noticed throughout this entire article there has been a heavy emphasis on being able to clearly define the outcomes you need to achieve. The reason for that is because measuring outcomes-achieved to dollars-spent is consistently the easiest and most meaningful way of turning two different technologies into an apples-to-apples comparison. By defining your requirements in terms of outcomes, and requiring the providers to answer in a format that directly speaks to those outcomes, we can create a filter by which we can standardize all provider responses, regardless of the underlying technology.

What we haven’t put a strong enough emphasis on yet is the structure of a vendor scorecard. Since this is the recording of your grading of each solution and provider, the scorecard will be the largest influence on your decision throughout this entire process. Therefore, it needs to be something you stand fully behind. As previously mentioned, the scorecard helps you identify the “Ys” so you can answer the “Whys.” To be more specific, what that means is the scorecard is a mechanism to quantify what are usually intangible qualities. Transparency, Flexibility or Scalability, Reliability, etc. You should be building a grading rubric that takes these into account, alongside the standard terms and conditions and pricing components that everyone already grades on.

Typically, to build a scorecard, you’ll select 3-5 traits for each intangible quality that you’re looking for. For example, if Transparency is a quality you want to grade on, then you might choose traits such as “clarity of pricing structure,” “frankness of salesperson,” “all fees revealed on contract,” or you’ll want to see evidence of the TCO, including renewal costs and discount potential. If your focus is Flexibility/Scalability, you’ll want to grade on pricing commitments, deployment commitments, and ability to integrate into both current and future expected network conditions. Reliability focuses on the SLAs (and ensuring they aren’t toothless), repair & replace commitments, security achievements, and the competency of their various SME’s. All scorecards should have a section just for the Terms & Conditions, wherein you’d grade the usage/audit rights, control and licensing rights, renewal rates, and maintenance fees. Lastly, there should be a section comparing the proposed pricing.

To fill out a scorecard, you’ll weigh the traits of each quality amongst each other to define priority, and then you’ll give each provider a score of 1-5. As an example, if the most important quality to you is Transparency, and you break that down to mean “all fees revealed on contract,” but also “frankness of salesperson,” and “clarity of pricing structure,” then you might weight “all fees revealed on contract” as 2x the score value, while the other two traits remain at 1x the score value. This would mean any individual provider has the potential to earn up to 20 points in the Transparency category ( 5×2 for revealing all fees, 5 for frankness, and 5 for clarity of pricing).

Now that you’ve got your scorecard, you’re ready to review the proposals and interview any providers you are interested in. As you’re beginning to review the proposals and interview providers, there is one last point to address. Many people pursuing any sort of pricing exercise often make the mistake of asking everyone and their brother to submit a quote. It is far better to limit the number of suppliers you accept bids from. It might seem like the more pricing options you get, the stronger your position is, but there are two reasons this doesn’t work. First, the more bids you accept, the more time you have to spend interviewing and grading. Second, when a provider sees you shopping every option, they’ll consider you less serious, and not reach as far to win your business. You’ll be in a far better position to use the information we gathered from the RFI segment (see Part 3) to narrow down the providers you want to take into the pricing round. When you advance a provider to the semi-finals, and they see that they only have a couple of competitors to beat, rather than the entire market, they will be more incentivized to make a deal to help them win.

When you’ve completed the interviews of the shortlist of providers you accepted bids from, you’ll have the completed scorecards, which should make it extremely easy for you to determine who you should proceed to contract negotiations with. Simply multiply each score by it’s associated weight, and tally up the total points. The provider with the highest score is the one most capable of providing you the experience that best serves your needs.

If you found this helpful let us know, for more thought leadership look for our next article, or contact us.

Keep Your Team – Reduce Waste – Get Smarter Solutions

AITP is pleased to have Aaron Brown, President of The ComtelGroup, join at the May Chapter meeting on May 12th at 11 am EST for a virtual conversation on “Optimizing Technology and Influence in Your Organization post-COVID19“. 

Over the last 20 years, including ten with The Comtel Group, Aaron’s led transformation in dozens of multimillion-dollar companies serving thousands of organizations nationwide. He has led in the evaluation and implementation of mission-critical technology like Cloud Computing, SD-WAN, Network Security, and more. Aaron and The Comtel Group are biannual participants at the Midsize Enterprise Summit (MES). MES is the largest gathering of midmarket CIO’s in the U.S., where The Comtel Group has won the most coveted award, “Best Solution Provider”, as voted by the attendees, for multiple years in a row. 

Join us as we discuss ways that we can all learn to optimize technology and our influence in a world that has changed in the midst of COVID-19. 

CLICK HERE TO REGISTER

Keep Your Team – Reduce Waste – Get Smarter Solutions

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.

Keep Your Team – Reduce Waste – Get Smarter Solutions

Part 2 – Establishing Your Specification

The first step in controlling your technology procurement outcomes is defining your needs: being able to clearly state what you are trying to accomplish for your organization, and having an agreement on which voice will represent the organization. With that clarity will come an understanding of what behaviors need to change, and by what degrees, to drive the necessary results.  The next step in the process is defining the measurements for the future state of processes and technologies that will drive the correct behavior, more commonly known as “defining the spec.”

The most common mistake made when beginning to define specifications is to start by actually defining the specifications. If specs are the measurements for the end state, then we can’t define specs until we have defined the end state.  To do that, we have to build a complete demand model.  This includes taking stock of your operational requirements, and lifecycle deployment schedules, including growth and downturn projections. The goal is to build a “Year One Commitment” position. This will be key when it eventually becomes time to negotiate on contracts.

The second most common issue when defining specifications is to spend a lot of time carving out a “wish list,” or any other named collection of non-essential items.  These lists only add unnecessary time and complexity to the process. Having unusual or custom requirements is perfectly fine, but define only absolute requirements at this stage.  Doing so allows the upcoming and inevitable vendor comparisons to be standardized at the most essential layers.

The third most frequent pitfall has some overlap with the second. This occurs when you treat each component, be it an end-user, a process, or a technology, as being unique until every variable has been proven to already have been captured elsewhere.  Instead, the focus should be on templatizing as much as possible. Start from a default assumption that all end users are the same, and break out sub-categories for features or permissions only when unavoidable.  A highly templatized stack, be it a workflow or data stack, is not only easier to evaluate and shop for, but it’s also easier to deploy and maintain.

With the foresight of these common mistakes, it clearly behooves us all to take some time and clearly map out how the technology you are shopping for will interface with and change processes, people, and behaviors. Make sure you can clearly visualize how end users will interact with this system and how it will change the way they behave. Understand all of the actions and tasks that an end-user must be able to accomplish through this system. Also look at things from a higher perspective, and figure out how managers will use this technology on a day-to-day basis to improve business and measure the KPIs you’re looking to improve. If you can’t draw a connection from the use of or interaction with this technology directly to an improvement in your KPIs, then it’s time to reassess your objectives.

Beyond just using the technology, end users must also get used to the technology.  It’s important that we clearly understand how we will introduce the new technology into the current environment, specifically the migration process but also including how we will maintain, expand, contract, and eventually replace the technology. Make sure you understand who will interface with this technology, both in operational use and maintenance/repair. How will they attempt to use the technology? How will they respond to its interface? How customizable is it?  Make sure you’re clear on what systems need to integrate with this technology, and whether they are capable of that now, or if they need to be reconfigured/updated to support this change. Take time to consider what amount of customization, training, and ramp-up time this technology or system will require for it to drive the results you need.  Are you equipped to support the additional workload to implement these services?  If not, consider looking for an agent that can redirect your commission dollars into implementation services.

Next, make sure you understand what currently works and does not work with your current technology service, to the best of your ability to define. Are there features that users just never understood or picked up on? Are there features that everyone just absolutely loves?  Can you quantify the things that don’t work? If bandwidth is an issue, can you identify that 300% more would solve the issue? If you need to improve up-time, what is the specific amount of downtime you can tolerate?

Once you have those, you can finally begin to define the specific outcomes that you are going to shop for. Some products, quantities or other details may make themselves apparent as you’re defining the outcomes, but at this stage we should only be defining the outcomes we need. Some examples are:

• Increase bandwidth so that users are not experiencing congestion (quantified increase amount, if possible)
• Introduce circuit-agnostic resiliency (quantified allowable downtime)
• Reduce current cost per license for productivity software

At this time it is imperative that you still focus only on what is absolutely necessary. That being said, you should still also have a clear vision of what will be absolutely necessary for the near future, so make sure you include the correct growth capacities in your requirements. Do you foresee growth or downturn in the next 12-24 months? You may have multiple locations that need this service, but will you really be rolling them all out within the first year? Is this a change you expect will last a while, or are you predicting another significant change in the next 12, 24, or 36 months? By the completion of this step, you should be able to clearly define the specific outcomes you are looking to achieve with a technology review or change, and each outcome clearly tied to driving the KPIs you have identified.

If at this point, you know the products, quantities, sizes, and other specific details of the solution you’re looking for, now is the time to validate they achieve the right outcomes, and then go ahead and document them in your list of requirements. If you’re not sure what technology will bring the solution you’re looking for, that’s okay.  If you’ve got the support of an objective procurement expert, they’ll be able to assist you in defining the finest details of the specifications.  However, if you’re still not sure of what you’re looking for, and you don’t have the advantage of an agent in your corner, then the next step from here will be to gather information on various solutions, define the last of your specifications, and ultimately request pricing.

Keep Your Team – Reduce Waste – Get Smarter Solutions

Whatever your organization calls it, and however you measure it, one of the most important KPI’s in financial stewardship is cost. One category where many organizations spend a lot of money is network connectivity. We all need to be able to connect, but the added layers of technical complexity and slow responses leave many feeling like their service providers might be taking advantage of them. So let’s look at (among other benefits) how we can leverage network technology to reduce waste and ensure stewardship.

The Situation
Business has changed. Of course, “the way business is done” is something that is constantly evolving, and those changes are known to frequently follow shifts in technology. Certainly, the recent shifts in networking technology have greatly influenced business behavior. So much so, in fact, that the resulting changes in business behavior have demanded even further advances in technology.

One of the two most noticeable changes is that, for many businesses, data is no longer either on-premise or centralized. Instead of sending all branches back to HQ or to a datacenter repository, employees may be connecting to one cloud service for their e-mail, a second one for their CRM, a third one for webinars and video conferencing, and a fourth one for data storage, all while needing access to various web resources. Specifically because all of that traffic is now leaving the organization’s WAN, with the sudden shift to cloud-based services there is a parallel and proportionate increase to the strain put on the firewall. For a company that previously kept many of these services inside a private WAN, the requirements could exceed the firewall’s capabilities.

There is a significant force multiplier that is enjoyed by moving to the cloud. The readily available compute power makes true computational scalability a matter of a monthly subscription. In a way, this can be a double-edged sword. As power has increased, applications have increased their ability to consume greater resources. VOIP and video conferencing applications are rapidly rising in business use, requiring high bandwidth with high uptime and low latency, often needing an additional capability to prioritize traffic.

Not only are many key applications moving to the cloud, but, in a sense, so are the workers. The remote and mobile workforce is constantly expanding, and businesses expect this portion of their workforce to continue to grow. If we also include the multi-device users into this group, we can easily see the need for accessibility to any app, from any device, at any location. The balancing consideration to this is the increased need for security. With the idea of the “perimeter” effectively shattered by anywhere-access, there needs to be a strong means of authenticating and authorizing users, so as to reduce the chances of letting the wrong people into your network.

The other most noticeable change is the gap between broadband internet and private WAN services has become too great to ignore. When broadband meant 10M/3M of fluctuating and unreliable cable internet, then it made sense to pay 3x as much to get 10M/10M of guaranteed bandwidth. Now that cable internet can reach speeds of 1G/30M for roughly $500/month, dealing with a 10% fluctuation makes more sense than paying $1K/month for a 20M guaranteed pipe. Beyond that, broadband now also includes products like FIOS, ABF, and Fiber+, which bring fiber directly to the consumer, offering unguaranteed but symmetrical high-bandwidth internet circuits for hundreds less per month than their guaranteed counterparts.

The culmination of all of this is that an organization’s WAN now needs to be more accessible, more distributed, more secure, and more reliable than ever before, but it also needs to cost less.

Easy enough, right?

Through this series we will be providing many of the “Keys To The Black Box” that is SDWAN, so you can reach your organizational objectives regardless of whether you’re in the (re-)evaluating, deploying, or management stages of the SDWAN lifecycle.

Keep Your Team – Reduce Waste – Get Smarter Solutions