“Expectations are a form of first-class truth: if people believe it, it’s true.”
I don’t know about you, but when I spend millions of dollars on IT management software, I expect the software to help me achieve the most critical business objectives that I face. This expectation, however, is not the only expectation that is set during an enterprise software deal; there are expectations that the vendor will support the software, that the professional services experts will deploy and configure the software in the best possible way, and (if all goes well) that the customer will pay for the products and services received.
There is yet another expectation set during an IT software deal that is less obvious, but in my opinion it is the most important of all expectations set. In every IT software deal, there is at least one person (sometimes many) that for sake of simplicity we will call the “influencer(s).” These influencers work for the customer, are typically a part of the IT organization, and are the ones who raised their hands and voted for the solution that will now be implemented. The reasons that an influencer chooses one vendor or another are often varied, but those reasons are irrelevant for the purposes of this discussion. What we are focusing on is the expectation that gets placed on the influencers (sometimes without their realization) by their peers, customers, and management as a result of the influencers’ decision to support a specific vendor or software.
Imagine that a solution provider is trying to set the customer’s expectations around the solution’s capabilities, but meanwhile the customer already has other unexpressed expectations around their own perceived value of the solution. You can serve the best caviar on a solid gold spoon to acustomer, but if they are vegetarian, they will remain hungry and unimpressed. A solution provider’s focus on trying to create or modify the customer’s expectations, although well intentioned is self-defeating. Why?
When it comes to the sales cycle of IT software, the advice we most often hear is, “Set the customer’s expectations appropriately.” Too often with large IT projects the customer gets that old familiar feeling that what they were shown prior to the software deal was not really what was delivered. “Bait and switch” and “smoke and mirrors” are terms often used to label this phenomenon, because the customer’s expectations around their perceived value have not been met. “Set expectations appropriately” is, theoretically, a good piece of advice. However, I would like to argue that this is the wrong advice.
The customer’s expectations have already been set by the influencers long before your solution was even put in front of them. Each influencer expects to receive what they perceive as valuable from the solution. Each manager involved in the selection of the vendor now has an expectation that the influencers on their team are making the best recommendation for the business as whole, regardless of whether the influencers are making their recommendations based on their own needs, the needs of their organization, or the needs of the company. The vendor did not set these expectations, nor did the solution set these expectations, yet we are left with a towering skyscraper of expectations for the software solution to fulfill. Now, all it takes is for one influencer to feel that their expectations were not been met, andthe perception becomes that the solution did not meet the needs of the business. Not only does this take focus away from the objectives that have been met by the solution, but it also means that all the pressure created by the perceived failure falls back on the individual influencers. The question asked of the influencers by their managers, “What product will best meet our needs” now becomes an accusation, “This was your idea.” The blame game always starts up when the poop hits the fan. It no longer matters what “the truth” is behind why the implementation is failing, because there was an expectation that the perceived value was to be delivered, and it was not. This perception now becomes “the truth”.
IT Software Goes on a Blind Date
An analogy: you (aka, the influencer) have a friend (aka, influencer’s boss) that is going on a blind date (aka, needs to deploy a new ITSM solution). Your friend asks you for a restaurant recommendation for the date (aka, which vendor should I choose for our new ITSM solution?). You suggest your favorite restaurant, and simultaneously set the expectation with your friend that this will be a good place to dine on a date. The restaurant (aka, the vendor/solution provider) has no idea what the blind date likes to eat, and must assume that because they are dining here, they must like what is being served. There are three possible outcomes to this blind date:
1) There is a chance that the outcome of the date will have nothing to do with the food.
2) There is a chance that the date will be negatively impacted by the quality of the food.
3) There is a chance that the date will be improved because of the quality of the food.
There are many reasons the date might not go well that have nothing to do with your restaurant recommendation (outcome #1): traffic, illness, lack of chemistry, lack of personality, lack of hygiene, etc. These outcomes could occur regardless of your restaurant suggestion, and you have no control over them. The outcome is completely disassociated with your choice of restaurant, so as long as your restaurant choice was not bad, then this is still a win (albeit a small one). Your friend will still be your friend and will come to you for dining advice the next time, because although the outcome was not the best, your advice was not a part of the problem.
There are also many reasons that your choice of restaurants may have negatively impacted the date (outcome #2): food allergies, dislikes, quality of food, quality of service, funky smells, cockroaches, etc. This is the worst outcome for you as the influencer. Your friend’s expectation has not been met, and the negative outcome of the date directly correlates to your choice of restaurant. Perhaps your idea of a “good” restaurant is not the same as your friends. Perhaps you did not know that your friend’s date was a vegetarian when you suggested the best steak house in town. The point here is that the reason this outcome occurred does not really matter, because the impact is inevitably the same: the restaurant gets a bad review, your friend goes home unhappy, and you are essentially the scapegoat.
What if you could eliminate, or at least drastically reduce, the possibility of outcomes #1 and #2 in your next software implementation project? Not only would the customer, the vendor, and consultants all have achieved success from a project perspective, but greatly reducing the chances of outcomes #1 and #2 means that risk of failing is much lower. Essentially, this means you can be both successful, and sleep peacefully at night. Amazing, right?! How is this possible?
In our restaurant example, what if you as the influencer had more information in advance about the blind date? Would it have helped to know that the date was vegetarian, or had a peanut allergy, or loved Thai food? Would it have helped to know that your friend wanted his date to know that he had an appreciation for gourmet food, or that he was on a carb-free diet? What about knowing that the influencer’s boss was afraid of being viewed as flashy on the date, and was looking for something under $40?
In our ITSM project, would it be helpful to know that one of the influencers hated this specific vendor? Would it be helpful to know your influencers thought the existing problems were process related and would exist regardless of what solution was implemented? Would it have been helpful to know that the only need your influencer had was to reduce the time required to resolve an incident, or to try and reduce the number of unplanned changes. These perceptions and expectations do matter, and will ultimately impact whether or not the date (or IT project) will end well.
Our goal as solution providers should be to understand the customer’s perceived value and expectations, and simultaneously try our best to meet all expectations and deliver the value as the customer understands it in parallel with the value as we understand it. Sometimes this means we have to compromise or sacrifice some of our own ideas of what is valuable. Sometimes we have to manage opposing ideas about value from different influencers that exist within the same organization. Sometimes the best thing we can do for a customer is to empower the influencers so that they may one day be able to inspire a revolution within the rest of their organization.
At the end of the day, if you deliver caviar to a customer that wanted grapes, you lose. If you deliver grapes to a customer that wanted caviar, you lose big time. But if you deliver both grapes and caviar to a customer that only asked for one or the other, you win the whole enchilada (so to speak).
What does this example tell us about unsuccessful software implementations?
There are two universal lessons here:
1) Perceived value is a constant. It is always there, in everyone, and you cannot change it. If you choose to ignore it, you are ignoring the opportunity for a successful outcome.
2) There is always at least one influencer for every IT project. Getting to know them, understanding their needs and expectations, and doing everything possible to guarantee their success will simultaneously guarantee yours.
In future articles, we will look at both of these lessons in further detail, and we will provide some real world examples of how solution providers can better serve their customers, and how customers can better server themselves. For now, here are a few questions to get you thinking about perceived value and expectations.
After reading Ramblings of a Disturbed Consultant, think of two examples at work when you were called upon to help make a business decision: one where your advice was taken and the result was viewed as successful, and one where your advice was taken and was not viewed as a success. What was different about the perception of value in the each case (yours, your managers, and your peers)? Were you aware of any unspoken expectations that were placed on you? Did you have expectations of your own? In what ways did the expectations have an impact on the outcomes? If there were other influencers involved in the decision, how were their expectations and perceptions of value different?