The Bad Practise Blog

Yes that is a play on the brilliant R.E.M. song and I hear it playing in my head each time a read some article or post that disrespect me by underestimating my ability to reason or apply common sense. But maybe let’s take a step back and look at the bigger picture. Years ago, before we were tried to fix natural stupidity with artificial intelligence, you used to get user manuals with your products that actually said something. For instance you motor vehicle manual had a section describing how to set the valve clearance. Now I now that reference is very gender specific but I am sure that it was the same for all sorts of other appliances. The point I’m trying to make is that people were trusted with value adding information with the assumption that they had some level of intelligence (there are exceptions and there always will be).

The Current State

Fast forward to today and this is what we are bombarded with everyday:

• “Do not use if you cannot see clearly to read the information in the information booklet.” — In the information booklet.
• “Caution: The contents of this bottle should not be fed to fish.” — On a bottle of shampoo for dogs.
• “Do not use while sleeping.” — On a hair dryer.
• “Shin pads cannot protect any part of the body they do not cover.” — On a pair of shin guards made for bicyclists.
• “This product not intended for use as a dental drill.” — On an electric rotary tool.
• “Caution: Do not spray in eyes.” — On a container of underarm deodorant.
• “Do not drive with sunshield in place.” — On a cardboard sunshield that keeps the sun off the dashboard.
• “Caution: This is not a safety protective device.” — On a plastic toy helmet used as a container for popcorn.
• “Not intended for highway use.” — On a 13-inch wheel on a wheelbarrow.
• “This product is not to be used in bathrooms.” — On a Holmes bathroom heater.
• “Eating rocks may lead to broken teeth.” — On a novelty rock garden set called “Popcorn Rock.”
• “Caution: Hot beverages are hot!” — On a coffee cup.
• “Do not iron clothes on body.” — On packaging for a Rowenta iron.
• “Do not drive car or operate machinery.” — On Boot’s children’s cough medicine.
• “Wearing of this garment does not enable you to fly.” — On a child sized Superman costume.

While I know and accept that there are the exceptions out there, I do feel offended by these warning labels. Somebody out there thinks that I am stupid and do not have the common sense to know that hot beverages are hot or that deodorant should not be sprayed in your eyes or that a superman costume does not give you supernatural power. But this is something I can, and must live with and I sort of understand why the 99 must cater for the 1 dimwit. Suing somebody for your stupidity has become very easy, and also the norm. But the point I’m trying to make is that this absurdity has now infiltrated professions such as business analysis.

Instead of applying focus on doing what we should be doing better and thereby adding value, we are being told what language should be used. The latest warning label look like this:

• “Using the phrase ‘Gather Requirements‘ will lead to poor quality work, disrespect and uncertainty”

What utter BS. If that warning rings anywhere close to the truth for you then I’d suggest staying as far away from business analysis as possible.

To Gather or Not to Gather, that is the useless question

Let me make something very clear. I am not against or for any language or terminology, I am for whatever gets the job done and adds value. In this particular case using the word ‘gather’ instead of ‘elicit’ adds no value to your stakeholder. Sure the essence of the two words are different but so what. If I ask you to go fetch me some water I assume that you’d have the common sense to go to the kitchen, take out a glass, open the tap and fill it with water (or whatever other process you follow). There might even be a glass of water on the kitchen counter just waiting for you take. The point is that a reasonable person understand that the use of the word ‘fetch’ implies that if it is not readily available you need to do what it takes to make it available.

If you read any Business Analysis textbook you’ll most likely find a section that describes the tools and techniques to be used to ‘gather’ requirements. This in itself is a very clear indication that these requirements will not just be lying around, waiting to be picked like apples, as one person puts it. It is clear as daylight that these tools and techniques must be used in various ways to uncover requirement. The fact that you say that you are ‘gathering’ requirement does in no shape or form imply that you should not use any of these tools and techniques.

Or as another person pointed out to me, if you say you will ‘gather’ requirements your stakeholders will not respect you as they will think that you not be able to uncover what they really want/need/should have. Seriously? Business analysts are now taught that you garner respect by using fancy words and not by doing a good job and adding value?

And Your Problem is?

Lets start with the most basic issue. If I have to convince you to stop using ‘Gather’ and start using ‘Elicitation’ just because the one implies something else then you SHOULD NOT be a business analyst. If I ask you, a business analyst, to gather requirement and you do a bad job it is not because of the word ‘gather’ but because you do not know how to use the tools and techniques available. So that is the first problem.

Then, to imply that your stakeholders will respect you for using the word ‘Elicit’ instead of ‘Gather’ is very shallow and a total disregard for the intelligence of your stakeholders. Respect is earned by what you do, by the value you add, and not by you absolute command over the English language (which btw is good when you are creating documentation). If you ever use a word, phrase or terminology that does not inspire confidence with your stakeholder you can adopt what ever they feel comfortable with or explain where you are going with it. But I have never EVER in my decades of project work been disrespected or confronted by a stakeholder because I was going to ‘Gather’ instead of ‘Elicit’. Just as a sidenote – one of the things you as a business analyst should be doing is to make sure that your stakeholders understand your way of work. They need to understand that you might be shadowing them, or interviewing them or send out questionnaires. That in itself should inspire confidence that you do have a structured approach to getting information from them, something a single word will never do.

Just Get On With It Already!

Let me say again, I have NO issues with whatever language you feel comfortable with. I have a huge issue with statements such as ‘I cringe every time somebody says ….‘ or ‘It is time we change …‘ when it does not detract from the value added if ‘somebody says …‘ or it won’t add value when ‘we change ….‘. The classic vegetable vs fruit argument of the tomato comes to mind. By the time we reach puberty we all know that botanically a tomato is a fruit and not a vegetable YET when we look at a basket filled with fruit vs one filled with vegetables you will NEVER find tomatoes in the fruit basket. Does it detract from the value it adds in a salad or a sauce? NO it does not.

Instead of wasting time trying to convince junior BAs that they much use this language and not that, it is time much better spend in making sure that the tools used to [fill in you preference] requirements are understood and used correctly, then it does not matter if you call it a fruit or a vegetable. The outcome lies in the correct use and not the name. Use whatever make sense, as long as it contributes to adding value.

One Option Does Not Fit All

And this principle applies to everything. Wondering what methodology you should use, what ceremonies you must have, what output you must produce? The biggest mistake we can possibly make is to go by the book because we are told we have to. Use whatever adds value. If it is textbook framework X then great, if not then that is great as well. Over time text books, manuals, and BOKs change how they describe certain things and this includes the use of different language. That is good but, except if there is an errata, it does not mean that it was previously wrong. In many cases it is done for the sake of clarity and to make sure that we do not rely on the now almost extinct common sense gene. The leaflet you got with your bottle of battery acid warning you not to drink it is not more correct than the one we used to get without the warning. It just means that we cannot assume a certain level of intelligence, something I’d hope we can do for a qualified Business Analyst.

We seem to forget that whatever we put on a screen, card, form, or whatever we choose to expose our data with, creates an expectation with the end-user. “Whatever we put” means messages, field labels, or any other text and graphic we choose to communicate something.

It is something I come across on an almost daily basis, apps or websites using words that create an expectation of what I can or must, or should do. This past weekend I wanted to make changes to the notifications I receive from my bank (ABSA) when transactions take place. Parameters that can be configured include delivery method i.e. SMS or eMail, and transaction type i.e. current, savings, etc.

Great functionality but so badly implemented that it boggles the mind. The purpose of these notifications is to notify the account holder when there is activity on an account and contains no confidential information that might breach the security layer i.e. even if I receive a notification from an account not owned by me I cannot use any of the information in the notification to access the account.

Issues

ABSA made two very important mistakes when they designed and implemented this functionality.

a) They used bad terminology on their website. The use of ‘Manage recipients‘ creates the expectation that I can in fact manage the notification for a specific recipient. This is in fact not so. None of the parameters for this function can be managed by the end-user and this is a very bad interface design

b) They chose not to provide the functionality so that the end-user can make changes at their own convenience and any change must be done via the support line, which is a bad implementation in itself. The reason why they do this is unclear since, as mentioned previously, the notifications do not breach anything, be it security or confidentiality. This implementation makes a joke of the user journey and takes it from something that could take less than a minute to do to a process of over 30 minutes.

Resolution

The resolution for this is so simple it is actually painful to type.

• Use terminology that make sense and creates the right expectation. Repeat after me ‘terminology is important’.
• Understand the user journey and where their pain points are. Focus on aleviation those pain points. Making a process longer that it should be does not aleviate anything.
• Remove complexity from the end-user and take it upon yourself i.e. move complexity to the backend where the end used does not have to deal with it. Just removing complexity al together often means the oppisite, you move the complexity onto the end-user so that you do not have to deal with it. That is like stealing pension money from a pensionare.