How IT Leaders Can Hold Vendors Accountable For Outcomes

If you’ve ever bought anything requiring a significant investment, then you’ve likely experienced the pre-sale courtship followed by the post-sale cold shoulder. During the sales process, the sales team is responsive, helpful, and solicitous. You get the impression that you’re beginning a relationship, not just buying a product.

Then the sale is completed, and suddenly emails go unreturned and questions unanswered.

IT Vendors

It happens in the enterprise IT space, too. That’s in part because too many vendors fail to understand the concept of enablement – the reality that using software solutions enables people to achieve business outcomes, but the mere presence of those solutions in your environment does not, by itself, guarantee a successful outcome. (Likewise, someone who buys a car but doesn’t know how to drive has not solved his or her transportation problem.)

Most vendors, though, do want to be accountable to your needs, if only because building long-term relationships is the only true way to grow their own businesses sustainably.

Yet accountability is a two-way street. When working with a partner whose job is to help you deploy and optimize a technology solution, the first step in holding them accountable is ensuring they fully understand your problem and desired outcome. Can they successfully articulate the problem back to you? Can they describe the business outcome you want in terms you agree with?

Only when the vendor can do that can you hold them accountable for driving toward your desired outcome. Then you can hold them accountable for the following:

Understanding your IT environment and your people.
Your vendor must become familiar with your existing IT stack, including the software tools you’re currently running and how those might interact with whatever you’re installing. You want to ensure that the vendor provides an IT solution that fits with what you have.

Moreover, your vendor needs to know who’ll use the tool and in what capacity. They need a clear picture of the technical capability of your in-house IT staff as it pertains to the new solution. Are your people capable of managing and optimizing the tool over time?

Providing training and delivering insights on who’s thriving, and who’s struggling, with the solution.

Training is an often-overlooked aspect of new software deployment, but a properly trained user base is an essential element of driving up adoption rates – and a high adoption rate among your intended users is a prerequisite to achieving value from your IT investment. Put another way: If users don’t feel confident about using the tool, they won’t use it.

Here’s one example of what that looks like. According to SoftWatch’s 2015 Microsoft Office Benchmark, users on average spend less than one hour a day using the Microsoft office productivity suite, and most of that time is in the Outlook email client. That’s just a single software suite, but the pattern is distressingly familiar: Organizations spend considerable amounts of money on annual maintenance and upgrades for software products their employees rarely use.

Continuing to work with you and your team long after deployment.

Your new software asset represents a treasure trove of features that would help move your organization forward if you had the skilled resources to bring those features to life. Without those resources, many IT leaders fall victim to “blame-the-tool” syndrome, eventually losing faith in the solution and replacing it with something else.

We’ve long said that a solution deployment is the beginning of your journey to achieving desired business outcomes, not the end. Make sure you understand how long your vendor will continue to work with you to understand the tool’s capabilities and build on them.

Deploying new software is always a challenge. By setting expectations with your vendor and ensuring they understand your business, you’ll go forward ensuring you have a true IT partner, not someone who’s just selling you something.

For a deeper conversation about driving outcomes, instead of just meeting technical requirements, reach out.

Related Posts

Should You Pay for IT Services by the Hour, Project, or Outcome?

Organizations traditionally pay for outsourced IT work in one of two ways, by the hour for time and materials, or by way of a fixed price for the entire project. There are assumed advantages in each of these scenarios – paying hourly allows you to control costs by managing project …

Jesse White • May 14th, 2020 Continue Reading

4 Ways You Can Actually Achieve Business Outcomes in Your Next Project

Organizations purchase software not to implement new software, but to achieve business outcomes, such as improving customer experience, increasing operational efficiency, remediating risk, and reducing operational costs. As project design begins, however, these business outcomes become buried beneath lengthy lists of technical requirements and project deliverables, and become increasingly distant. …

Jesse White • May 14th, 2020 Continue Reading

What IT Leaders Can Learn from Trader Joe’s

The science behind choice reveals that although people are drawn to having choice, having too much of it contributes to anxiety, dissatisfaction, and inaction. Approaching IT project design without considering this paradox will yield underwhelming and ineffective results, and as this process is the bedrock of any IT initiative and …

Jesse White • May 14th, 2020 Continue Reading