Forums for the Business Analyst

  Modern Analyst Forums  ModernAnalyst.c...  Introductions &...  Intro and Advice
Previous Previous
Next Next
New Post 1/6/2011 9:03 AM
User is offline RMitch
1 posts
No Ranking

Intro and Advice 
Modified By RMitch  on 1/6/2011 12:51:34 PM)

 Hello, I'm new to the forum and wanted to drop a line to say hi. I've been a Front-End Web Developer for 12 years and my company is looking to move me into a BSA role.  It's a totally different career path for me so I've got a lot to learn.  

What are 5 pieces of advice would you give to someone making a move from development to BA? What pitfalls would you avoid if you could be a newbie all over again? Also, what do you like and dislike about being a BA?

Thanks for your time.

New Post 1/19/2011 6:25 AM
User is offline Chris Adams
323 posts
5th Level Poster

Re: Intro and Advice 

1) Know your business enivronement. Study the business.  Understand how the business operates and how it makes money.  What are the most prominent business processes within the business. What systems does the business have in place today to help support their processes.

2) Don't underestimate the importance of outstanding business requirements.  Even mediocre business requirements cost projects a lot of money as they carry over to each successive phase of the project.

  • Document WHAT the business needs not HOW
  • Document the WHY, or the business rationale behind the requirement.  As analysts get deep into the system design, question arise about why a requirement is stated a certain way.  The rationale helps answer these question.  Often by this put the business has forgotten WHY they said they needed something
  • Also take a look at the ModernAnalyst interview questions on the characteristics of a good requirement ;-)

3) Always think in terms of the logical and the physical design separately.  Model the system from a logical perspective first, then get into the physical design.  This is probably the MOST difficult thing for developers transitioning to a business analyst role.  I've witnessed their challenges in this ara first hand.  Both the logical and physical design are important, but they should be separate and distinct.   The logical design will align more closely with the business needs and won't change as frequently.  The physical design may change based on architectural constraints and other systems that it needs to interface with.

4)  Study and understand the importance and benefits of:

  • a Fact Model (also sometimes call a Business Entity Model)
  • a Logical Data Dictionary.

I'll let you do the research (some can be found here on  Which leads into the next point...

5) Don't be a lazy analyst.  Most analyst think that learning and career growth is whatever happens between 9am and 5pm.  The best analysts regularly study and read up on business analysis tools, concepts, methodologies, etc., outside of their regular work hours.  Everybody wants to think they are the top 20% of BAs out there.  Well 80% of them are WRONG.  To be in the top 20% takes real effort.  If you are on this site frequently, you are already taking the first steps that many BAs don't.

Good Luck!!

Chris Adams
Core Member –
LinkedIn Profile
Previous Previous
Next Next
  Modern Analyst Forums  ModernAnalyst.c...  Introductions &...  Intro and Advice

Community Blog - Latest Posts

Salesforce has established itself as one of the most reputable CRM platforms, providing important customer data to assist businesses in effectively managing their operations. Salesforce is the world's best CRM platform that helps businesses to keep up the data in an arranged or structured manner. Salesforce is the world's most popular...
There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms: Data exploration means the deep-dive analysis of data in search of new insights. Data presentation means...
Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...



Copyright 2006-2022 by Modern Analyst Media LLC