With only 38 days left before The International Institute of Business Analysis (IIBA®) sunsets the CBAP® (Certified Business Analysis Professional) exam for the Business Analysis Book of Knowledge® (BABOK®) 1.6, the curiosity of what the BABOK® 2.0 offers is driving a massive number of business analysts to seek out any study guides (study group, self directed or other materials) to take a pick at the content of the exam. Unfortunately, of all these business analysts, only a few really qualify to sit for the exam. If you have considered joining the rush to become a CBAP®, here are a few things you should know:
What is CBAP® Certification?
If you take a look at today's job market in the IT field, you will see that the demand for Business Analyst is astronomical!!! And as Katherine Walsh commented in her article: "Hot Jobs: Business Analyst", business analysis has finally being recognized as a separate role in the organization and most IT folks, are being more and more interested in it. But how do you get in the field? How do you know if you are right for this role?
Business Analysis is defined as the role that liaise between the business, IT and almost always with the customers. Though requirements gathering is what most people think is the role of the BA, it is not limited to that area only. The International Institute of Business Analysis (IIBA®) has identified 6 Knowledge Areas that can be and should be performed by the Business Analyst. These Knowledge Areas (KA) are:
1. Business Planning and Monitoring
3. Requirement Management and Communication
4. Requirements Analysis
5. Enterprise Analysis
6. Solution Assessment & Validation
Now, to become a business analyst doesn't mean you have to absolutely have experience in all these KAs. But it wouldn't hurt to acquire the knowledge and help an organization by providing recommendations to certain business problems. For example, if an organization has a problem of buying new software and shelving them after a period of time, then you may recommend that they do certain parts of an Enterprise Analysis to become more aware of the enterprise activities (business processes) then go through requirement elicitation to understand the requirements of the business and only then purchase or implement a system that will support their business need.
A Business Analyst who is not familiar with the 6 KAs may jump on the bandwagon of I call the "backward analysis" where the system requirements are identified before the business requirements and sometimes without even looking at them.
In order to get into this field, you may have to ask yourself some serious questions and be very honest at answering them. The reason being that though you can learn the hard skills (UML, Use Cases, ERD.. etc), the soft skills are what will give you leverage in getting in this field. Anyone can learn but not everyone is good at applying what they learned. I don't want to discourage anyone out there but it's is good to understand where you are so that you develop the skills that are missing.
Here are somethings to think about:
Are you the kind of person who understand business and IT without mixing the two or be biased on one side?
Do you know how to make people come to a consensus?
Do you have patience to listen to someone explain what they do?
Do you like or feel comfortable with asking more questions to get more details? even if the questions seem "unintelligent"?
Do you like to make people feel comfortable around you and do you know how? see why this is important in my comment
Do you like to speak in front of people?
Do you like to research and keep up with technology and business issues?
These are some questions to ask yourself to know if you can be good for this field. Once you have the basic soft skills, learn the hard skills by taking courses.
If you are currently working at a company that doesn't have BA positions, this is a great opportunity for you to create this position by educating your boss and showing him/her how your skills can improve the efficiency of the organization.
If your organization already has these positions, I suggest that you ask one of the BA to mentor you and help you land a job as a BA or join an IIBA local chapter to get mentorship and network to find how you can get into a BA position.
Most of us, Business Analysts, are more familiar with gathering system requirements because they are more interesting to our organizations and customers than the user requirements. But user requirements are absolutely of equal importance if not more important that the system requirements. You may ask me why is that?
In this series of blogs, I am going to take you through understanding the importance of user requirements and how to gather them.
If the goal of your organization is to develop products that has a good reputation and requires less training and support in the backend (sells well, keeps customers happy, and produces referrals), your focus should be on the users of the product. The main reasons that drive customers away from products are:
Now what are user requirements?
According to the Business Analysis Body of Knowledge version 1.6 definition, "they are statements of the needs of a particular stakeholder or class of stakeholders. they describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. They serve as a bridge between business requirements and the various classes of solution requirements.
They must be collected in order to determine the direction of the product. There are various sources of user requirements.
Have you ever been in an elicitation meeting and the users refers to some functionality in your product and you have absolutely no idea what they are talking about? Well, this has happened to me a few times. I was thrown in with the high level description of the product but had never seen the real product because the organization had only the "in-development" products. And, as a débutante in business analysis, I really didn't know what I was doing most of the time. But I have learned my lesson since then.
That's why, I believe the first commandment to a Product BA, is to KNOW THY PRODUCT.
You may ask, but how do i do that?
Part of my job as a Business Analyst, it is my responsibility to facilitate business process analysis meetings with a group of very knowledgeable folks. As I stood in front of my audience, I couldn't stop thinking: "What if I don't understand what is going on here? What if I can't comprehend the issues at hand? What if i steer this group to an outcome that is completely irrelevant to the issues at hand?" I was hired in the public health industry at the time and prior to that, I worked in the gaming industry, healthcare, computer software and hardware.
So often Business Analysts or Project Managers have to face customers who have been promised the world when the organization can barely produce a tenth of that world. And most of the time, it is really hard to tell the customer "no, we don't do that" or "no, we can't do that". But this job has to be done. Having faced this issue many times, I wanted to share with you some tricks on how to say "no" without saying "no". This is not an easy task to do, especially if you face angry customers. The good thing, however, is that as a business analyst, I have learned that bringing the customer in the process is always a the key to success in every projects and with good facilitation, I have learned a way to negotiate with the customer that gives them the power to say "no" to themselves without you having to utter it.
Here is the trick: