Everyone has clients. In our world, clients are the people who want software to generate significant business value. Even make their business dreams come true.
For other software folk, the client might be internal – basically, the person within your organisation asking developer staff to meet a need, fix a problem, innovate something new.
Often, clients don’t know what they want. That’s not peculiar to software; I mean clients of anything. Being a client who doesn’t know what they want can be hard to admit; harder still for you to extract. Inertia can also arise when they do know what they want, but can’t properly articulate it. All this is completely understandable when the challenges are complex and the stakes are high. Sometimes you’re the problem; not the client. You just don’t get it.
Understanding the client is critical to getting out of the blocks on a software project. It kickstarts the scoping process and digs under the covers of the present business state as well as the future business need. Projects fail when business clients and software practitioners don’t see eye to eye.
Here are four ways to get a clear picture of what’s going on inside your client’s head.
Outlaw bull$*%! from your discussion
People talk; they take it in turns; one speaks while the other listens. These are ground rules you learn at playgroup, but worth restating for clients who ramble at you rather than natter with you. By all means plump up the cushions, put the kettle on, create the environment. But have an agenda, and ask questions.
Nothing is off limits except for jargon, ego and discourtesy. Don’t fall into the trap of using language as a weapon or being beaten up by it. This isn’t a power game. As software people, we can confound the hell out of clients with Kanban this and Agile that, a few drops of Jenkins and a sprint for good measure. It’s like a red rag to a bull and the client goes, “have some of my buzzword bingo then” and gives it back both barrels with KPIs and change management and bottom line until you beg for mercy. This is a waste of energy. You need them to stay on the safe ground of explaining in “friends down the pub” terms what they want for their business and ignore the technology bits and pieces which come much later in the process.
Play nice, talk proper. You’ll get more done.
Get them to tell the story
We’ve been telling stories ever since we stood up straight and grew opposable thumbs. It’s an immensely powerful human instinct and an essential framework for getting people to relate to one another. Stories are also incredibly rich in the kind of detail you just can’t get from a ‘positioning document’ or 20 slides of PowerPoint. People are hard-wired for stories.
The story you need is how the client arrived at the point they are at right now, and what the happy ending they want hopefully looks like. What told them they needed to hire a bespoke software development consultancy, or go knocking on the door of the internal development team? What have they seen, what have they heard, what do they fear, what do they desire?
Stories have a chronology that goes “and then this happened/is happening”, each one providing you with an opportunity to politely interject and ask a question. Stories can also be immensely liberating for the storyteller, opening up a cognitive capacity that they might rarely use and which could unbung blockages to articulating their vision.
Draw pictures
The client probably isn’t expecting you to whip out a gingerbread man-style figure and ask them to colour it in. Doing so not only arms you with the crucial element of surprise in a tricky knowledge download meeting, but it also provides valuable breathing space to come up with more questions while they bicker over the felt-tip pens.
Seriously though, there’s plenty of psychobabble out there about left brains and right brains and visual learners and spatial awareness, and all of it is fascinating stuff that ultimately supports this approach.
But like the storytelling gambit, drawing pictures is something else that appeals to our natural communicative instincts. People occasionally complain about being rubbish at drawing, but this can be quickly soothed by keeping a couple of spray cans up your sleeve (not really).
The best pictures are those that describe how to apply visual means to organise complex information, such as a reporting dashboard. You could even invite participants to sketch out what needs, motivations and frustrations are driving users, in the form of a visual storyboard. A note of caution: do not under any circumstances take as read anything that a client says about users unless they are actually users themselves. Their opinion is well worth recording, but additional focus group research is essential to getting to the bottom of these questions.
Ask why
The biggest mistake people make when trying to get answers is asking what and how and when, but not why. What do you want, how big should it be, when do you want it by? These are details. The nub of the matter is why. Why are we doing this? Why has it got to be like this or that? Another even more disarming, and some might say rather confrontational, approach is asking “what’s the point?” Or even, “who cares?” These aren’t intended to irritate the client, but sooner or later you are going to have to push back on some of their statements and really challenge their position. This is skillful work. Get it wrong and you can easily skirt past a really valuable bit of insight that could guide the project to an awesome result. Get it really wrong and get a cup of coffee chucked over you!
