It’s been a while since I blogged, and while the next installment in my NoSQL and CMS series is in the process of being written, right now I’m fired up about a totally different topic, and thought in fine curmudgeonly fashion I’d vent my spleen here.
So what has me so fired up it’s brought me out of my extended blog hiatus?
Clients Behaving Badly, aka Nasty Vendor Management Games
In a nutshell, these are the games clients play with providers (vendors) of a product or service in order to extract as much value from that provider as possible. Many such games are entirely legitimate (in fact I have increased respect for clients who utilise those!) but there are also many that are inherently exploitative in nature, and it’s those ones that have me fired up at present.
I’m not the first to have commented on these silly games (I wish this post was as entertaining!) and others have commented on the reverse situation – providers playing dirty tricks on clients. The point of this post is that such tricks are not limited to those who sell products or services, let alone those engaged in the Content Management arena.
What I’m going to do here is enumerate some of the more unpleasant games I see being played, primarily during the implementation and production phases (since that’s primarily where I live). If you’re on the provider side this may help you to recognise these games when a client trundles them out and take appropriate action (if any – sometimes it’s appropriate to just play along). If you’re on the client side, I would encourage some honest self-appraisal of whether you’ve used or continue to use any of these tactics when dealing with your providers – keeping in mind that they will likely backfire (or at least be defanged) if the provider wasn’t born yesterday.
In no particular order, here’s my list:
Robo-Questioning
This is where the client asks a provider staff member a question, and if the answer is not to their liking they simply ignore it and ask someone else the same question again (repeating ad nauseam if they get the same answer repeatedly). The game stops when the client gets the answer they were looking for or a reasonable approximation – at that point they hold the entire provider to that particular answer.
In practice it’s rare that this tactic will achieve the result the client is after, since usually there’s a good reason they’re getting an answer they don’t like (particularly if they get the same answer several times). In fact chances are the answer the client liked came from a well-meaning but uninformed member of the provider’s staff and is therefore of dubious accuracy.
Examples:
- Asking a detailed technical question, ignoring the answers from technical staff but accepting the answer from a sales person or marketer.
- Asking a licensing question, ignoring the answers from sales staff but accepting the answer from a technical person.
Selective Deafness
This game is a variation of the previous one. In it, the client asks a question, receives an answer not to their liking, but continues the conversation as if they had received the answer they wanted.
Examples:
- Asking for a discount (so far so good), but then ignoring a “we’re terribly sorry, we cannot discount this” response by saying things like “so that’s agreed then – you’ll send us a quote with the X% discount?”.
Revisionist History
This game involves the client denying prior events or creatively reinterpreting them. In the best case there is documentary evidence from the time the events took place that neatly summarises what actually happened (meeting minutes, for example – learn to document everything you do, kids!), allowing history to speak for itself.
Ultimately though, this game is an extremely toxic one because it completely annihilates any trust that may have existed between client and provider.
Examples:
- Client stating that a particular recommendation was made by the provider when it was not.
- Client asserts that they had never been informed that something they were doing was ill-advised, when in fact they had.
- Client is Winston Churchill, who beautifully summarised this game when he said “History will be kind to me, for I intend to write it”.
Damsel in Distress
I find this one quite depressing, given how trivially it can be avoided (at least if the issues are related to whatever the provider delivers).
The classic manifestation of this game is having a client approach a provider (typically a product vendor of some kind) with the message that their product is “fundamentally broken and you better come over here and fix it RIGHT NOW before we go postal on your a**!”. Typically this message of hope and inspiration is delivered shortly after some important milestone has just been missed.
A common (but panicky) vendor response is to throw some poor professional services peon at the client, promising that all of the problems will magically be fixed. The poor suckerconsultant can see #fail written all over the assignment from light years away, and can see that if only they’d been involved 3/6/9 months earlier disaster would have been averted via an informed design.
To add insult to injury, if the vendor’s sales staff are doing their job, they would have seen the potential for disaster and recommended training and/or professional services early on to help stave it off. If this is the case and the client ignored that recommendation, they will often play a double game of “Damsel in Distress” and “Revisionist History”, presumably figuring that the one-two punch of tactics will bludgeon the provider into submission.
Bullying / Badgering
If the one-two punch isn’t enough, truly obnoxious clients will turn to bullying and badgering to bend the provider to their will (on occasion this game is also played independent of the others). This game has numerous variations, including:
- Leapfrog – complaining up the chain of command when something isn’t going their way (this is a particularly nasty combination of bullying and robo-questioning)
- Threats – ranging from “we’re considering dropping you” to “we’re talking with our lawyers”
Failure to RTFM
This one is so silly I almost can’t believe it makes this list, but, well, it’s also ubiquitous so deserves some air play. This is really just another manifestation of the general trend towards hubris seen amongst techies (a topic which deserves a post all its own, and yes I am as guilty of this as anyone).
Typically this one starts out with a techie thinking something like this: “I don’t need to read some stupid manual to install this here application. How much trouble can I get into by double-clicking install.exe??”
Lots, as it turns out, and you don’t come across very well when you pull a “Damsel in Distress” 6 months later and the provider responds with “that’s described in bold red blinking 48pt Comic Sans on page 2 of the manual”.
Misdirected Accountability
This is typically seen when a client demands that a provider support someone else’s work. This can take quite a wide variety of forms, including:
- Client designs and develops extensions by themselves (without RTFM of course), and those extensions are unstable, perform poorly or any one of a bezillion other problems. They then blame it on the provider and demand that they fix the “broken product”.
- Client engages a third party to implement some extensions to a product, then after that third party has long since ridden off into the sunset demands that the provider fixes bugs in it.
- Provider’s product uses some third party product (a relational database, for example) but client doesn’t have the skills to maintain or support that third party product so over time the entire system becomes slow and/or unstable. They then blame the provider’s product, since that’s where the symptoms are most visible.
Blamestorming / Finger Pointing
This game often follows on from Damsel in Distress, particularly if jobs are at stake. Rather than focusing on determining where problems lie and addressing them (irrespective of fault), the client team reverts to an unproductive game of finger pointing.
Foil Bait
This is a pre-sale game where the client is using the provider as leverage with their incumbent provider, or another provider that they are actually interested in. This is a commonly used tactic on open source software vendors, since there are some clients who see open source as little more than a great way to scare traditionally licensed vendors into discounting their hefty up front license fees.
An obvious warning sign is a prospect that is very interested in pricing, but isn’t particularly interested in product functionality or service offerings.
In Conclusion
And there you have it – a veritable Smörgåsbord of unpleasant client behaviours that anyone who’s worked for a provider of some kind (be it product or services) is likely to have seen at one time or another.
I have no illusions that this post will help reduce the prevalence of these antics, but at least by shining a spotlight on them I can encourage providers to be vigilant, and enter new client relationships trusting that they will be conducted respectfully and to mutual benefit, while also verifying that silly games aren’t on the cards.
The CMS Curmudgeon 