Business Analysis & the art of Sign Language

What has Sign Language got to do with being a Business Analyst…? In simple terms, both are processes of interpretation, not – and this needs to be stated clearly – ‘just’ processes of translation.

Not that there is anything WRONG with translation – its an important skill in some scenarios – but translation skills alone will not really be enough to be a good BA (in my view, at least. Feel free to disagree!). Translation and interpretation are related but different processes in the same way that Cryptography & Steganography are related but different. Only by knowing which you are supposed to be applying can you hope to do it right! By the way, don’t worry if you don’t know your Steganography from a Stegosaurus… it’s obscure / specialised, which kind of illustrates my point: knowing what they are is only part of the battle.

Surely there is very little difference (perhaps just terminology?) between interpretation and translation? If you think this, and you are intending to follow a career as a Business Analyst, you’re in for a bit of a surprise and you’re also limiting your potential employability. If you’re already a BA and still think that what you do is translation rather than interpretation, you should consider the bigger picture. Learning to interpret (or, to be more precise, learning that what we BAs do primarily involves interpretation) will make you a far better BA. It is, from my experience, expected of BAs that we can interpret rather than ‘just’ translate. It’s also something we should do even when stakeholders don’t necessarily think we need to. We have all been in scenarios where the Stakeholder defines a particular requirement only for us to discover that the ‘requirement’ is to deal with a problem caused by something else (fixing the symptom instead of the cause).

If you are asked to interpret a User’s requirements but you simply translate instead, the chances of getting the best outcome are likely to be slim. You might get the translation ‘right’ according to the Stakeholder’s instructions but sometimes ‘right’ is not enough.In fact, ‘right’ is sometimes wrong!

Unlike translation in its simplest form, interpretation requires much more than just transposing one word for another. Even where translation becomes more complex (e.g. between languages where the ordering and context affect the meaning of the words or where translation is from an obsolete language), translation is still primarily based on knowing what word or words should be substituted to provide us with the original or intended meaning.

However, ‘interpretation’ is far, far more than just words. It is context, understanding & intent among other things. Back in the late 1980s, I spent three years as an ‘Interpreter of Sign Language’ (yes, really…!), working with various Police forces in and around London, as well as with the Courts and other Public Services (e.g. Hospitals, Social Services etc). Working with Deaf people made the importance of body language, facial gestures, posture, context and so on, very obvious. Working with them in the Legal sphere made the implications of mis-interpretation very real and very serious. Working with people from completely unintegrated domains (Barristers & Judges on one side, Deaf & Mute people on the other) highlighted the problems with domain terminology & jargon. Even terminology we consider ‘everyday’ has the potential to trip other people up.

Take the following for example. During a Court case in which I was acting as Interpreter, one of the Barristers (being unnecessarily verbose, as you might expect!), stated to a deaf defendant: “I put it to you that you were caught red-handed with a stolen vehicle. What do you say to that?”. Seems perfectly reasonable… right..? Maybe, but in this case the Barrister didn’t realize (or care?) that the context HE was familiar with was totally unfamiliar to the defendant. Skipping the detail of the ensuing debate, I was eventually asked by the Judge to ‘Translate’, rather than ‘Interpret’, the Barrister’s words. So I did. I can only guess that the deaf defendant thought the Barrister was bonkers. In direct translation, it would have come out as something like “I tell you that you were caught with a stolen vehicle and you had red hands. What do you say?”. As you can imagine, the defendant’s answer wasn’t quite as the Barrister might have expected. The actual response (which I didn’t translate!) was a vulgar reference to the Barrister perhaps being overly active doing something at night time that might make him go blind…

Consider, for example, that idiomatic idea of being “caught red-handed”… more than half the world will have no real understanding of that phrase and will either trip over it or, worse (for a BA) ignore it, perhaps to hide their ‘ignorance’. As a BA, I deliberately try to take the role of the ‘ignorant’, especially in cases where mis-interpretation might happen and especially in cases where I am new to the domain. Rather than worry about appearing ‘foolish’ or ‘underinformed’, I deliberately make it clear that my job as a BA is to get to the udnerlying message and often that means decomposing situations to first principles and to their most basic description.

With interpretation, at least in the forms I am accustomed to, the actual words are only a (small) part of the message. That’s a very important thing for BAs to remember. In a previous post, I quoted the line* that:

“There is significant evidence that the worst way to communicate information between people is via documentation”

…so it stands to reason that a BA who simply translates the ‘vocabulary’ from one system or process to another is missing out on a lot of the message. We all KNOW this, of course, because we all KNOW that even in everyday conversation the words are only a (small) part of the message. Body language, context, tone etc all form important parts of the message. Context is probably one of the easiest things to ignore but is vitally important in ensuring that understanding is captured and transmitted as well as possible. It is also very easy to miss, especially in conference-calls or video-conferencing and much more obviously in documentation.

For me, the primary purpose of person-to-person communication is to provide information in such a way that the RECIPIENT can understand it. There is little point communicating to others in a manner that illustrates how clever and intelligent WE are, if they can’t understand what we’re telling them. Even this blog post should fall into that category. If readers can’t understand my point(s), then writing and publishing it is a waste of time – as is reading it.

Anyway, the (somewhat labored?) point here is that we have to try to get ourselves into the mind of the User / Stakeholder / Business, and in a context that they are familiar with, when trying to elicit accurate requirements. I think the biggest skill (or art) a BA can develop is empathy: being able to put ourselves in the shoes (or seats) of the User, the Business or any other stakeholder as they provide us with their requirements.

All of this of course assumes the person providing the message actually knows what they want to tell us. In many BA tasks, this is not the case. In the same way that Henry Ford allegedly said something like “if I had asked potential customers what they wanted, I would have sold faster horses”, many BAs can probably identify with the idea that if we ‘just’ ask Users what they want, it will probably involve faster, bigger, better or easier-to-use Excel spreadsheets! As a BA, we need to also identify what it is that the Excel spreadsheet is being used for: where is the value to the business? If it is used to calculate something, can it be calculated some other way? If it is used to keep records of lists / data, can they be kept in a more useful and user-fiendly (not to mention usable) form?

This is where interpretation REALLY becomes important. When a BA is tasked with interpreting a User’s requirements, it is much more than just understanding what the User does, before documenting and then replicating it. We must also understand WHY the User wants to do this, what they hope to achieve, what the end result should be, what the business value is, what the environment is, what the ‘soft’ requirements are and many other things… flavored with our own experience (perhaps) of other scenarios – similar or otherwise. As we become more and more experienced, particularly of different scenarios, different businesses / sectors and different Users, good BAs will apply this experience more and more effectively in future projects.

In some sectors (at the moment, Legacy Modernisation in Banking systems and related industries are a good example at the moment), BAs can gain a lot of experience like this by contracting for short term consultancy-type opportunities. Far from being anxiety-inducing, the short term nature of these opportunities offer a great way to gain experience of different Users, different priorities, different systems & different scenarios. Additionally, by switching to other sectors when the opportunity arises, BAs can gain wider breadth of experience. All of this will make a BA more rounded as an individual, increasing their value to any employer – contract or permanent.

In almost all of my previous ‘careers’, I have been involved in ‘interpreting’ in one form or another (‘Interpreter of Sign Language’ is just the most obvious, but Lecturing and BA roles also include a form of interpretation). For me, the various techniques a BA uses (e.g. flow charts, UML, User Stories, whatever) only allow them to ‘translate’ but it is when applying intelligence, experience and non-technical aspects of the BA ‘art form’ that the BA is interpreting. As breadth and depth of experience increases, the BAs individual ability to interpret rather than translate will become more valuable and allow the BA to be more effective.
——–

* The line quoted was also the influence for my earlier post