Originally written Thursday, March 3, 2011.
As I type, I’m flying home from a three day customer site visit, listening to the movie Miracle on my iTouch. My day didn’t end well. Before we left the customer site we had a meeting with a technical representative from another Independent Software Vendor (ISV), and the interaction left me with new insight into why customers complain about ISVs.
We were onsite to evaluate the customer’s current solution and infrastructure, and then provide options for High Availability and Disaster Recovery implementations to support our application. The customer is in the process of changing part of the hardware that comprises the underlying infrastructure. As a result, there was a technical representative from that hardware vendor onsite, assisting with the change.
Part of our challenge was understanding not just what their current environment looks like today, but also what it’s going to look like when this hardware change is complete. We had one meeting with the ISV’s representative on Tuesday, where the rep spent most of the time providing high level information about the hardware. We did our best to ask questions and understand how the final environment would look. The rep seemed to be very hurried, even though we were assured the rep was there to help and answer questions.
Pause, it’s the scene in Miracle where he gives the speech before they play the Russians in the Olympics. I love this speech…and his pants.
We spent yesterday and today developing our recommendations, talking through them, figuring out holes, how to fill them and so on. We had asked for another meeting with the representative yesterday, but that did not pan out. We reiterated our request this morning, and finally sat down with the rep about an hour before we had to leave.
Our plan was to propose the High Availability solution, and step through it to clarify any gaps on our end. Within one minute, the rep told us the plan would not work and the customer did not have the infrastructure to support what we were suggesting. It went downhill from there. I was flummoxed. Where did we go wrong? What did we miss in our investigation? What questions didn’t we ask?
Then I realized I had to get past that, and figure out a solution based on what we now knew. So I started asking questions. And I kept getting interrupted. And I kept getting told what wouldn’t work. At one point I finally stated that I was trying to find a solution that would be highly available and utilize as much as the existing infrastructure as possible. And you know what the rep said? “I don’t know why you’d want to do that.”
He muttered it, just to me, and no one else on my team heard him. At that point, I shut down. It was suddenly clear to me that the rep had no interest in trying to use what existing hardware the customer had to help us create a solution. The rep said several times, “I don’t know how your application works.” I then understood it also meant that the rep had no interest in even trying to understand how our application works.
It was, sadly, a complete aversion to partnership.
While I know that highly available solutions are expensive, I don’t see any harm in trying to provide a solution that may not be completely automated, but still only incurs 15 minutes of data loss and 30 minutes of downtime. The cost difference between the two can be dramatic. But if the mostly-highly-available-solution provides the customer what they need, is that wrong?
To me, the representative was following a hard line of highly available, and there was no middle ground. There was also no effort to understand what our application needed, while we were trying to understand exactly how the rep’s hardware affected us. There was no collaborative discussion or knowledge sharing or brainstorming. It was very negative, and just not fun.
I’ve let the interaction bother me for a couple hours, and I know it’s time to let it go. It’s imperative to learn from this. I have a list of items we can do better next time we’re investigating the solution, and I have a list of hardware concepts and functionality that I need to better understand. As for interacting with other ISVs, well…I have a lot to learn there. That will come from experience, good and bad.
To those of you with complaints about ISVs, I get it. But I implore you to remember that not all ISVs are equal. While it’s my goal to give you the best set of recommendations I can, I also realize that you don’t have a blank check, and probably need different levels of recommendations to help you figure out how to get the most you can for your money. This is what consulting is all about, to me. I’m not your coach; I’m not going to come in and lay down the law and tell you how it has to be done. I’m a teammate, and I’m going to help you find something that works for you, and make sure you understand what it gives you and what it doesn’t give you.
Oh good, the US beat the Soviets in the Olympics. USA! USA!
Very good post, the hardest thing to overcome when you encounter the “unbendable arm” is to stop trying to understand why it doesn’t want to bend but simply accept that fact and move on. Its frustrating all the same. Thanks for sharing your experiences, amusing to read nether-the-less.
Thanks Mark. You are absolutely right in that I needed to stop trying to understand the individual’s attitude/aversion/whatever, and just move on. That was a failure on my part, and I will do better next time. It was a good lesson. Sometimes the only way to learn! 🙂
Good post, Erin. That same scenario often happens internally as well – Project managers vs programmers vs marketing – all saying different things but all trying to reach the same goal. Sometimes I just have quit saying “it can’t be done that way” and figure out a way to make it happen that way.
Gill-
Thanks. I could see it happening internally, with perhaps different motivating factors. This clarified for me the importance of getting all parties in the room at the same time. This is another challenge we face. Everyone is so “busy” and doesn’t have time to meet with us when we’re on site. To me, if you’re paying someone to come on site, you better require all the relevant parties to be available.
But…that’s just me 🙂
Erin
I can relate to this post Erin and have found myself at the frustrated level with having to remind someone that “the reason we are here is to make the client more productive”. Sometimes some people forget that the client is the important thing and not how YOU think the system should run. What I do when I find myself in situations like that is I try to remember the lessons I learned from Dale Carnegie’s book “How to Win Friends & Influence People”. That book was written years and years ago but it still applies because people have not changed that much. Everyone likes to help someone when they think that person respects them. Check that book out, if you’ve read it before then read it again. It helps me with not only dealing with “god-complex Hardware Techs” but with clients too. Also, “that what does not kill us, makes us stronger” I’m sure you learned a lot from that trip.
Todd-
Reading that book is an excellent suggestion, thank you, I will add it to my list. I have learned a lot over the years about how to handle myself in those tricky situations, but I *know* that I can always do better. I am always learning, and always looking to build my list of resources, so thanks again for the recommendation!
Erin