8 Painful Vendor Mistakes IT Pros Make
When InformationWeek surveyed 100 IT leaders about their biggest mistakes, failures around vendor choice, contract negotiations, and SLAs emerged as major sources of pain. Here, we highlight 8 mistakes IT professionals make in working with vendors -- and what you can learn from their experiences.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt628a1c8d536570fd/64cb44dd6ca4553d329db132/maze-ladder_31245690_SMALL.jpg?width=700&auto=webp&quality=80&disable=upscale)
How much of your time is spent evaluating, testing, and working with tech vendors?
If you're like most of the CIOs and other IT leaders we speak with on a regular basis at InformationWeek, managing vendor relationships probably takes up a lot more of your time than you'd even care to admit. It's also the place where you can make your worst, most visible, career-altering mistakes.
InformationWeek polled 100 CIOs and other IT decision-makers earlier this year about the worst mistakes they've made in the past 12 months. Respondents regaled us with tales of how they've ruined their relationships with the business and their worst IT and staffing failures.
But a special kind of pain emerged among those who shared tales of vendor experiences gone wrong. Pitfalls included troublesome contract negotiations, weak service-level agreements, and vendors who overpromised and under-delivered.
Every year, InformationWeek releases the Elite 100 -- a ranking of the nation's most innovative users of business technology. As part of the process, we also conduct the annual InformationWeek Elite 100 Executive Research Survey, which offers a unique glimpse into the strategies of these 100 large, leading-edge IT organizations.
The survey, which is open only to Elite 100 applicants, polled US-based companies and higher education institutions that have $250 million or more in revenue. Subsidiaries with revenues below $250 million may apply for the Elite 100 if their parent company has qualifying revenue and their parent company did not apply. Federal, state, county, and local or municipal US agencies are also eligible to apply.
The eight mistakes we're highlighting here are drawn from responses to the InformationWeek Elite 100 Executive Research Survey and have been anonymized to protect the innocent -- or the guilty, as the case may be.
[See 9 Ways IT Can Ruin Its Relationship With the Business.]
If you're looking for more guidance on how to evaluate vendors, consulting firm Temkin releases an annual Experience Rating of Tech Vendors each November. The company surveys 800 IT decision-makers from large companies to evaluate their experiences with 62 large technology vendors.
The Temkin Experience Ratings of Tech Vendors evaluates three areas of customer experience:
success (Can customers achieve what they want to do?)
effort (How easy is it for customers to do what they want to do?)
emotion (How do customers feel about their interaction?)
You'll see each of these categories emerge as pain points in the eight experiences we're highlighting here. Once you've reviewed these eight vendor pitfalls -- and some of the ways IT professionals have resolved them -- share your own experiences with us in the comments section below.
The IT organization at a large energy company was moving ahead with a cloud strategy leveraging two public cloud providers for platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS). All seemed to be moving along well in 2015 as the CIO and other IT leaders pursued technical evaluations, made targeted vendor selections, and began establishing legal frameworks to support the cloud strategy.
"As a large energy company with worldwide operations, we had to consider both company and international requirements around security, privacy, audit and governance," said this survey respondent. "We needed the vendor disclosures and legal points to be addressed in our legal frameworks in order to move forward with enabling our business with cloud solutions."
That's where things fell short. "Our single biggest mistake was underestimating the time and effort it would take to negotiate the cloud legal frameworks with major public cloud providers," according to the survey respondent. Ultimately, the team's persistence and due diligence paid off with successful agreements that met all requirements.
The lesson learned? "Establish clear criteria on what the deal-breakers are, and ensure you have alignment on the risk-benefits," said the respondent. "Allow ample time for due diligence, and ensure the legal frameworks are established before business pressures force you to compromise on key issues."
With each new product deployment comes the need for vendor service, yet it's all too easy to let these service contracts renew without review. That's one of the bigger mistakes one respondent said his company made in the past 12 months.
"A large portion of an IT budget is comprised of service contracts, and frequently there are many legacy agreements that can be renegotiated and re-evaluated to lower spend," the respondent said. "If we had engaged dedicated resources earlier, it would have led to cost efficiencies and forced us to gauge the value of our service contract portfolio."
Lesson learned: Investing the time and personnel to evaluate your vendor service contracts on a regular basis will pay off in terms of potential cost savings. It will also help eliminate redundancies as your organization's service needs change.
Is anyone in IT happy with the ability of vendors to meet performance-based service-level agreements (SLAs)? The pain point emerged starkly among respondents to our survey.
Here's one example: In late 2014, one respondent added terms and conditions to external vendor agreements through a refined RFP that included key metrics, SLAs, and additional industry benchmarks. It became clear in 2015 that external vendors weren't meeting their performance SLAs, and proactive attention was needed from IT.
Lesson learned: This respondent said, "We are drafting controls and governance around measuring SLAs, and holding our vendors accountable for their performance."
One financial services company had high hopes for a new privileged access management (PAM) tool it was deploying. The company selected the tool after a thorough RFP and proof-of-concept. That's about where the goodness ended.
According to the respondent, "Unfortunately, implementation of the product in the production environment proved difficult. The tool was plagued with technical issues, and features did not work as advertised."
The product was implemented, but because of the limits of the technology the scope of the implementation had to be greatly scaled back. This left the company -- for which customer data is of the utmost importance -- with security vulnerabilities.
The lesson? If something looks too good to be true, it probably is. This respondent said the company learned new questions to ask of vendors as a result of this mistake, and is pursuing an alternative solution offered by another leading vendor in the marketplace -- after much delay and cost.
There's no easy way to say this. Not all vendors can be trusted, and sometimes you don't find out until it's too late.
That's what happened to this respondent, who admitted, "We had too great a reliance and trust in a vendor-led system implementation."
The respondent said his company purchased key compliance systems from a vendor as part of an upgrade and consolidation of its existing platform. "The vendor has a privileged position in the market being the de facto standard for this capability, and being in good standing with our industry regulator."
Unfortunately, the vendor sold the product beyond the capabilities of its delivery organization and had challenges with staffing and delivery methodology. This caused the respondent's IT organization to have significant overruns in product timeline and costs. "The level of trust in the delivery capability was misplaced and resulted in significant additional cost to our organization," said the respondent.
What's an IT professional to do? For starters, don't take a vendor's profile for granted. Make time to find out who among your peers at other companies has also used the product, and ask about their experiences.
Check with industry professionals on social media to learn more about their experiences with a given vendor. Ask the vendor for customers you can talk to directly. If a vendor isn't willing to provide this, consider whether you can trust that vendor. There's no substitute for due diligence.
In IT, it can sometimes feel like no good deed goes unpunished. Such was the case for this respondent, whose organization wanted to give employees a simple, secure way to remotely access network applications from their personal PCs, smartphones, and tablets.
The IT team settled on a web-based VPN solution and rolled it out to users with great fanfare and a big internal marketing splash. Unfortunately, one key component was overlooked: updates.
"We found over time that the remote access capability relied heavily on Java framework," said the respondent. "Each time a Java update or security patch came out, the access became unstable. IT resources were now responsible for supporting out-of-date hardware and software across multiple platforms."
The respondent said, "We threw in the towel, ate some crow, and migrated to Microsoft Remote Desktop Protocol."
The lesson for this respondent? Be sure to consider the framework on which your choices are built, and factor in the effect that frequent updates and security patches will have on your users.
-
About the Author(s)
You May Also Like