Author: Jeffrey Davidson

That’s Not Your Job

Written by Jeffrey Davidson on February 24, 2015. Posted in Articles. 1 Comment on 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:

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.
Agilists use different techniques for developing their product backlog.
For the more on the requirements of a requirement, see the IIBA BABOK, https://www.iiba.org/babok-guide.aspx.
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

Why Do We Need Business Analysts?

Written by Jeffrey Davidson on January 19, 2015. Posted in Articles. 1 Comment on Why Do We Need Business Analysts?

It’s easier to defend Business Analysts than it used to be. Part of the reason is because I am defending the role in general. My job isn’t on the line any more. For other people this is a much more immediate concern. Still, it brings back memories. I hear the question at a conference or networking event and my heart shrinks. “Why do we need business analysts?” No matter how the topic comes up, it always makes me sad*.

I used to think other folks didn’t get it. The significance provided by analysts was obvious and self-evident to me. How could managers, executives, teams, and developers not understand all the value BAs add? Can’t they see BAs are the glue that holds these projects together? What would a project be without the contribution of a good business analyst?

Here are a couple important things a BA does on a project:

BAs break down the work in small chunks. This makes work easier to understand and confirm. It also makes developing and testing easier.
BAs document the scope and keep the project on track.

This is difficult stuff. Take a look at results from the Standish Group’s Chaos Report. I’ve put the success rates they measured for software projects into a graph below. We deliver projects on time, on budget, and as expected we only meet those goals about 1/3 of the time. Our success rate is terrible!

Compared to 20 years ago we have made huge strides. Project teams and tools are improving. Failures are trending lower. The project success rate has doubled over in 2 decades! Despite this headway, more than half of all software projects are failing or challenged. Why are there so many struggles? According to a recent Chaos Report, here are the related reasons for our problems. (Hint: You, my fellow BA, are part of the solution)

Failed Project Factors:

Incomplete Requirements – 13.1%
Lack of User Involvement – 12.4%
Lack of Resources – 10.6%
Unrealistic Expectations – 9.9%

Challenged Project Factors:

Lack of User Input – 12.8%
Incomplete Requirements & Specifications – 12.3%
Changing Requirements & Specifications – 11.8%

Do you see what I did there? I bolded some of the key reasons for breakdowns. They are the exact areas where a good business analyst is making an impact. For years I listed all the problems and said, “Look—this is why we need BAs. Analysts help solve all these problems! Our specialty is requirements, specifications, user input & involvement.”

—

I would draw on a whiteboard or give a presentation when I had more time. (See the graphic for a handy example!) I explained the result of few documented requirements was wasted work and missed opportunities. I said how we helped the business explain their needs today. I painted a picture of our goal, requirements maturity.

I would talk about the process of analysis. I spoke about understanding the big picture and little, tiny details. I ranted about tools, the details, and the conceptual steps in between them.

I could pontificate for hours about what we needed to do and how projects would benefit. If all projects had a BA, then we would answer the challenges of the Chaos Report with better documentation.

—

Sometimes I would add more items to the list above while sitting around with trusted colleagues. “Why else do we need business analysts?”

When a project manager is overwhelmed, then BAs are great providing support to the project team and sponsors.
When communication breaks down—and it does all the time(!), then BAs fill in the gaps.
When there is confusion about the scope, requirements, or testing, then BAs are ready with an explanation and helpful hand.

These three items are samples of the other services BA provide project teams. BAs are grease in the gears of the project, allowing it to move forward when it might stick or stall. Many people think project managers handle these responsibilities even when they are overloaded with budgets, schedules, and reports.

Ensuring everyone is working well together and has the same understanding is a great function to have on the team. These things are not a given or automatic response from putting individuals onto a project. These things are . . . squishy.

I know soft skills are the hard skills. I think good managers realize this, also. It is difficult for a Business Analyst to say “I keep things on track.” First, no one believes you. Second, this is not in your job description. Third, this stuff happens behind the scenes and under the radar; not everyone sees it. Spending time making sure teammates get along can lead to people wondering where you add value.

—

Unfortunately, I was answering the wrong question. Sure, the software industry needs better analysis. Yes, 50% of software built is rarely or never used(!). Yes, we had huge gaps between the original goals and delivered software.

So what? Who cares? While interesting to researchers and academics, the topic isn’t about the industry. It isn’t even about your company. It’s about you, the Business Analyst.

Which leads to the central question needing an answer. What do people want to know when they ask, “Why do we need Business Analysts?”

They are politely asking, “Have you been a key reason why this project succeed, or didn’t? Where did you add significant, game-changing value?” Or maybe, “What have you done to justify your salary?”

On the bright side, this set of questions means people expect something from you. They think you can make a difference. This is great news. You have a chance to shine, to excel! When you get this question, share what you have done and how made the project a success. Let them know about your contribution and how it made a difference.

On the other hand, if your team, or boss, or executive is asking this question, then you might be too late. It means people may be questioning what you do and if you can make a difference.

—

Through out the coming year, we will be exploring what it means to add value as a BA, from simple techniques for capturing elicited requirements to the squishier skills that make a difference. So stay tuned and come back.

In the interim, please do me a favor. Do it before you are again asked, “Why do we need Business Analysts?” Evaluate how you are making an impact. Come up with the answer that will let people know you understand their real concern and how projects are better with you involved. And while you’re at it, tell them what you need to make an even bigger impact?

* I see this frequently in environments with a traditional or waterfall SDLC. I do not see this in companies using Agile methodologies. We will talk about his in the coming year, also.

Don’t forget to leave your comments below.