A colleague of mine asked me recently what makes a good Business Analyst, and this stumped me for a while. I had a rare opportunity to go trout fly-fishing recently and as the fishing was slow I was able to contemplate this question. You will gather from this that the question had worried me as I seldom think about work stuff when I am fly-fishing.
So what does make a good Business Analyst?
I decided to go back to basics; if I want to know what makes a good Analyst then I need to ask what do we, as Business Analysts, do? If I could understand that, then I can start to understand what makes one Analyst better than another.
I asked around in business analysis circles for an on line description of what we do. Although I got a few different answers, I found I got the most consensuses with “a Business Analyst elicits, documents, and communicates business requirements”. But what does that mean?
Let us look at the definition of the word ‘elicit’:
e•lic•it –verb (used with object)
"to draw or bring out or forth; educe; evoke: to elicit the truth; to elicit a response with a question".
[Origin: 1635–45; < L élicitus drawn out (ptp. of élicere), equiv. to é- E- + lici- draw, lure + -tus ptp. suffix ]
http://dictionary.reference.com/
and
Etymology:
Latin elicitus, past participle of elicere, from e- + lacere to allure
Date:
1605
1 : to draw forth or bring out (something latent or potential) <hypnotism elicited his hidden fears>
2 : to call forth or draw out (as information or a response) <her remarks elicited cheers>
http://www.merriam-webster.com/dictionary/elicit
The common theme appears to be ‘to draw out’. So when we say the Business Analyst elicits requirements, this means the Business Analyst draws out the business requirements from the business. This I know to be a reflection of the truth because sometimes that drawing out is as painful as pulling teeth.
This was the catalyst I needed to be able to answer the burning question of what makes a good Business Analyst.
A good Business Analyst is a person who draws out or facilitates the process of documenting of requirements. In other words, the Business Analyst is someone who has a set of methods or tools that allows them to draw out the business requirements from the business users and then document them in a manner that is understandable to the business users. That understanding is critical as this ensures the business users are able to confirm the business requirements for correctness and completeness. The Business Analyst can then take these agreed requirements and, if necessary, translate them into a form that the technical team is able to understand and create a computer system from them. In this way, the system is able to deliver the functionality the business user needs to solve a business problem.
Now we understand what a Business Analyst does, but what makes a good Business Analyst?
First, let’s look at the concept of facilitating the requirements process. The first important concept to understand is the requirements belong to the business user and the Analyst is drawing them out.
Here is where the practice of a good Business Analyst varies from the not so good Analyst.
A good Analyst facilitates a correct and full set of requirements but ensures the business users retain ownership. Nothing is added to the requirement that did not come from the business users. Even if the Analyst can see a hole in the requirement, the Analyst will direct the users in finding the requirements that will fill the hole. Whereas not so good Analysts will see themselves as having to create a full and complete set of requirements and will often fill in the blanks based on their own knowledge. As soon as this happens, the requirements belong to the Analysts and not the business users.
How many times do you see a job advert for a BA requiring business or domain knowledge? If the Business Analyst is skilled in drawing out the requirements from business then why is domain knowledge so important? Often this is because the business users are not used to a good Business Analyst who is skilled at drawing out their requirements in a manner that the users can confirm has actually been achieved. Often the Business Analyst has to fill in the gaps in the requirement because the elicitation processes are not working correctly.
There could be many reasons the elicitation process is not working properly:
- The Analyst lacks the correct training and skills
- Poor methods used to document the requirement (no one understands them)
- Users do not participate correctly in the process
- Users expect too much from the Analyst
- Analyst does not understand his/her role
- Business users do not understand the Analyst’s role
This list could go on, but the end result of the elicitation process not working correctly leads to one thing, ASSUMPTIONS! Assumptions such as:
- The user assumes the requirements are correct and complete
- The Analyst does not have enough access to the business users and assumes what a requirement is, based on their domain knowledge
- Technical team doesn’t understand the requirements, or the requirements are incomplete, so they will assume they know what the users want.
Now these assumptions often work out but sometimes they don’t and, when they don’t, my first law of bugs can be applied.
“An assumption made about requirements can be either right or wrong, so it will have at least a fifty percent chance of being incorrect. By implication, an incorrect assumption will result in an incorrect requirement and therefore there is at least a fifty percent chance it will result in a bug.”
Or as I like to say “assumption is the Mother of all Bugs”.
This percentage of error in creating bugs is unacceptable. So a good Business Analyst will create a correct, verified and complete set of requirements which will contain (as close to as humanly possible) zero assumptions.
Another source of bugs is a lack of understanding of the importance of business rules.
So, as before, let’s get the definitions right:
Main Entry: rule
Function: noun
Etymology: Middle English reule, from Anglo-French, from Latin regula straightedge, rule, from regere to keep straight, direct
Date: 13th century
1 a: a prescribed guide for conduct or action
3 a: the exercise of authority or control
From http://www.merriam-webster.com/dictionary/rule
If we contextualize this within the business rule, it can be seen as a prescribed guide for the conduct which allows the business to exercise control.
OK now, let’s look at the correlation between business rules and bugs.
Business rules are the checks and balances the business has developed in order for it to function correctly. Some business rules will be determined by law or governance in order for the business to operate within its chosen market. Yet another group will be so critical as to be the sequence of activities the business does for, or offers to, its customers that differentiate it from its competitors in the market place. Others are put in place as a protection mechanism; such as:
‘A customer cannot place any further orders with us if they have exceeded their credit limit with us.’
This business rule has been developed to ensure we can control or minimise the number of bad debts the business will have. The credit limit is a value that we feel is reasonable for the value of indebtedness we will allow for a given customer. If the final system does not enforce this simple rule then the entire financial future of the company may be put at risk.
When it is put into the system, it will need to be a conditional statement like this for example:
If (Cust-total-unpaid-purchases > Cust-credit-limit) Then ….. (the actions to be taken)
So if this was not in the requirements then it not going to appear in the program code. As soon as the business user finds it is not present in the system there will be a mad scramble to insert it, and get rid of the Bug.
Here is my second law of Bugs:
“If an Analyst misses a business rule or does not correctly define a business rule, it will result in a bug in the final system.”
It is as simple as that. So we can see how important the business rules are to the Analyst’s success of fully, correctly, and completely documenting the set of requirements.
We can see that it is not surprising, based on the above, the Standish Group's Annual Chaos Report indicates that three of the top five reasons for project failure are related to requirements. In addition to this, requirements can be blamed for a high percentage of rework required on systems.
So a good Business Analyst will create a correct, verified and complete set of requirements which will contain (as close to as humanly possible) zero assumptions, and complete means all business rules identified verified and defined.
So, to answer the question where did that bug come from? We know it can come from many places but assumptions and missing or ill-defined business rules are certainly the main culprits. If you, as the Analyst, get these two right, I know there will be a dramatic reduction in the number of bugs in the final system. This can have a very positive effect in the overall costs related to systems development and maintenance. It is accepted that a requirement, which was missed during analysis and which could have taken an hour to find and document, will take at least one hundred hours to find and fix if it is only discovered after the system is complete. So just imagine what the impact is if we reduce the missed or ill-defined requirements by just ten percent.
Author: Robin Grace, Principal Consultant BA Practice for IndigoCube in South Africa.
Robin has been involved with Businesses Analysis for nearly twenty years and has used a variety of Methodologies, Modelling techniques, and Tools. He is well known for his presentations on various aspects of Business Analysis.
Robin recently published a book titled “Aligning Business Analysis, Assessing Business Analysis from a Results Focus”.