Honey, What is it you Really do at Work?

Are you sometimes at a loss to explain to your spouse, family or friends just what is it that you actually do at work as a Business Analyst? Do they ask you questions that you don’t quite feel comfortable answering?

And even if you have answered the question, you haven’t completely explained what it is that you actually do. More importantly, you haven’t touched on what value you give to your organization. Here is a scenario that you might recognize:

Q: “So, do you tell the programmers what to do?”
A: “Uh-hmm, no I don’t. I really describe and document the new system or parts of a system that they have to produce.”

I know that after trying to answer a question like this, and adding in some more details that I think are relevant, I can see by the long pause that follows my answer that I haven’t communicated much but have simply managed to overload the questioner with TMI; Too Much Information. I’ve answered the question but not explained myself.

But why be concerned about these kinds of questions, you might ask. You know what you need to do, so go and do it so your clients and manager will be happy and forget about your job description. That’s fine, but I believe that by answering these questions you will sharpen your own understanding of the role you play as a Business Analyst.

Consider this scenario:

Q: “Well, I know that business is about making money, and you’ve analyzed all that, so do you have any tips about making money for me?”
A: “Well, ……. actually I don’t work at making money, I work on computer systems.”

There are two parts to this problem of describing what we do:

• The “Business Analyst” title is too broad and easily misinterpreted. “Requirements Engineer” is more accurate, but you are more likely to find this title in academia rather than in business. The Business Analyst title has persisted for good or bad.
• We know what a firefighter, teacher, or doctor does, at least at an abstract level, and why those jobs are important. Some might even understand what a Network Engineer does. But not many people understand why it’s important to describe business workflow in great detail before the programmers begin their work in order to produce quality software.

Whenever I am in a situation like this, where it is too time consuming and complicated to thoroughly explain something, I often resort to analogies. This is a quick way to communicate the core values that a BA brings to their job roles, and the choice of an analogy sharpened my own thinking about what I accomplish at work.

My favorite job analogy is that of a lawyer who you see in order to have your will or testament written. In your everyday language with your lawyer you describe what you intend to happen, much the same way that project stakeholders first describe the new system or improvement that needs to be produced. It is the lawyer’s role to understand what you described, determine feasibility, and question ambiguities or conflicts in your statements. The lawyer may also act as a consultant, offering alternatives that may affect your estate taxes or point out something you may have overlooked.

The lawyer then produces a document specifying your desired outcomes. The document must include all your specifications, and be free of any ambiguity so it can be interpreted clearly by any other lawyer or judge. After all, if your will is being read then you will not, obviously, be available to answer any questions.

The Business Analyst also produces a document that needs to be precise and unambiguous, and while the BA will be available to answer any questions from other stakeholders the document still needs to stand on its own.
Using this analogy has helped me to understand the key role that language plays in the discussion, discovery and clarification of requirements, from ordinary language that typically includes jargon and colloquialisms to precise descriptions that leave no room for multiple interpretations.

In ordinary language, we tend to use metaphors and indirect comparisons rather than literal descriptions. I don’t know if this occurs in languages other than English, but it does occur even in conversations with technical people. A software engineer I worked with used phrases such as ‘The system knows that …’, which of course is total nonsense. That system, any system, knows nothing; it’s just a machine. Yet we use these expressions constantly when discussing functionality or requirements.

As a Business Analyst you need to be aware of when discussions include these metaphors and colloquialisms so that you can question or clarify them until you arrive at a clear understanding of requirement needs.

Another analogy I’ve successfully used is that of an editor at a publishing house who is putting together a book of regional recipes. The editor consults with chefs or prominent cooks, similar to the way a BA consults with subject matter experts, to discover and then document recipes.

The editor may write about the background of these recipes, and then develops the recipes in a clear manner so that any reader can follow them. In all likelihood, the editor is not a chef, but most likely does have a strong interest in cooking. This analogy emphasizes collaboration with subject matter experts when you are not an expert yourself, and clear writing that follows logical sequences.

This is, of course, what a Business Analyst does when developing use cases. You might think of a recipe as a use case, with preconditions, triggers, actors, sequential steps, and postcondition metrics. Both the editor and Business Analyst have similar deliverables to produce; a step-by-step description of how to create a dish in the case of the editor and a workstep or process description in a use case format for the Business Analyst.

Besides sharpening your own thinking, answering the ‘what do you do at work’ type of question can make you more confident in your role at work.

What analogy would you use to answer that question, ‘What do you do at work?’

Don’t forget to leave your comments below.