The three things a Business Analyst should think about during meetings

When it comes to working as a business analyst, I’ve learned that there are just three things you need to keep in your mind when meeting with your customers (the project sponsor (gold owner) and domain experts (“goal donors”)) to gather requirements. These three thoughts will keep your meeting on track, lead you to the next question, and will help you know when your work is done.

The three concerns of the business analyst

Those three key requirement-gathering thoughts of a business analyst are:

1. I need to finish the requirements document; what’s keeping me from calling it ‘done’?
2. I need to finish the database design; what’s keeping me from calling it ‘done’?
3. I need to finish these user interface prototypes; what’s keeping me from calling them ‘done’?

I’ve met with dozens — possibly hundreds — of customers over a 15-year career as a Business Analyst, and no matter what you think your job is, creating these documents is your primary concern — your only concern.

You can handle your meetings as Mr. Nice Guy or Ms. All-Business, but in the end, finishing these three documents is the only thing that matters. And, as a side benefit, a very cool thing about this approach is that if you keep those three goals in mind, you’ll always know what questions to ask next.

“Um, but I just write software requirements ...”

I know, I know, a lot of business analysts just write requirement specifications without creating a data model or user interface prototypes. I know there’s supposed to be a difference between requirements and analysis, but sorry, based on my experience, that separation of concerns doesn’t work in the real world.

I’ll agree that you don’t have to completely design the database as you go along (like I do), but you must create some form of data model, otherwise how will you know what you’re missing, or when you’re finished? (I’ll write another article in the near future about how Function Point Analysis helps you know when you’re done, and what you might be missing.)

As for the need for user interface prototypes, as they say, a picture is worth a thousand words. I’ve seen customers completely agree with a use case, then balk when they see the UI screens that correspond with the use case. Some people might call that an “implementation detail,” but I call it “communication.” Believe me, as a consultant, you must know that the customer agrees with the planned UI/UX before you give them a bid.

“But I don’t do database design or prototypes ...”

Your business may be staffed differently than mine, and it may not be your direct responsibility to create the requirements specification, database design, and prototypes, but for me, as a business analyst, these are still your deliverables, and your responsibility. Someone else may perform the work, but that work still has to be done, and very importantly, you need to know what’s missing.

“But what about ...”

I’m sure other thoughts may be rambling through your mind right now, perhaps thinking about things like time and cost estimates, but for me, those come later on in the process.

A fourth element

Okay, okay, if push hard enough I will admit that on more complicated projects you also need to consider the software and hardware architecture of your proposed solution, but I’m leaving this off my “Top 3” list for several reasons.

First, the architecture of most software projects is so simple that it doesn’t need to be discussed. You just say “This will be a web application developed in Java, using our usual toolset, and we’ll be hitting these databases on the back end, creating our new tables here, here, and here,” and that’s the whole discussion. While this can be much more complicated for large businesses with millions of users, I find it to be true for at least 80% of the projects I have worked on.

Second, most goal donors don’t care about this implementation detail ... well, at least not until you tell them the cost. But even then, at least 80% of the goal donors don’t care about the architecture, nor will they understand it. It also doesn’t affect them, as long as it matches their stated requirements.

Third, in many large organizations, there is often some sort of political firewall installed between business analysts and software architects. In some businesses there is a “firewall” between the software developers and the hardware people. So while I do think business analysts should have a firm understanding of how a solution will be implemented, and they should know when a customer starts talking “crazy talk” (requests that are way out there, or are technically extremely difficult), at many large organizations the business analyst is only allowed to go 80% of the way up the mountain, and then the software architecture people say, “We’ll take it from here.”

To summarize this point, yes, on more complicated projects you will have to discuss the planned architecture with some people, but not with all of them, so that's why I’ve left if off my “Top 3” list.