At the eve of Thanksgiving here in the USA, as you look outside you can see and smell the changing season. Trees have become empty and brown here in Georgia. Yet, at some other parts of the country, they are covered with snow. And yet again, in Australia, little buds are filling the branches and the green trees are attracting all sorts of birds. As you know, change always brings something or takes something away. This change, as part of our daily lives and routine, can be either envigorating or devastating. At the eve of all the festivities, ExpertMentors and Center4BA, have decided to join hands. We believe that with both of our strenghts we can better paint a bigger picture of the Business Analysis World. Our goal is to create a new season with this change and providing you with an envigorating experience. During this new season, we are committing to provide our members with business analysis tools, techniques, stories, experiences, and ideas used in a variety of industries.
My name is Linda Erzah and together with John Vu, we are expanding on our passion for mentoring other Business Analysts as they flourish to their full potential.
Please stay tuned to our blog.
Monday, November 26, 2007
Friday, August 17, 2007
Business Analyst: The Neutral Convener
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. I started out the meeting with the objectives and outcomes of the meeting and proceeded to asking them a high level question: "What is the objective for Activity #1" (We had already brainstormed on the various activies performed in the public health arena); which started a discussion in the room full of PhDs, Directors, and a few MPh. As I listened, it started to become clear to me what were the issues... Questions started forming in my head, I wanted to know more and dig more into what they were saying. I wanted to understand what this person meant by one thing and if that understanding was similar with others. I wanted to know what the accronyms spelled out and I wanted to know more...
They each had different knowledge and sometimes they called the same report with different names.
When they first arrived in the room, each person knew that they were in this group to bring out the commonalities of their business processes and work toward developing common set of requirements for future systems. But each had different knowledge and experiences (or at least they thought it was very different and very complicated than those of their counterparts)So each one came with their own understanding, definitions, accronyms, knowledge.. etc.
As their Business Analyst, I had confidence that I could lead them to a common understanding but how was I going to do that, not having a background in the public health? Let's talk about the difference between the vertical and neutral convener BA.
Have you ever heard of a vertical Business Analyst? This new term describes a Business Analyst who has specialized in one industry and has a solid background and understanding in the industry. Most recruiters, hiring managers and others have this concept that a good BA is the one that has specialized in a particular industry. The BA are being strongly encouraged to stick to a particular industry in order to become well acquainted with its culture, language, processes.. etc. Not having the please to stick to one industry, I can only speak of the benefits of the neutral convener role that the Business Analyst must play in defining, analyzing and modeling the business and/or requirements.
A neutral convener Business Analyst is defined as one who has no bias or stake in a particular subject or issue at hand. This person does not benefit from the outcome of a project or meeting. Their job is to guide, motivate, build a bridge, bring peace, listen, elicit information, and lead discussion to a desired outcome. This outcome can be based on a methodology or can be defined by the owner of the project or meeting.
With this definition at hand, the BA who is a neutral convener:
1. will help elicit full and candid information from stakeholders
2. will make participants feel free to be more candid with someone who has no vested interest in the project.
3. will maintain confidentiality, if a stakeholder requests it, while still integrating the stakeholder’s views into the recommendations.
4. will define, analyse and model a process based on complete and accurate information, strengthening the conditions for constructive dialogue.
5. will be effective in engaging diverse stakeholder groups and organizing constructive dialogue and negotiation processes. This can help provide an effective vehicle for subsequent discussions on the substantive elements of your project.
There are many other benefits to having a Business Analyst as a neutral conevener. Since some of the outputs of business analysis can be used as input to other processes such as training new hire, a BA with industry bias, will have difficulties relating to those who do not understand the industry, its culture, language and standards.
I still don't know what the benefits of being a vertical BA are. I challenge those in this position to comment on this blog and let us know the benefits of this direction.
They each had different knowledge and sometimes they called the same report with different names.
When they first arrived in the room, each person knew that they were in this group to bring out the commonalities of their business processes and work toward developing common set of requirements for future systems. But each had different knowledge and experiences (or at least they thought it was very different and very complicated than those of their counterparts)So each one came with their own understanding, definitions, accronyms, knowledge.. etc.
As their Business Analyst, I had confidence that I could lead them to a common understanding but how was I going to do that, not having a background in the public health? Let's talk about the difference between the vertical and neutral convener BA.
Have you ever heard of a vertical Business Analyst? This new term describes a Business Analyst who has specialized in one industry and has a solid background and understanding in the industry. Most recruiters, hiring managers and others have this concept that a good BA is the one that has specialized in a particular industry. The BA are being strongly encouraged to stick to a particular industry in order to become well acquainted with its culture, language, processes.. etc. Not having the please to stick to one industry, I can only speak of the benefits of the neutral convener role that the Business Analyst must play in defining, analyzing and modeling the business and/or requirements.
A neutral convener Business Analyst is defined as one who has no bias or stake in a particular subject or issue at hand. This person does not benefit from the outcome of a project or meeting. Their job is to guide, motivate, build a bridge, bring peace, listen, elicit information, and lead discussion to a desired outcome. This outcome can be based on a methodology or can be defined by the owner of the project or meeting.
With this definition at hand, the BA who is a neutral convener:
1. will help elicit full and candid information from stakeholders
2. will make participants feel free to be more candid with someone who has no vested interest in the project.
3. will maintain confidentiality, if a stakeholder requests it, while still integrating the stakeholder’s views into the recommendations.
4. will define, analyse and model a process based on complete and accurate information, strengthening the conditions for constructive dialogue.
5. will be effective in engaging diverse stakeholder groups and organizing constructive dialogue and negotiation processes. This can help provide an effective vehicle for subsequent discussions on the substantive elements of your project.
There are many other benefits to having a Business Analyst as a neutral conevener. Since some of the outputs of business analysis can be used as input to other processes such as training new hire, a BA with industry bias, will have difficulties relating to those who do not understand the industry, its culture, language and standards.
I still don't know what the benefits of being a vertical BA are. I challenge those in this position to comment on this blog and let us know the benefits of this direction.
Tuesday, August 14, 2007
Gathering User Requirements - Part 5: Create User Scenarios
Call it Use Case, Scenarios, User Stories...etc depending on the methodoly used by your organization, you have to create some kind of scenarios. When getting to know your product, you should have some high level scenarios developed with the help of other department.
Don't forget, that this is an iterative process. You may develop some high level scenarios and then refine them as you are learning more.
Scenarios are stories about the personas you just created. These stories describes how each personas would complete their jobs. There is a lot involved in creating scenarios. The things to consider are:
Going through this exercise will help you with identifying some desired features (this is not the same as system requirements). Build scenarios for each persona until you have covered all the functionality of your product. If you uncover other functionalities during this exercise, then you have some elements of your gap analysis between what is and what is desired. During this exercise however avoid talking about the system. Don't say or write things like: "Jane selects her courses from the combo list and then clicks the submit button". At this point your are focusing on what Jane does if the system didn't exist or wasn't build the way it is. The best way to correct this sentence would be: "Jane selects all her desired courses and submits this information to the admistration department"
Now, to solidify your scenarios, you will have to have some contact with your users. You can't just use creativity for everything. You must validate what you just wrote or assumed about the users, their personas and their scenarios.
There are many templates out there depending on your methodology. Make sure you understand how to build your scenario and don't get caught in analysis paralysis as Barbara Carkenord from B2TTraining advise in her blog: We NEED Project Managers!
Don't forget, that this is an iterative process. You may develop some high level scenarios and then refine them as you are learning more.
Scenarios are stories about the personas you just created. These stories describes how each personas would complete their jobs. There is a lot involved in creating scenarios. The things to consider are:
- Critical task or situation
- User's desired outcome for the task
- Task flow- how the user goes through the task
- Time interval
- features or functionality that the user will need or will be using
- Exceptions - the rare events and their frequencies
Going through this exercise will help you with identifying some desired features (this is not the same as system requirements). Build scenarios for each persona until you have covered all the functionality of your product. If you uncover other functionalities during this exercise, then you have some elements of your gap analysis between what is and what is desired. During this exercise however avoid talking about the system. Don't say or write things like: "Jane selects her courses from the combo list and then clicks the submit button". At this point your are focusing on what Jane does if the system didn't exist or wasn't build the way it is. The best way to correct this sentence would be: "Jane selects all her desired courses and submits this information to the admistration department"
Now, to solidify your scenarios, you will have to have some contact with your users. You can't just use creativity for everything. You must validate what you just wrote or assumed about the users, their personas and their scenarios.
There are many templates out there depending on your methodology. Make sure you understand how to build your scenario and don't get caught in analysis paralysis as Barbara Carkenord from B2TTraining advise in her blog: We NEED Project Managers!
Monday, August 13, 2007
Gathering User Requirements - Part 4: Know Thy Users
I wanted to expand a little bit more on your notion of users. In Part 2, I mentioned that there are group of users from which you can get great requirements about product. But as a Business Analyst, I don't want you to be leave you hanging at the high levels, so let's dig a bit deeper on this subject. Many of us Business Analyst fail to recognize the users of the products or services offered by an organization. We are more interested in our high level stakeholder that we don't spend much time with the user. Yes, this is the job of a usability analyst but why shouldn't we get more familiar with their approach?
Prior to choosing your methods, even the BABOK recognizes that we need to determine the requirement elicitation stakeholders (BABOK vs. 1.6). Well, yes, there are the stakeholders of the project and there are also those who will use the end product of the project: The Mud on the boot folks! Most of the time, we fail to bring them in the picture and if a Business Analyst wants to be successful at gathering the user requirements, they must make sure they consider this group.
That said, how do you go about getting to know your users?
1. Create a User Profile
How do you know who are your users? Depending on industries, your users may be fixed or may be spread. For example, if you are going to develop requirement for a software that will go on a cell phone, you will have a variety of users, older folks who may have some challenges picking up on the technology, the young folks who will try to break the features, and the busy middle aged users who may feel that it's a waste of money to have more features and higher price.
And there are your other organization whose users will remain fixed, such as software developed for children learning computers. You will have a fixed group mostly!
A user profile is a detailed description of the users' attributes (experience level, age range, education, job title or role, work hours, user category...etc)
You and go in as much detail as you want! There are so many usability books that go into detail about this.
The user profile is a great help with scoping the issues you want to deal with as well. If you don't think you want to deal with the issues of technology challenged users because you believe they represent a small group of your users then you have part of your scope statement right there :). It can also give you the availability of your users if you wanted to perform job shadowing ... etc
If you hade a big amount of data and you didn't know how to go about figuring it out the characteristic of your users, use the affinity diagram to sort and organize your data.
2. Build Personas
Now that you have a generic idea of who your users are, now it's time to get more specific. This is where I believe business analysis become an art and requires some imagination.
A persona is the details about a typical user within your user profile. Think about your user profile as a class or envelop of a set of humans - let's say teachers. Now your persona is the description of a teacher who could be female, 24 years old and single with a degree in Information Technology (instead of teaching).
So all the fields you used for your user profile, you will use them here too.
Personas give you a good sense of reality. Let's say you are in a meeting and you described the above teacher as Jane. Now, if I was to build a software for curriculum planning for teachers, I would say that Jane would need some instructions on how to build a curriculum where may be another persona, Ellen, who had gone through the teaching progam, may not need this feature. And a little secret on our scope again, if you have more Ellens than Jane, guess what? your stakeholders may decide that Janes may just get some manual training and this feature is not needed. Yes you got it, you have just reduced your scope future or you found you some good data to help negotiation if your stakeholders are pushing for all functionality with a fixed budget!
Once you have all this information, now you are ready to begin some conversation with your users to perform you following step: Gathering Requirement: Part 5: Create User Scenario
Prior to choosing your methods, even the BABOK recognizes that we need to determine the requirement elicitation stakeholders (BABOK vs. 1.6). Well, yes, there are the stakeholders of the project and there are also those who will use the end product of the project: The Mud on the boot folks! Most of the time, we fail to bring them in the picture and if a Business Analyst wants to be successful at gathering the user requirements, they must make sure they consider this group.
That said, how do you go about getting to know your users?
1. Create a User Profile
How do you know who are your users? Depending on industries, your users may be fixed or may be spread. For example, if you are going to develop requirement for a software that will go on a cell phone, you will have a variety of users, older folks who may have some challenges picking up on the technology, the young folks who will try to break the features, and the busy middle aged users who may feel that it's a waste of money to have more features and higher price.
And there are your other organization whose users will remain fixed, such as software developed for children learning computers. You will have a fixed group mostly!
A user profile is a detailed description of the users' attributes (experience level, age range, education, job title or role, work hours, user category...etc)
You and go in as much detail as you want! There are so many usability books that go into detail about this.
The user profile is a great help with scoping the issues you want to deal with as well. If you don't think you want to deal with the issues of technology challenged users because you believe they represent a small group of your users then you have part of your scope statement right there :). It can also give you the availability of your users if you wanted to perform job shadowing ... etc
If you hade a big amount of data and you didn't know how to go about figuring it out the characteristic of your users, use the affinity diagram to sort and organize your data.
2. Build Personas
Now that you have a generic idea of who your users are, now it's time to get more specific. This is where I believe business analysis become an art and requires some imagination.
A persona is the details about a typical user within your user profile. Think about your user profile as a class or envelop of a set of humans - let's say teachers. Now your persona is the description of a teacher who could be female, 24 years old and single with a degree in Information Technology (instead of teaching).
So all the fields you used for your user profile, you will use them here too.
Personas give you a good sense of reality. Let's say you are in a meeting and you described the above teacher as Jane. Now, if I was to build a software for curriculum planning for teachers, I would say that Jane would need some instructions on how to build a curriculum where may be another persona, Ellen, who had gone through the teaching progam, may not need this feature. And a little secret on our scope again, if you have more Ellens than Jane, guess what? your stakeholders may decide that Janes may just get some manual training and this feature is not needed. Yes you got it, you have just reduced your scope future or you found you some good data to help negotiation if your stakeholders are pushing for all functionality with a fixed budget!
Once you have all this information, now you are ready to begin some conversation with your users to perform you following step: Gathering Requirement: Part 5: Create User Scenario
Gathering User Requirements - Part 3: Know Thy Product
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 debutante 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? First of all, following on our BABOK bible, during your Requirement Planning and Management and while you are defining the business analyst work division strategy, make sure you use knowledge transfer and allow for some time for studying the product. This can be done between QA and BA or Development Team and BA. If the product is well documented (which I have rarely find) then use the document analysis technique from the BABOK.
Other things you can do to familiarize yourself with the product is:
1. Use it
This can be a bit hard if you don't have any documented personas or scenarios. I recommend that you talk with you start making friends with your QA department. They should have some test cases or can verbally tell you how they go through testing the product, which will give you allow you to understand the kind of users you will be dealing with and the functionalities being tested.
2. Look at competitors
If this is a brand new product and you have an idea who your competitors are, start studying their product. You will learn about the users of their product, understand its use and gain good strategy on how to lead the conversation with your users. You don't want to not have some type of knowledge. Your competitor may have a better documentation than your organization on an existing product as well.
3. Talk to marketing
Marketing department may have competitive analysis data or data from focus groups; which will you give you an idea of what users desires are (NOT requirements)and the perception of the product. You can also discover what the marketing people are presenting to the customers, what vision of the product they are selling.
4. Check the status tracking or log file if existing
If you have been assigned to a maintenance project for an existing product, and if there are logs on the use of the product, this is a great place to get user paths and even some scenarios. Once you get this information, you can go back to using the product and learn more about it by following your users.
And of course, going back to our first lesson, don't forget your "Fixer Uppers" and you "Wind Stoppers". Check with them to see what they know of the product and the functionalities used by the users.
Once you know your product, now it's time to get to know your users: Gathering User Requirements: Part 4: Know Thy Users
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? First of all, following on our BABOK bible, during your Requirement Planning and Management and while you are defining the business analyst work division strategy, make sure you use knowledge transfer and allow for some time for studying the product. This can be done between QA and BA or Development Team and BA. If the product is well documented (which I have rarely find) then use the document analysis technique from the BABOK.
Other things you can do to familiarize yourself with the product is:
1. Use it
This can be a bit hard if you don't have any documented personas or scenarios. I recommend that you talk with you start making friends with your QA department. They should have some test cases or can verbally tell you how they go through testing the product, which will give you allow you to understand the kind of users you will be dealing with and the functionalities being tested.
2. Look at competitors
If this is a brand new product and you have an idea who your competitors are, start studying their product. You will learn about the users of their product, understand its use and gain good strategy on how to lead the conversation with your users. You don't want to not have some type of knowledge. Your competitor may have a better documentation than your organization on an existing product as well.
3. Talk to marketing
Marketing department may have competitive analysis data or data from focus groups; which will you give you an idea of what users desires are (NOT requirements)and the perception of the product. You can also discover what the marketing people are presenting to the customers, what vision of the product they are selling.
4. Check the status tracking or log file if existing
If you have been assigned to a maintenance project for an existing product, and if there are logs on the use of the product, this is a great place to get user paths and even some scenarios. Once you get this information, you can go back to using the product and learn more about it by following your users.
And of course, going back to our first lesson, don't forget your "Fixer Uppers" and you "Wind Stoppers". Check with them to see what they know of the product and the functionalities used by the users.
Once you know your product, now it's time to get to know your users: Gathering User Requirements: Part 4: Know Thy Users
Saturday, August 11, 2007
Gathering User Requirements - Part 2: What are User Requirements?
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. And I may not be able to list of all them for you advanced users. But for our Jr. BA or those who have very little experience gathering user requirements, these are the folks that you should consider when planning for the collection of user requirements:
"Mud on the boot" users: these are the front line users. They will be using your product on a daily basis. A frustrated "mud on the boot" user can be like a virus. They like to vent or complain about their products. They will tell you how they do their jobs, and how they would like to see things improved. They may also have some level of competition among each other so if your product allows them to perform their activity effeciently, they will rave about it.
The "Wind Stoppers": they perform the middle man role. They deal with the "mud on the boot" users on the daily basis and know the pains and successes of those users. They provide assistance, run reports, and overal understand to some degree the needs of the the "mud on the boot" users. If your organization sells directly to the "mud on the boot" population, your "wind stoppers" will be internally, such as customer service, call center, sales department, training department... etc.
and finally the "Fixer Uppers": if anyone can give you what the users have difficulties with, the "fixer upper" is the person to talk to. Once the "wind stoppers" intercept the issues on the field, the "fixer uppers" are deployed to patch things up and allow the "mud on the boot" users to smile again. They understand the error paths, they will give you alternate scenarios (we will talk about this later). These users can be found in your field service agents, technical support department... etc.
If you know of some other user group that I missed to get "user requimements, I would like to hear from you...
Your next step is found in Gathering User Requirements - Part 3: Know Thy Users
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. And I may not be able to list of all them for you advanced users. But for our Jr. BA or those who have very little experience gathering user requirements, these are the folks that you should consider when planning for the collection of user requirements:
"Mud on the boot" users: these are the front line users. They will be using your product on a daily basis. A frustrated "mud on the boot" user can be like a virus. They like to vent or complain about their products. They will tell you how they do their jobs, and how they would like to see things improved. They may also have some level of competition among each other so if your product allows them to perform their activity effeciently, they will rave about it.
The "Wind Stoppers": they perform the middle man role. They deal with the "mud on the boot" users on the daily basis and know the pains and successes of those users. They provide assistance, run reports, and overal understand to some degree the needs of the the "mud on the boot" users. If your organization sells directly to the "mud on the boot" population, your "wind stoppers" will be internally, such as customer service, call center, sales department, training department... etc.
and finally the "Fixer Uppers": if anyone can give you what the users have difficulties with, the "fixer upper" is the person to talk to. Once the "wind stoppers" intercept the issues on the field, the "fixer uppers" are deployed to patch things up and allow the "mud on the boot" users to smile again. They understand the error paths, they will give you alternate scenarios (we will talk about this later). These users can be found in your field service agents, technical support department... etc.
If you know of some other user group that I missed to get "user requimements, I would like to hear from you...
Your next step is found in Gathering User Requirements - Part 3: Know Thy Users
Gathering User Requirements - Part 1: The Beginning
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:
1. Inability to use the product in the desired way
2. Missing much needed features
It's so easy for those who have been in an industry for numbers of years to assume that they know what the users want and need. Though this might be true to some degree, it may not always be the case, especially when we are talking about detailed requirements.
For example, if after working for many years in a particular industry, you come up with this really cool product that will help those in the industry perform their jobs more effienctly, then KUDOS to you!!!! However, having a high level idea or understanding the high level requirements (such as business requirements) may not mean that you know how the users activities should translate in your product.
It's only by gathering those requirements that you will know how to build a product that puts a smile in your customers.
To continue with the series, go to Gathering User Requirements - Part 2: What are User Requirements?
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:
1. Inability to use the product in the desired way
2. Missing much needed features
It's so easy for those who have been in an industry for numbers of years to assume that they know what the users want and need. Though this might be true to some degree, it may not always be the case, especially when we are talking about detailed requirements.
For example, if after working for many years in a particular industry, you come up with this really cool product that will help those in the industry perform their jobs more effienctly, then KUDOS to you!!!! However, having a high level idea or understanding the high level requirements (such as business requirements) may not mean that you know how the users activities should translate in your product.
It's only by gathering those requirements that you will know how to build a product that puts a smile in your customers.
To continue with the series, go to Gathering User Requirements - Part 2: What are User Requirements?
Friday, August 10, 2007
So you want to be a Business Analyst!
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 finaly 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 has identified 6 Knowledge Areas that can be and should be performed by the Business Analyst. These Knowledge Areas (KA) are:
1. Enterprise Analysis
2. Requirements Planning & Management
3. Requirements Elicitation
4. Requirements Analysis & Documentation
5. Requirements Communication
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 effeciency 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.
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 has identified 6 Knowledge Areas that can be and should be performed by the Business Analyst. These Knowledge Areas (KA) are:
1. Enterprise Analysis
2. Requirements Planning & Management
3. Requirements Elicitation
4. Requirements Analysis & Documentation
5. Requirements Communication
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 effeciency 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.
Tuesday, August 7, 2007
Saying "No" without saying "No"
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:
1. Baseline what you currently have: It's very important that you understand where you are with your product. What have you already developed? What are the components that are still under development and what are their functionality?
2. Understand your customer's requirements: You need to know exactly what is it that your customer is asking for in terms of business and system requirements. Performing a requirement analysis will help you accomplish this. It's important that you know the core functionality and users that the product will affect. Make sure you capture the functions the product must perform to support the core functionality of the business and the desired functions requested by the users.
3. Understand the gaps that exist between what you have and what they need: If you have a well documented product, this task is easy to do. If whoever your product is poorly documented, make sure you look research the functionality that the product supports and what it doesn't.
4. Analyse the impact of covering the gap (cost, time, & resource): Once you know how what is missing from the current system in order to satisfy your customer needs, translate this into numbers as far as how much it will cost your organization in monatary value, time and resource.
5. Present the result of the impact analysis to your customers: Since your customer will have to pay for this endeavor, by showing them the cost of the project, they can make their own decision. I have also found that if you give them several options, you can gear them toward choosing what will be a win-win situation. For example, instead of giving them only how much it will cost them for all their core functionality plus their desired functionalities, you may separate the two prices. If your customer is more concerned with immediate result, you may show them how breaking down the project by either functionality of certain components will give them what they want in the time that they want.
This approach allows you to channel the negative response back to your customer court without making your responsible for making the decision.
As a business analyst, even though you will find yourself making lots of recommendations and decisions, you will also find that you are the "fact messenger". When presented with a situation where you have to say "no" to your customer, don't be afraid to say "YES, let me give you some options on how we are going to do this and see how YOU would like to proceed"
Here is the trick:
1. Baseline what you currently have: It's very important that you understand where you are with your product. What have you already developed? What are the components that are still under development and what are their functionality?
2. Understand your customer's requirements: You need to know exactly what is it that your customer is asking for in terms of business and system requirements. Performing a requirement analysis will help you accomplish this. It's important that you know the core functionality and users that the product will affect. Make sure you capture the functions the product must perform to support the core functionality of the business and the desired functions requested by the users.
3. Understand the gaps that exist between what you have and what they need: If you have a well documented product, this task is easy to do. If whoever your product is poorly documented, make sure you look research the functionality that the product supports and what it doesn't.
4. Analyse the impact of covering the gap (cost, time, & resource): Once you know how what is missing from the current system in order to satisfy your customer needs, translate this into numbers as far as how much it will cost your organization in monatary value, time and resource.
5. Present the result of the impact analysis to your customers: Since your customer will have to pay for this endeavor, by showing them the cost of the project, they can make their own decision. I have also found that if you give them several options, you can gear them toward choosing what will be a win-win situation. For example, instead of giving them only how much it will cost them for all their core functionality plus their desired functionalities, you may separate the two prices. If your customer is more concerned with immediate result, you may show them how breaking down the project by either functionality of certain components will give them what they want in the time that they want.
This approach allows you to channel the negative response back to your customer court without making your responsible for making the decision.
As a business analyst, even though you will find yourself making lots of recommendations and decisions, you will also find that you are the "fact messenger". When presented with a situation where you have to say "no" to your customer, don't be afraid to say "YES, let me give you some options on how we are going to do this and see how YOU would like to proceed"
Subscribe to:
Comments (Atom)