Demystifying Business Analysis

It’s a truth universally acknowledged that everyone thinks their job is important: it’s tricky, it takes some skill, and everybody else in the organisation under-appreciates how complex it can be and the effort you have to put into it. And to some extent, I think this is true. I have my fair share of heated discussions with Project Managers and Developers and Testers and sometimes come away thinking “gah, they just don’t get it”. By the same score, I’m guilty of coming away and thinking “why is that so difficult, can’t they just do it like this?” Ultimately, though, I appreciate that everyone has a role to play on a project and each role is equally as critical. And I’m not really one for mystifying what I do or trying to keep knowledge to myself to make it all seem more impressive than it actually is. Whisper it if you have to, but there’s no secret art to Business Analysis. It’s actually quite straightforward once you know how to do it. Of course, the skill comes in on how well you do it, but let’s try and break it down a bit.

The Importance of Logic

I can’t stress this enough: logic is king. In everything you do. It’s all there really is to be honest. 99.9% of the tasks and problems you face as a BA are resolvable by logic. BA training courses dress it up in dozens of different ways - the five whys; the fishbone diagram; the Boston Box etc. etc. - it’s all logic. Logical thought, logical steps, and logical outcomes. If it’s not logical, it’s useless to you. If it is, then it will lead to an answer, or a set of further questions that will then lead to an answer.

I’ll try and demonstrate this via some of the key tasks and deliverables a BA will typically be asked to perform and produce. Let’s start with a nice general one, a process map.

Processes

Everyone can write a process diagram right? Put some boxes down, stick some words in them and join them up with arrows. Done. Done? Well, there’s a little more to it than that, but essentially, yeah, that’s the foundation of it. To get a good process document, however, you should be using a logical method. Person A gets hold of something, an input, let’s say it’s a customer letter. They do something with this input, let’s say they change the customer’s address on their customer database. They pass the letter to the accounts team because they have to make the change on a different database. So person B takes the letter, makes the change, and then passes the letter to person C who files it in a big filing cabinet. Simple process. Probably a bit out of date now, this was the kind of thing that happened in the 90’s before systems got a little more sophisticated, but it’s an easy example which is why I picked it.

Is that the process? Is that all there is to it? Because logically there are things that can go wrong there. What happens if the address the customer has given is missing the postcode or has the wrong postcode and person A can’t update their system, they get blocked from doing it by that system’s address validation? There should be an alternative process path which shows how person A would contact the customer to get the missing information and then return to the main process path of updating the customer database and everything that follows. What if they gave the correct postcode but the house is on a new estate, just built, and the address validation of your customer database hasn’t caught up yet? You can go and confirm with the customer as above, but that doesn’t resolve the problem, so you’d need a different alternative process path which enables you to override the postcode validation somehow and record the correct address regardless of the constraints of your system. And what if the address the customer is advising you to change their record from is not the address you currently have recorded? Does that require some other verification check that they are who they say they are, or do you just accept it?

At this point, you might ask if it’s possible for the customer to have two addresses on your systems, one for correspondence on the customer database, and a different one for invoices and payments on the accounts system. If so, how should the process differ if their letter is to advise a change to just one of these two addresses? And finally, what happens if the request is for some outlandish third address? Is there a default exception handling process step for things that just need someone to make a manual decision on?

You know what, even I’m getting bored with this example now, but you get the point. Working out all the possible permutations for the process is just the application of logic. For every step that should happen there is at least one or more alternatives - things that can go wrong or just aren’t there. Some analysts call this ‘what if’ analysis, some call it happy path and alternative paths, some call the exceptions ‘edge-cases’. They’re all the same thing. What should happen and what can happen instead. These are the kind of things a BA should be asking about for any process they help map out. There is no such thing as a simple happy path in which nothing will ever go wrong. Your job is to try and tease out the possible variations and cater for them in the process flow, even if catering for them is a process step which says “we stick all these ones in the bin and forget about them”. Sometimes unforeseen variations will occur, and there’s not much you can do about these except go back and cater for them in your process once they’re known, but in theory, because of the logical way you inverted every positive process step with one or more negatives, you should get close to covering off all eventualities.

Functionality

I’ll give a slightly different type of scenario for the use of logic in functional work. To mix it up a bit. I’ve said before that a BA’s job is not to just write down what people tell them. It is not to just accept, at face value, how someone thinks something should work, or does already work. It’s a BA’s job, in my opinion, to also find out if that’s true. I couldn’t tell you how many times in my career someone has told me an existing system works in a particular way only for me to find that that is not how it works at all, and that the difference is actually quite fundamental and changes everything about the requirement and the solution the project needed to provide. But how do we go about validating these things? We’re not developers, we shouldn’t be able to read code (although I’ll come onto why that isn’t strictly true later). Well, as you might imagine, there is a logical way to do this.

At an abstract level, a system only comprises three things: a front end of some sort (a user interface usually); a back-end, typically a database with tables you can look at and records you can see; and a processing bit in the middle which moves data around and transforms it. If you can look at the front end, which usually anyone can, and you can get a DBA or a BI Analyst to give you access to the back end, then anything that happens between the two is derivable. It’s just like working with an equation in maths. Try not to go into GCSE maths paper panic mode, but imagine you start with the number 10 entered on the front end, something happens to it, and it ends up in the database recorded as the number 12. Hmm, looks like that ‘something’ in the middle just adds 2. Let’s try it again by starting with the number 20. By the time it hits the database, this has become 24. Ok, so it’s not just having 2 added to it then. Let’s input 15, because I have a hunch, and yeah, that comes out as 18. That’s what’s happening: the transformation bit in the middle is adding 20% onto your initial figure. You can see it. You can work it out by spotting and then validating the pattern. Is that because, maybe, VAT is set at 20%? You can go and check that with your stakeholders, and then one of them usually says “oh yeah, I’d forgotten about that, we always apply the current rate of VAT to stuff as well. But only in certain instances, where the record type is x”. And then you’ve uncovered some other complexity in your requirement that was otherwise hidden.

Some BAs disagree with me, but it’s my opinion that a decent Business Analyst should have at least a basic knowledge of databases and how to interrogate them. By that, I mean typically, can write a bit of SQL. Not advanced SQL - unless you have a data specialism there’s no need to know how to optimise complex SQL statements and utilise nested sub-selects - but at least an ability to Select * from something, maybe chuck in a table join or two, add a filter statement to whittle down your result to something manageable. And the reason I believe this is precisely so you can do what I’ve just described above. There are other ways of doing it, sure, like getting some data extracts and working with them in Excel. But I find that usually takes longer and isn’t as reliable a way to spot the patterns you’re looking for. In any case, SQL works as an application of logical statements. It’s another tool which enhances the logical way a BA should be working anyway, and it really isn’t that hard to grasp the basics of it.

In any case, functional problems are resolvable by the application of logic. Similarly, functional requirements should be expressed in terms of logical rules. I used to write a lot of field level validation rules for websites, and they were actually really similar to the process logic I explained above. “Enter Surname”. 1. If blank, return the error message “please enter your surname”. 2. If it contains anything that is not an alphabetical letter or an apostrophe or a hyphen, return the error message “please use only alphabetical characters with a maximum of one apostrophe or one hyphen” (to cover the O’Learys and Saxe-Coburgs of this world etc.). 3. If it contains only lower case characters, return the error message “please use sentence case and start your surname with a capital letter”. 4. If it contains all upper case characters, return the error message “please use sentence case, do not enter your entire surname in capital letters”. 5. If it is less than two characters long, return the error message “surnames must be two or more characters long”. It’s all about thinking through the possible scenarios for someone entering a value and trying to handle them all.

(And yes, there will be the odd person who has changed their name by deed poll to ‘Splendour’ and officially now has no surname, but there comes a point where you have to accept the edge cases that you’re not going to bother handling because they’re more effort than they’re worth. Splendour just won’t be able to use your website. Tough, they’ll just have to deal with it).

Code

Now this is the contentious bit. Developers won’t like me one bit for saying this, but code is just logic. It’s logic that is expressed in different ways, different styles of syntax depending on the language used. And I don’t profess for one second to be an expert in even one of those languages. Yet, in my career, I have read code and pointed out to developers the problem in their logic on more than one occasion. How did I do that? Well, because it isn’t that hard is the answer.

I said above, a system can be abstracted into three things: front end, back end, processing bit in the middle. A piece of code can also be abstracted. All coded functions, pretty much, boil down to the following: If A is true, then do this, If B is true, then do that, otherwise do the third thing. Obviously, I’m simplifying, and the true complexity of code comes into play really in the ‘things’, what it is supposed to do if A or B are true or not. But as an Analyst, they don’t really concern me. It’s the logic, the scenarios, that do. And they are easy to read because they all have some variation of IF paired with them.

I had one stakeholder tell me that their database wasn’t working properly. When they changed one of the dates against a customer record it didn’t save the change. I spoke to the development team, they told me that was impossible because the function was sound. I went back and asked the stakeholder to check again. They insisted it wasn’t working properly. I went back to the developers, they told me it was impossible. This went on for weeks. In the end, I went onto a test version of the system and recorded every possible permutation of date changes you could do on that page for a customer. And lo and behold, for one of them, and it was only one of them, it didn’t work, just as the stakeholder had told me. I showed the developers my test cases. They checked the code again. They told me it looked sound.

I had to ask a different developer, one who owed me a favour, to secretly print out the code for me. I promised I’d never breathe a word about where I got it. And then I went through the IF statements there and mapped them out on a piece of paper as scenarios. And, fancy that, there was a clause missing in the logic. For that particular combination of taking out one date and inserting another one, the logic statement didn’t cater for it. It had already decided what to do when the first date was removed, so exited and saved what was there before the new date was added. I went back to the developers and showed them. They didn’t believe me. I showed them again. They were dubious. I explained it a third time and they had to concede that actually, yes, I was right. Stupid BA with his stupid insistence on backing up the stakeholder (mutter mutter mutter)…

Ok, that was a particularly happy day for me, but I’m not writing about my experiences as a BA to somehow prove how great I am. None of these examples prove anything about me. They prove the points I’m trying to make: in this case that a grasp of logic is all you actually need to be able to do a ton of things successfully, as a Business Analyst or in IT generally.

To go back to where I started this post, we all like to maintain that our jobs are specialisms. Not just anyone could do them. And while that’s true, as in ‘not anyone could turn up one day off the street and just pick it up like that’, I don’t believe that any job is really unattainable for someone who wants to work hard at becoming proficient at it. I think Business Analysis requires a certain kind of skillset, a certain type of personality, it doesn’t suit everybody, but that’s not because the things you do are fiendishly difficult. It’s more because you have to wade through some pretty tedious stuff at times, and you have to be persistent, and you need to retain a keen eye for detail. You have to follow where the logic leads you even when, if we’re being totally honest about it, you just can’t really be bothered. And it’s a thankless task at times: the things you miss become the things the project misses and can result in more work for someone else who will then almost certainly blame you for it. But it’s an interesting job most of the time, it’ll keep you from wandering the streets, and if you remember that 99.9% of it is achievable by detaching yourself and just working systemically through things step by step, you know what, you’ll probably do alright.