That’s Not Your Job

Last month we talked about adding value. In truth, delivering value is everyone’s job. We are all here to add value. Some of us do that through thinking up new things, some through helping a customer over the phone. Some add value by selling things in a physical store and others by writing code. In the exchange between a company and an individual you deliver some value to the company and in exchange you receive value, such as vacation time, retirement savings, and maybe insurance.

The question for you, Business Analyst, is how do you add value?

Please take a few seconds, stop reading, and think about this. What value do you deliver? Tell you what, when you come up with your answer open Twitter and post your answer with the tag #BAvalue¹.

Did you post the value you deliver? Go ahead, do it now.

Please.

I’m not going anywhere. I will wait right here for you. Go on.

—-
Ah, there you are! Welcome back.

As a business analyst I have given a variety of responses on how a BA adds value, depending on my mood or the audience. Talking to BAs, I hear the same things I said. Here are some popular responses:

Gather (or elicit) requirements

Gathering requirements is an initial step in traditional² projects. It assumes someone has been thinking about this and has stuff figured out. The job of the analyst is to go and “gather” this information from key stakeholders. It’s as if there are diamonds scattered in a field and the business analyst merely has to ask a few questions to put them into her satchel.

There are a few assumptions and problems with this comparison. The first assumption is some person has thought through everything they need and want to be built. Second is requirements can be gathered with just a few questions. And third, analysts have gathered diamonds rather than the droppings of some random varmint that just ran through the field. If all we had to do was take notes on other people’s ruminations we would be titled stenographers, not analysts!

These problems are a big part of why the IIBA prefers the phrase elicit requirements. Eliciting means to evoke or draw out. In practical terms, it means we understand our stakeholders have not thought of everything and we cannot simply accept what we told. We must dig into context and needs, motivations and desires, presumptions and goals in order to uncover the missing gems a simple conversation will never reveal.

Whatever your word choice, this step is important because it gives guidance for the project. It results in requirements, constraints, models, and even documented assumptions. “Obviously,” I would say, “we need to gather (elicit) requirements! If we don’t know what they want, how will we build it?”

Translate what the business wants so developers can build it

This is a big one: translating between stakeholders and developers, developers and stakeholders. The truth is, the two sides don’t often meet. Stakeholders—end users, line managers, executives sponsors, whomever—are busy folks. And so are developers. Getting time for both of them to meet can be a challenge, especially if different parties work in physically different locations.

More significantly, the groups typically speak different languages. I cannot tell you the number of times I have business users’ eyes glaze over as developers start to answer questions in the form of APIs, service layers, questions about data table fields, or other techno-babble. And to our business partners, it’s all technobabble! They studied and spent a career in operations or accounting, shipping or sales. The number of business folks who want to understand how IT systems talk to each other is a very, very small number indeed. The groups need a way to communicate and Business Analysts are often the (only) translators between them.

Break down user needs or business desires into something cohesive, complete, consistent, correct, feasible, mandatory, modifiable, unambiguous, and testable

This list³ is concrete. This is something an engineer can validate. The need to build a system or solution, the ability to test it is built correctly (without serious defects), and the requirement for it to add business value implies we need a means to confirm we met the original goals.

Building off the conversation around gathering and eliciting above, not everything our partners want is known up front. There are almost always subtleties to what a customer wants. Breaking down what they want into something that is easy to build and test, on track with the goals, and not fluff⁴ is important. Our thinking is someone needs to do this because it’s going to be a disaster without it.

Write requirements / specifications / user stories

Naturally, the information we assembled, the assumptions and constraints we identified, from the overarching goals for business value to the tiny details in the interface, need to be documented.

Early in my career this was done through a Systems Requirement Specification (SRS). Depending on the project, I have also used terms like BRD, SSRS, MRD, VSD, and so on. With agile teams the needs are documented in User Stories, small elements of functionality that can be described on an index card.

Whatever the techniques for writing (or typing) what has been captured, this record is something business analysts consider vital for the building, testing, and history of a system.

—-

Now, as I write this, I haven’t seen your response yet. I really hope you have posted your reply on Twitter or in the comments below. However, if your answer is anything like one of the items above, you’re wrong. I’m not suppose to say stuff like that because it might cause you to stop reading, but there it is. Let me explain:

All of these BA contributions I listed above are like saying a racecar driver’s job is to shift gears. These things are tasks, but it is not her job. Surely, a racecar driver who doesn’t shift gears is going to lose the race, but it is a shallow response to say she adds value by shifting gears. The value she delivers is much bigger than that. Her job is to drive the car to its peak performance, navigate the course, and out-think her opponents. Her job is to win the race! Shifting gears, while necessary, is hardly a good way to say “this is how I add value.”

Similarly, the value of a farmer is not measured by tilling a field, nor is a ballet dancer measured by how high he leaps. The value they add is greater than that.

Which brings me back to the original question. How are you adding value as a Business Analyst? I know it is greater than your ability to ask questions (elicit requirements). I know it is greater than acting as a “go between” for stakeholders and developers. I know it is greater than how you documented a need or solution. Those things are part of what you do, but they are not how you add value. Those things are not your job.

What is it? How are you adding value?

I look forward to reading your replies. And I hope you come back next month as we dig into my answer.

Don’t forget to leave your comments below.

Notes:

1. You are on Twitter aren’t you? You work in technology. If you have not started learning about important social media tools that came out 9 years ago (an internet eternity!), then it’s time for you to start! If you’re not using Twitter and you want to learn why it’s important for business analysts (#baot #BAagile), then drop me a line and I’ll write a future article for you.
2. Agilists use different techniques for developing their product backlog.
3. For the more on the requirements of a requirement, see the IIBA BABOK, https://www.iiba.org/babok-guide.aspx.
4. The technical term for “fluff” is gold plating. If this term is new to you, please start with Rapid Development by Steve McConnell. A summary of the classic mistakes he discusses is found here: http://www.stevemcconnell.com/rdenum.htm