2009-07-16

Tell me the problem, not the solution

One of my customer companies is a startup. As a startup, they've currently got a CEO who is also CEO of a bunch of other companies. So this guy regularly jets around North America guiding his companies.

He's acquired a phone solution which is some kind of VoIP tied to his laptop. So where ever he happens to be, he can use the same phone, the same phone number and the same kind of calling plan.

The problem is he got it without talking to at least one of his IT people (ie, me). Which is a problem.

Yesterday he lands, and almost immediately I start getting a stream of email from one of his co-workers complaining about how this phone thing doesn't work. The phones depend on some sequential ports being available for them to use, so they want these ports set up for a bunch of IPs. However, we can't plug ports on the firewall directly to multiple internal IPs.

I get the name of the vendor out of them, and go off to their web site. There's no links to self-help. Only an invitation to describe your problem and indicate which customer of theirs you are. So I email back to them, sorry I can't help, open a ticket and tell them you have a blah-blah firewall and need help getting it set up.

Well a day later I get slightly more threatening email from them. They've decided they want some external consultant "who has experience with the blah-blah firewall" This doesn't put me in a much better frame of mind, because while this guy may know his stuff, he certainly doesn't understand all the "why"s that led to the firewall being configured the way it is.

As an almost off-hand comment, the email suggests I look at this link describing how to make a baby linksys router work. While the document in question was useless, I did see how to make the URL to their knowledge base; looking through THERE eventually nets me a document describing how this VoIP thing also depends on ports 10xxx and above.

And I happen to know that ports 10001 through 10009 are already in use. Which makes solving the problem a political issue, not a technical one.

This meant that the root cause was that the VoIP solution depended on fixed resources which happened to already be in use at our site.

So, what is there to take away from this?
  • If you are a user, describe the problem. Send links to any documentation, if you have it, up front. Don't just describe what you think the solution should be.
  • If you are a solutions vendor, make your documentation reachable from the main page (or a click or two beyond that) so that when poor IT people get dumped with your product having a problem, they have a fighting chance to get it sorted themselves. This means you as a vendor DON'T have to get it sorted.
  • And if possible, be flexible about what network resources you are going to use. Don't insist on fixed resources (like ports) if you don't have to.