Forums for the Business Analyst

 
  Modern Analyst Forums  Careers  Getting Started  QA to BA
Previous Previous
 
Next Next
New Post 9/24/2007 10:04 PM
User is offline Adrian M.
762 posts
3rd Level Poster




Re: QA to BA  
Modified By Adrian M.  on 9/24/2007 11:06:50 PM)

 rina wrote

Thanks a lot for your advise, Chris and Adrian!

I am trying on the things suggested by you. You suggested that try answering the WHat system can do and answering all the why's but Are there any general questions where you can start from when talking to users about the requirements.....and then get into details???

Also, how can you make users to trust you and become more comfortable in your company?

Once again,thanks a lot for your suggestions.

Hi Rina,

Probably one of the biggest fears that new business analysts have is the fear of asking the wrong questions.  My advice to you is to stop finding the right questions - just use your analytical skills to find out what are some of the problems that the users are facing.  Don't ask them "What are your requirements?" as they don't know either.

Begin by asking questions such as:

  • What are the top three problems that you are faced with today and which a new system (or enhancement) could solve for you?
  • If you were to make one change to your current process, what would it be?
  • Why do you think this project is important to your job?

While these questions are very generic, they will get your users to talk.  Just be ready to listen!  Most analysts love to talk a lot (unfortunately - I'm one of them).  ;-)  The end users want to get the job done and, once you get them talking, you can't stop.  Be ready to listen carefully, very carefully!  Document what they say!

After your requirements workshops (meetings) go over your notes and make sure you clean the up.  Write down anything you don't understand and any questions that you may have.  These will become the questions for the next requirements meeting.  Also - being to organize the information that you are gathering.  You'll begin to see patterns of major issues/problems that the users have and you'll start to identify some of the critical requirements.

In addition, one question that you should be asking over and over again is "Why?".  It takes a number of why to get to the bottom of the "real" requirement.

For example, in one of my projects the users were asking for the ability to print out all the data they entered in the system before submitting it to the next department.  I asked why?   They said that they wanted to have a copy on file?  I asked why? They said because they wanted to reference it later?  I asked why?  They said because when the data gets to the other department and it's wrong they want to be able to show that they entered the data correctly!  Now we had discovered their real problem!  They did not really need the printouts, they were just sick and tired of the problems with the data transfer process.  In then end, rather than creating useless reports we fixed the data transfer problems at a fraction of the cost.  Everybody was happy!

"Why?" is your friend!  ;-)

Another thing you need to remember is that nobody expects the business analyst to be a business expert.  If all BAs knew everything about the business there would be no need for SME (subject matter experts).  The BAs could just write down the requirements and on they go.  But that is far from the truth!  The role of the analyst is to facilitate the conversation and to help the business experts get to the bottom of the real requirements.

Find an SME/end user which you feel comfortable with and ask them to point you to some resources (knowledge bases, books, manuals, etc.) that you can use to come up to speed on the specific industry that you are working in.  For example: if you are working for a retail company, ask for the operating procedures for opening and closing the stores, ask for the sales training manual, etc.  While you will not be able to gather requirements reading this stuff you'll be able to quickly understand the big picture of how the business operates (also known as the AS-IS).

Hope this helps!

Keep us posted on your progress!

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 9/24/2007 10:09 PM
User is offline Adrian M.
762 posts
3rd Level Poster




Re: QA to BA  

One more thing!  Take a look at the requirements related articles in the article repository:

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/CategoryView/categoryId/6/Requirements.aspx


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 9/30/2007 12:58 PM
User is offline rina
17 posts
9th Level Poster


Re: QA to BA  

Thanks for the information, Adrian.

I have one question: How do you deal with difficult Users. I met the users once during UAT (which was going on when I joined). I've heard it from everyone in my company tht the users we are dealing with are difficult in the sense, its hard to get the requirements from them. ALso the other Senior BA has been working with them for last 5 yrs, so wht can i do to make users get comfortable with me & get them easy to talk to me?

 

 
New Post 9/30/2007 6:09 PM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: QA to BA  

A structured approach is a good way to develop a sense of credibility. And as for users being difficult; there are a couple of ways this can show itself.

One is that they don't settle on their requirements because they don't know their business. Your analysis should provide a framework for them to match their local tactical needs to the strategic idea being implemented by the project.

Another is that they don't trust the project office or IT because of a history of bad projects. Again a structured approach is best.

A third problem is not assigning the right people to work with the project - you get someone too junior (can't make decisions) or too senior (too strategic and busy.)

Develop a requirements management plan and a communications plan and share it with them before going into the requirements in too much detail. Let them have their say on your approach and modify as you need to. Make sure everyone knows who is participating in requirements workshops, reviewing documents and approving things before you get to the first major requirements session (or as soon as you can afterwards.)

Success comes from a partnership between business stakeholders and the project team. Starting with closing this gap.

 (By the way; don't rush your requirements, speak with everyone at least twice, and ask for help if you need it.)

 
New Post 9/30/2007 6:35 PM
User is offline rina
17 posts
9th Level Poster


Re: QA to BA  

WHen do you start communicating with Developers? Is it that you first gather the req, create mock ups & document the requirements & then after the req. are complete, then you involve the developers or the process goes hand in hand?

Also, what exactly is 'Story Specification'?

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Careers  Getting Started  QA to BA

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...

 






 

Copyright 2006-2023 by Modern Analyst Media LLC