Human Factors

On Being a BA: Thoughts in 5 Parts

Leave a comment

I’ve been mentoring and sharing Business Analysis best practices on an ad-hoc basis for most of my career. Colleagues and friends have been the primary audience, on everything from BA 101-level stuff, like “How do I write good requirements?” to more delicate and complex topics like how to navigate tricky political waters on a project.

There’s been much ink spilled over the nuts and bolts of documenting requirements.  And we could talk about that, but that’s not terribly interesting for me.

How I would answer the question of “How do I write good requirements” gets a little philosophical.  I’m also going to make a quintessentially BA-like move to make everyone rewind and examine their assumptions before answering the question, so that’s what’s going to happen up in here.  I’m going to talk about how to BE as you do requirements elicitation, analysis and validation as a Business Analyst.

Stay tuned for posts on:

  1. Requirements as Art (not Science)
  2. These Aren’t Your Requirements
  3. Requirements are Never Done
  4. People Problems, Not Technology Problems
  5. The Question Behind The Question

 

On Being a BA: Requirements as Art (not Science)

Leave a comment

[Part 1 of a 5-part series of posts about ways of being while being a Business Analyst]

There are many ways to express requirements as a Business Analyst.  There are templates and methodologies and analytics about requirements metadata… but all that quantifying effort fails to illuminate that requirements are not concrete things that can be effortlessly pinned down, categorized and defined. That’s why BAs stopped saying we “gather” requirements and instead “elicit” them.

Much of what we do as Business Analysts is to take messy ideas and complex situations and describe them succinctly.  This is what any system that has people as a component (e.g. all of them). We tend to lean on the hubris that we’re performing objectively.  That what we’re documenting is fact, reality, truth.

In practice, it’s more like a painting than a photograph.  Sometimes it’s an out-of-focus photograph of a painting of another photograph.  How close you can get to the primary source of the ideas will dictate how accurately you depict them.

Business Analysis is also a discipline you cannot study in school (this is emerging, but most of us “fell into” business analysis).  It’s experiential.  You get trained on some of those methodologies and templates and make lists of questions to ask and check them off one at a time and you still make mistakes.

Because you need to live through it to learn from it.  That’s really painful for people who are not genetically predisposed to analysis to fathom.  It’s why BAs will often answer every question with a long story as preamble to their reply.  Because there is more in heaven and earth and their requirements, than are dreamt of in their philosophy.

Other posts in this series:

  1. Requirements as Art (not Science)
  2. These Aren’t Your Requirements
  3. Requirements are Never Done
  4. People Problems, Not Technology Problems
  5. The Question Behind The Question