Let’s talk about business analysis (not to be confused with business analytics, which is different).  Consider a SQL development project.  Defining it is a matter of answering three questions:  Why, what and how?  “Why” are you doing it is the business requirements, “what” are you doing is the logical and functional design, “how” you are doing it is the physical design and code.  If you think of those answers in a continuum from requirements to code, usually a systems analyst or technical PM is the one to provide those answers someplace short of “code”.  In Scrum, the answer to “why” is owned by the product owner, who provides and stack ranks requirements and accepts work products as meeting those requirements.

So what is business analysis?   PMI defines business analysis from the context of a project manager who works with stakeholders to enumerate project or business requirements, and ensures projects drive successful business outcomes.  The International Institute of Business Analysis™ (IIBA®) defines it more expansively.  Their definition is more encompassing, and probably closer to what used to be thought of as business consulting, a practice to achieve organizational improvement.  Rather than paraphrase, read IIBA’s description.

I really enjoy my time as a business consultant, but it seems to me that the reality for most organizations is PMI’s view of business analysis.  Companies are always trying to get “closer to the customer”, to better understand requirements and thereby efficiently produce products customers desire.  Even so, it’s also my feeling that there’s a lot of value in IIBA’s Business Analysis Body of Knowledge (BABOK®) and understanding it makes for better projects.  It’s no trick to say the more knowledge a project manager has, the better are the projects they manage.