When I do these more serious posts about workplaces issues, not so much of my angry persona leaks out. A little does, to be sure, but not so much as, say, when I'm foolish enough to get into politics. Part of this is not wanting to completely obscure serious points with humour but part of it is my nature; when I'm dealing with situations that require more analysis I tend to get more clinical and I try to keep emotional responses to a minimum.
I'm sure this is true in business generally but I know for a fact it's painfully true for IT workers: sometimes you have to deal with "customers" (whether internal people/departments that have a stake in IT development or actual paying customers) who are absolutely infuriating. The disconnect between customer thinking and what is possible, sensible or even a vaguely good idea is sometimes truly staggering. But then again, if we were honest, we'd have to admit that some of the thinking coming out of IT departments is not even a distant relation to common sense or reality.
As a Business Analyst, I tend to be put between these two (often conflicting) worlds. When I'm in a good mood I feel like I'm the bridge between two worlds, clarifying and translating when IT doesn't understand business needs and the business side doesn't understand IT needs. On bad days I feel like the meat in the sandwich. My starting point is that I'm in IT and I'm usually representing IT interests - so how do I do this without losing my cool in the face of what seems to be insurmountable ignorance?
I should probably start by giving an example of a fairly dramatic failure on my part to do this well. A little while ago I was contracting with a little start-up who were doing some interesting work, very web 2.0 stuff. They are probably the best at executing this type of web based services I have seen in Australia. But, inevitably, the day came when something really dumb was proposed. A web application aimed at the advertising industry was under development but progress had stalled and I was working on resolving some of the issues. It soon became clear that the biggest issue was the manager of the internal business unit that was selling the product to advertising agencies (selling a product that didn't actually exist - is this sounding familiar to anyone?)
The concept itself was extremely strong - an online communication tool that let everyone involved in the very complex of shooting an ad stay in touch and book each other's time. The development was well-advanced, we had a prototype that showed how to turn what had been a manual process that could take weeks to resolve into an online process that could be set up in one or two days. But then the product manager saw some over-designed Flash-based website with animation out the wazoo that he decided was "sexy". Everyone wants to be sexy. People in the advertising industry definitely want to be sexy. So when he showed this example to potential client and promoted how sexy it was, of course they all said that was exactly what they wanted.
Nobody wants to say "no thanks, I'd rather not be sexy."
The problem is, this was a product designed to be used all day every day for people's core work. No matter what someone tells you they want, what they need is something that is functional and doesn't get in their way when they're working. The primary problem with this over-designed monstrosity is that it would slow down every single task for the sake of animated menus, rounded edges and general "sexiness". I needed a way to convince the product manager that his central idea that he was so excited about simply couldn't work. No matter how much people said ahead of time they loved the idea (nobody will say they don't want to be sexy) they will hate you five minutes after they start using it and it becomes clear this application will make their life a misery. So I sat him down and calmly said:
"This is a really dumb idea. You have to go with the simpler interface the programmers have already developed. I know everyone at the advertising agencies told you they loved the concept but trust me, they'll find it impossible to use. If you insist on following this, the developers will hate you for making them do it and the customers will hate you for making them use it."
Did I mention that the product manager was a senior boss's brother? All in all, not the best career move I've ever made. On the plus side, after saying this the development team really, really wanted my contract to be extended. On the negative side, nobody on the business side seemed particularly impressed that I'd held up one of their own to ridicule and started to argue that "I wasn't a good cultural fit" for the company. I probably could have stayed there if I had really wanted to (the CEO was on my side) but it was a really good job market and I decided I didn't need to put up with that sort of crap.
So there's a prime example of how not to do it. Here's a few examples of how to handle difficult customers in a way that's more likely to generate a positive outcome for everyone concerned:
1. Don't tell someone their idea is stupid. Instead of what I did in the above example, try to steer the discussion towards a positive outcome rather than highlighting how stupid the proposed idea is. The best way to do this is to ask questions rather than make statements. People can argue with statements but they have to answer questions. I learned while researching something else that this is essentially Socratic Irony - you play dumb and treat the person you disagree with as an expert. Eventually, they'll talk themselves into a corner.
2. Start the analysis at the highest level possible. Any discussion with a customer that starts with "I want this type of system that uses this framework and looks like that" is destined to have a lot of problems. It's surprising how often people who dive straight into "solution mode" can't clearly articulate the central problem they're trying to solve when you put them on the spot. How can you arrive at a solution when you can't even say what the problem is? Discussions should start at cloud level (to borrow a term from use case methodology) and ask in the broadest possible terms: what are we trying to achieve? Ideally, the first people to talk about an actual IT solution should be programmers.
3. Know when to stop analysing. I'm not an advocate of Agile methodology per se but you definitely need to avoid analysis paralysis. If a customer is driving you crazy with over analysis of requirements, know when to move from thinking to action. There are too many variables in any IT project to know without doubt how things are going to turn out. I'm in favour of having clearly defined goals and a plan on how to reach said goals but at a certain point you need to stop planning and start delivering. Sadly, this is more art than science and it's impossible to define exactly how much analysis will be required in all cases (anyone who says otherwise is trying to sell you books and/or seminars). The right amount is however much it takes to execute the project successfully - don't stop too soon and don't go on too long.
4. Define what you're going to deliver. It's an irony of IT that the customer who wants something is often very bad at defining what they actually want. One of the most important roles of a BA is to articulate what is actually going to be delivered in a way that's clear enough for the business side to understand yet precise enough for the development side to deliver on. It's easier to avoid getting angry with a difficult customer if there's an objective source to refer back to, that way you don't have to argue over points in isolation because there's always a way to bring focus back to the conversation.
And my number one tip for avoiding getting angry with a difficult customer:
5. Know when to walk away from a discussion. There will come a time when it feels like you have two choices with a particularly insane customer who is placing unreasonable demands on you: strangle them or walk away. Walking away is always the right response no matter how satisfying you think it might be to strangle them. End the discussion in a dignified way, not with a screaming hissy fit. Say: "I think we've reached a point where further discussion isn't getting us anywhere, let's leave this for a while so we can all think about it and get back together later," and set a time for another discussion. This is infinitely more useful than screaming "I hate you! I'm not putting up with this crap any more!" and storming out.
The sad fact is that in most organisations, IT people are lower on the food chain than sales people and we simply have to deal with that. Mastering the anger that threatens to well up when dealing with people that we quite frankly consider to be idiots is a skill everyone should master. I've seen too many people who were completely in the right lose all credibility because they shouted, swore or stormed out of a difficult meeting. Find you own way of dealing with customer-inspired anger if none of these work for you but for your own sake, don't let the bastards get to you.
No comments:
Post a Comment