The word "elicit" more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

1. To draw forth or bring out (something latent or potential)
2. To call forth or draw out (as information or a response)

There are many ways to elicit requirements from your stakeholders. A BA should be proficient in all of these: interviews, workshops, focus groups, brainstorming, observation, and surveys/questionnaires. While all of these methods involve three basic parts: preparation, conducting, and follow-up, they do have differences.

Interviews

Interviews, either with an individual or with a group of people, offer the opportunity for rich, detailed communication.

Prepare

• Define interview goal: Determine exactly why you are holding the interview and what you want to achieve in it.
• Select participants: Decide who needs to be involved in the interview in order to achieve that goal.
• Determine logistics: When and where will the interview be held, and how will the interviewees be invited?
• Design the interview: Decide on the format that is most appropriate for the interviewees and the goal. Should it be structured with a detailed agenda and formal set of questions, or unstructured with a looser agenda, depending more on ad hoc interaction? Should the questions be open-ended requiring sentences or paragraphs to answer, or closed-ended requiring short, even one-word answers?

Conduct the Interview

Take time at the beginning to ensure that the interviewee(s) knows the purpose of the interview, who you are, and what your role is. Wrap up the interview with questions like "Is there anything else you would like to add?" and a hearty "Thank you!"

Follow up

Like any other meeting, interview minutes should be published. This allows the interviewees to see what you learned in the interview and validate that what you heard is what they intended to say.

Workshops

A workshop is a structured method for interacting with a group of people. Workshops can generate much information quickly if well facilitated and if participants are active.

Prepare for Workshop

• Define purpose: Determine exactly why you are holding the workshop and what you want to achieve in it.
• Select participants: Decide who needs to participate in the workshop in order to achieve that purpose. Make sure to consider the personality types involved and ensure that you'll get participation from the entire group, not just a few dominant people.
• Determine logistics: When and where will the workshop be held, and how will the participants be invited?
• Conduct preliminary interviews: Some workshop methods include collecting some information from the participants before the workshop to provide a starting point. Such methods provide specific guidance about what preliminary information should be collected.

Conduct the Workshop

Be sure to accurately capture all of the information that the workshop produces. Depending on the size of the group, you may want to assign a record-keeper so you can focus on facilitation

Follow up

Some types of workshops result in the assignment of action items to the facilitator or participants, in which case, they must be managed to closure. The workshop results should be published so the participants and other interested parties can see what you learned in the workshop.

Focus Groups

A focus group is an interactive session with a carefully selected group of people designed to capitalize on the synergy of a group.

Prepare for the Focus Group

• Select participants: Decide who needs to participate in the focus group in order to achieve its purpose.
• Define roles, topics, and logistics: Define who (among the people running the focus group) must do what, and the specific topics that the participants will discuss. Also define the basic logistics such as when and where the focus group will be held, and how the participants will be invited.

Run the Focus Group

Carefully facilitate the group to ensure free and open interaction among the participants. Participants must feel free to interact openly or the focus group could fail.

Follow up

The focus group report records what was learned, including both agreements and disagreements among the participants.

Brainstorming

Brainstorming is a method of quickly generating many creative ideas from a group of people.

Prepare for Brainstorming

• Define topics and time limits: Define precisely what will be the focus of the brainstorming session, and how long it will be allowed to go on.
• Select participants: Decide who needs to participate in the brainstorming session in order to achieve its purpose.
• Determine evaluation criteria: Decide how the ideas that come out of the brainstorming session will be judged afterward. Be sure that the evaluation does not go on during the brainstorming session.

Conduct Brainstorming

Encourage a free flow of ideas. This requires careful facilitation to ensure that participants feel comfortable with adding any idea to the list, and that no criticism or even discussion of the ideas goes on during the brainstorming session.

Follow up

Apply the evaluation criteria to the ideas that were generated to reduce the list to only those ideas that are reasonable or viable.

Observation

Observation is watching people as they go about their jobs. Observation can be an effective way to gain a realistic and detailed understanding of how work is done in the production environment; however, it is time consuming and may disrupt work.

Prepare for Observation

• Define goals and individuals to be observed: Decide what you are trying to accomplish in the observation and who you should observe in order to achieve those goals
• Decide on mode: Observation may be done in either of two ways:
  • Passive/invisible: Observing in a way that does not disturb the workers. "Invisible" refers to the fact that the workers are not even aware that observation is taking place.
  • Active/visible: Interacting with those who are being observed. For example, asking questions and having them describe what they are doing and why.

Observe

If people believe that they are being evaluated, they are likely to do the work "by the book," instead of the way they normally do it. So those who are being observed must be assured that the observation is not for the purpose of judging them. As the observation goes on, keep detailed records of what is observed and questions that must be answered later.

Follow up

After obtaining answers to any remaining questions, publish the results of the observation.

Surveys/Questionnaires

Surveys allow you to collect information from many people in a relatively short period. A survey can be an effective way to collect quantitative information; however, writing the questions requires great skill and care to avoid ambiguity that could compromise the utility of the results.

Prepare for the Survey

• Define purpose, target people, and logistics: Decide what you are trying to learn from the survey, who you should target in order to achieve those goals, and how the survey should be distributed (for example, paper, e-mail, internet, telephone).
• Choose survey type:
  • Open-ended questions vs. closed-ended questions: Open-ended surveys are more difficult to analyze, yet closed-ended surveys limit the responders' options.
  • Anonymous vs. signed vs. optional: People may be more forthcoming if they do not have to provide their names, but anonymity does not allow for any follow-up questioning.
  • With vs. without pre-survey or post-survey interviews: Pre-survey and post-survey interviews increase the valuable data that you can get from the survey, but add significant effort.
• Define target response level and follow-up activities: Getting many people to respond to a survey is difficult. If you are expecting more than a small minority of the target people to respond, it will require follow-up work beyond merely distributing the survey.
• Write questions: This step is more challenging than it sounds. Writing questions that cannot be misinterpreted (resulting in misleading results) requires great skill and concentrated effort.
• Test the survey: Because it is so difficult to write questions well, it is advisable to test the survey to see if people misinterpret any of the questions, and to see if it provides the information that is sought.

Distribute the Survey

Get the survey into the target people's hands, and encourage them to respond. If follow-up activities are planned to increase the response rates, do them.

Follow up

After the response period has ended, analyze the data, and summarize and report it to the appropriate people.

This is my second article on the same subject.

Yesterday I was going through Business Analyst Times and came across with some interesting facts about the so called PM/BA role.

Some people might take this as a direct attack to their practices and so called best processes throughout the years and might take it personally.

My first question is, is it fair enough to ask for a person to bare both the roles on a project?

These two are against to each other.

Good BA should look at the customer’s needs and should be able to convert them in to format which ease the life of the developers and the testers. He should be able to list down and develop all the requirements from the customer’s side. In some cases he should be knowledgeable enough to figure out the customer’s needs and propose something workable for them. He should be smart enough to identify the priorities and develop requirements accordingly. Then the developers can identify the customer’s needs and convert them in to a working piece of software and testers can start deriving test scenarios or the transaction sets to see the health of the application.

PM on the other hand is there to control the scope, budget, time, resources and quality of the deliveries. Some might argue that controlling the scope is somewhat business analysis task so that PM can wear the BA hat easily.

Someone will suggest that for smaller projects, you can get the PM to work as the BA as well.

Yet again it’s a burden for the company. If it’s a small project, let a senior dev or test resource to play the BA role on behalf of the team. Otherwise you will be ends up with increasing the project costs. Rarely the pay rate of PM goes below a developer or senior engineering resource. Companies might think that they are keeping their PM resources idle by giving some small project(s). That’s not PM’s fault, it’s an issue with the company’s forecasting and the sales team. If your sales team can not bring down projects which create enough workload for PM’s and if your resource management team can not foresee the resource requirements for the projects, then you have to deal with those. You have to fix that issue first. Please do not try to screw the lives of your PMs by adding something opposite to the PM practice in to their bag due to inefficient marketing and resource management teams.

Following comments were taken from the BA Times. Those were published by very seasoned Bas with number of years working experience against their BA portfolio.

“They are also the advocates for different goals. The PM needs to think time lines and the lining up of schedules, resources, and events. The BA needs to ensure that critical requirements are met and that the system is useful to the customers. That's not to say time lines don't concern the BA, but it snot his/her primary focus. It's through dialog that these two can compromise and work together to build a system that can be workable and on time.

If you combine this role, you'll always have someone who leans too far on either side of the fence.”

“It guess it all depends on what you expect a BA to do.

If you expect your BAs to simply document the work of others... then there isn't much of a difference. However, if you expect your BAs to play a significant role in the overall project then there is a significant difference between the skills set of a PM and a BA.

A BA is the keeper of the "what's delivered". They know not simply the requirements and design they also know the "intent" of the customer of a project. They play the role of "keeper of the faith" with the customer. The BA knows the "what's" well enough that they can "know" the systems impact of a change or issue.

The PM is the keeper of the "when it's delivered" or "how it's delivered". They know all the work items and which have to occur in which order. They know when each comes in to play and when they will be delivered. They are the "keeper of the schedule". The PM knows the "when" well enough to know schedule impact of a change or issue.

These are distinct skill sets... The ability to hold the entirety of a project in one's head well enough to do both the BA and PM role is a huge task that very very few can do well (if any can.)

I guess the real distinction between the skills of a BA and a PM is not that one can't do the role of the other... After all... most of us can use a paint brush, and we can paint a house. The issue isn't ability its skill. And, its the nature of the skill sets of a BA versus a PM. The best BAs I know have a more abstract way of thinking. They tend to model reality as a set of generalized rules. This versus the best PMs I've met who tend to a more concrete and defined way of thinking. They tend to conceive of reality as a series of discrete events driven by specific rules.

Another way of looking at would be... PM are hearders... BAs are guides. Both get you where you're going... they just do in in very different ways. Are the skills the same? No. Is the out come... perhaps... but the journey certainly was different.”

“As a BA, I TOTALLY agree with you! We actually have combined PM/BA roles in my organization now and it has had it's share of issues! We are currently in the process of separating those individuals into either the PM or BA role. There are a lot of soft skills that a BA needs to have vs. soft skills a PM needs to have. Like you said--different brain wiring! Combining the two into a single role is NOT the way to go!

My vote is an emphatic and resounding NO!!!!!”

“A combined PM/BA role might be practical on small projects or on simple projects (or if such a person is willing to work 16 hours a day). Any project of moderate complexity needs to have dedicated focus by a PM and BA to insure the PM is not being distracted by the often very time consuming details of analysis (or other aspects). This is also necessary to insure that resources are being properly utilized and that the PM has time to think proactively about the project to anticipate issues and alert stakeholders to needed course corrections before major issues arise. This is one of the most important functions of a PM.

Most projects I am involved in require several BAs and at least one PM, all of which can generally expect to work more than full time. Combining a PM/BA role would be a major risk for a project of any complexity or size for the above mentioned reasons, which would need to be added to the project risk register and monitored throughout the project. I speak from experience currently as a BA on larger projects having been a PM, developer, DBA, data modeler etc on various past projects. That's my 2 cents worth.”

“I'm a BA that is forced to play both the PM and BA role in more and more projects. It is a challenge because the roles have principles that conflict.

Unfortunately, I see a lot of companies moving in this direction. And I also see many professionals promoting themselves as a "PM/BA".

I personally believe the roles are best left separate especially considering many BAs have no interest in PM work and vice versa.

Is PM/BA/QA next?”

“Indeed... not "wired different" (per say)... Rather, focused different. Can a BA transition to a PM role and vice versa? Absolutely. But can one person do both roles effectively, no (IMO). Its bad for the workload, its bad for the appropriate project controls, it is distinctly two different function. The PM and the BA are peers in a Project... They keep different aspects of a project in-alignment with the business/customer goals.

Anyone seeing some sort of merger of the roles is also seeing a much smaller scope for each role... They are under-utilizing their BA and PM resources.

It comes down to how one defines what the roles are. In some companies the two roles are easily combined because the actual scope is significantly limited and really is much more administrative in both cases. In other companies I've seen the roles of the BA and PM having a much greater definition and each is a high distinct skill set and responsibility set.”

Throughout the years we are discussing about the same topic. But some organizations purposely combine these two roles for following reasons;

• They want their employees to work like slaves
• They do not want to spend a penny more to improve the work life of the workforce
• They never think about their customers
• They think their customers and employees are dumb asses (one suppose to pay contract fee on time and other suppose to work for less)

You can add many more to the LIST

Ultimately what happens is both these fellows will get frustrated and move out!!!

After a long silence, here I start my first blogging…
Even though the blog heading is QA Heaven, never discussed the QA issues on this forum…
Most of the local vendors utilizing the term QA in wrong way…
Who ever test an application gets the two letters in front of their designation and becoming QA Engineers…
And the selection criteria for the QA Engineering position also got degrade throughout the years…
If you lack the coding standards but can test the applications to catch visible errors, then you can become a QA Engineer in this country… That is easy as that…
Those ridiculous practices lead to many of the organizations from good to bad and bad to worst and created chaos…
As a direct result of these practices, customers came up with 1001 defects even after the UAT (user acceptance testing)…
I am not going to talk much about those issues here… but taking my time to criticise some of the practices at a process savvy IT company in Sri Lanka…
I am not going to reveal the name over here since it might be the practice and the cost cutting mechanism at most of the local vendors…
Not only local vendors, there can be hundreds of thousands of companies around the globe doing the same mistake…

Yet again a something which is outside from the QA but this is the right time to build a constructive criticism on so called best practice at that organization…

This company tends to hire resources to undertake both the Business Analyst and the Project Management role in parallel…

Hmm… two one has to show the two sides of the coin at the same time…

While I was browsing through the web, found this interesting interview and sharing the same for your informational purposes…

Here the author Michelle Davidson presenting a summary of interview with the Barbara Carkenord, who is the author of "Seven Steps to Mastering Business Analysis”.

Business analysts must have certain skills and must understand the many software requirements techniques out there, says Barbara Carkenord, author of "Seven Steps to Mastering Business Analysis."

What made you decide to write your book, "Seven Steps to Mastering Business Analysis"?

Barbara Carkenord: The reason from a business analysis perspective is that there really haven't been any books written specifically for people doing that type of work. There are a lot of books on techniques and analysis techniques, but not anything that says here's everything you need to do analysis work. There are people just coming into the role who really don't know what they need to do, and this book is for them.

If someone is considering becoming a business analyst, what skills are considered necessary?

Carkenord: I would say the number one thing is communication skills -- both verbal skills and written skills -- documentation -- because the main job is to be a liaison between two groups who don't communicate well.

They also need skills around understanding how technology can solve business problems, which means they need to know about the business and what's technologically possible.
They have to be people who can logically break down problems and think things through -- just very analytical.

What challenges should new business analysts be prepared to face?

Carkenord: I think the biggest challenge when you're assigned to a project is really trying to figure out how to get started. There's a lot available to you and a lot you need to find. You need to figure out whom to talk to in order to get the information you need.

When it comes to software requirements elicitation, elaboration, and validation, what are the biggest problems business analysts have?

Carkenord: The biggest challenge is business people don't always recognize what they need or what is capable for them. So they have trouble communicating with IT. And IT doesn't understand the business side, so they give them an elegant solution that doesn't do what they need.
Business analysts need to help business people figure out what they really want. The BAs really need to sit down and talk with them.

I think the development environments continue to be more and more productive. Developers can build things very fast, but we don't know what we want them to build. They can build a lot of things, but are they meeting business needs?

What techniques and strategies serve business analysts best when it comes to working with stakeholders?

Carkenord: We have a lot of techniques. There are actually hundreds of analysis techniques. Part of the challenge is learning which works, because each project might necessitate a different way.
For a new BA starting out, we encourage using a real structured scoping technique to get the business people to agree what the objectives are. You can determine what are we doing and what are we trying to accomplish.
Data requirements are also very important. And we encourage new BAs to use Entity Relationship Diagramming (ERD) to structure data. It's a really good way to elicit requirements of what the needs are of the business.
Use cases are a very popular requirements technique right now. We also do prototyping and storyboarding.

In your book you talk about business analysis certification. Do you think that type of certification is necessary?

Carkenord: It's become popular because the role of the BA is very challenging to define, and companies don't have good job descriptions. So, they're looking to certification to help them figure out if this person really knows how to do this work.
Certifications are very popular. So I suspect this will be as popular as, say, the PMP [Project Management Professional] certification.

Certification in many IT industries, such as testing and project management, is a controversial topic with many saying certifications don't guarantee a level of expertise. Does this controversy seep into the business analysis realm?

Carkenord: I do think there's always going to be that challenge of whether the certification really means something. The IIBA [International Institute of Business Analysis], which certifies business analysts, is aware of those kinds of issues and has worked really hard to design a program that would assess people's ability to do the work rather than just pass a test. The work experience aspect is very high, and the questions are very analytically based. You need to think analytically to answer the question.

What's the difference between a project manager and a business analyst, as a lot of project managers have been responsible for requirements?

Carkenord: We see them as two completely separate roles, at least on large projects. I think the personality traits for project managers are different than BAs. PMs are managers; they push things forward, and they get things done. BAs are analytical and like to explore, but they can get stuck. They'll get all the details up front to make sure they don't miss anything.
If you have both on your team you're covering all your bases. If you have that team, your likelihood of success is much higher.

Many organizations trying to combine these two practices in to one and trying to utilize a single resource to cover both these aspects.

They never understand the importance of both these practices and neglecting a one. Pressure comes from the top management on cost cutting might be the direct reason for this.

As a direct outcome of this they never understand the value of BA and adding extra effort on project management and expect the resources to add higher effort on project management and controlling practices.

The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. At the same time, allotted resources failed to capture proper and accurate resources due to management pressure and the extra workload from the project management practices. This leads to failures in projects in the long run and generated frustration on both the customer’s end and the in house.

That doesn’t sounds that project manager should not carry any BA expertise but the roles has to be separated from one person and assigned to two or more resources based on the requirement.

That will improve the productivity as well as the efficiency and increase the correctness of the data or the requirements as well.

Dialog was discussing about the WiMax connections by mid 2005 but SLT started the trials. Even though their trials went successfully Dialog pioneered the WiMax offerings by entering in to the commercial operations by mid 2007. Q01 of the 2008 was a very interesting one and couple of players entered to the Mobile and WiMax market. It seems competition is getting very hot and newest addition to the WiMax game board is the Lankabell. They disclose their service offerings by 30^th May 2008 and will launch the services commercially by 2nd of June 2008.

Best news is SLT and Suntel too felt the heat and as per the Suntel’s authorities their WiMax shipment is on the way. SLT too brought the WiMax spectrum from a third party and increased their external bandwidth by twofold. If I am correct SLT having the infrastructure to launch the WiMax at the moment but waiting to see what others going to offer for the prospective clients. Other than the SLT and Suntel; Electroteks too waiting in the queue to offer the wireless broadband services.

Awesome…

Almost all the fixed line operators are now in to the broadband internet race?

My question is that who will win the race in the long term?

To make it a success story, they have to understand the requirements of the end clients.

Being a client of Dialog WiMax and the SLT ADSL, I am not happy with both their connections. SLT’s connectivity is not stable enough and sometimes I have to wait for hours to get the connection online. They come up with hundreds of thousands of explanations but none of them brought the exact solutions for problems. On the other hand, Dialog able to provide a much more reliable connectivity but sucks with downloads. Due to their fare usage policy sometimes I stuck in the middle of important meetings.

What I heard from the Lankabell was that they have covered the whole Colombo area and will charge max of 6600 (including government taxes) for their high end connection which is going to offer 2 mbps downlink and 512 kbps uplink. Best thing is that they come without any fair usage policies at the moment.

Answers for my question will be…

1. One with the best bandwidth
2. One with the best pricing scheme
3. Best support services
4. One with the customized solutions caters for different end user requirements will win the race…

As of now, most of their rates are high and restrictions and the bandwidth limitations are among major concerns.

So who ever break these issues will attract most of the demand and secure the number one position in the market.