BA Skills: Wibbly Wobbly…Timey Wimey…Stuff-EN

I’m a second-generation Dr. Who fan. For those of you who aren’t “Whovians”, Dr. Who is a Time Lord who crosses through space and time in his TARDIS – a time machine cleverly disguised as a bright blue phone box.

In a classic scene, Dr. Who is attempting to describe time. Instead of being linear, he says:

“….it’s more like a big ball of wibbly wobbly…time-y wimey…stuff.” – David Tennant, the 10th Doctor Who

I can sympathize with Dr. Who’s lack of eloquence here, because I have the same problem trying to describe business analysis and the role of a business analyst. If I had a dollar for every time I’ve gotten the following question from a student, I’d be rich, retired and living on an island somewhere:

“OK, but is that really the BA’s job? Shouldn’t the (fill in the blank with another job title here) be the person who does that?”

I think lots of people wish there were nice, neat, non-overlapping, industry-standard definitions for certain roles.When there was “stuff” to do on a project, we could simply look at this chart and say, “Aha! That “stuff” belongs to the SME!”.

Sadly, real life just isn’t that neat. So most people are willing to accept that roles might look more like this:I think truly successful teams realize that it really looks like this:High-performance teams don’t rely on a set of predefined roles. Instead, they figure out what “stuff” needs to be done, and they allocate that “stuff” to the team member best suited to do the work. This is true whether the team is using an agile approach or following a more plan-driven approach.

So wait….am I saying we don’t need BAs? That we can just give the BA “stuff” to other people on the team?

What I’m saying is that I don’t care what your title is. And I don’t care what your teammate’s title is. Somebody on your team needs to be responsible for the analytical “stuff”.

In agile projects, this “stuff” is typically identified at the beginning of each iteration or sprint:On plan-driven projects, the “stuff” may be organized in a RACI matrix, or some other formal planning tool:Bottom line? Don’t worry about your title. Don’t worry about pre-defined roles. Worry about getting all the “stuff” done. And worry about improving your analytical skills so that you can be the go-to person for all the analytical “stuff”. After all – it’s the most fun “stuff” on the project.

Core BA Skills

So what are those core ba skills? Well, here at Netmind, we think there are seven of them:

1. Process Analysis

Someone once told me that the six most expensive words in business are “We’ve always done it that way.” Automating an inefficient or error-prone process without doing thorough analysis just means that you’ll make the same mistakes….only faster.

I wrote a blog a while back challenging readers to become part of the 30% of teams that make successful process changes and walked through our Framework for Process Improvement. I now challenge you!

2. Business Rule Analysis

I frequently find business rules to be humorous. I especially like to pick on airline websites – my first job out of college was at TWA, and I fly a lot, so I tend to find airline rules amusing:

• You’re allowed one carry-on bag and one personal item in all cabins. (So I can put one of each in coach, and in business class, and also in first class? Excellent! Oh – and by the way, can I count my husband as a “personal item”?)
• All baggage fees are non-refundable and apply per person, each way. (Wait – if my husband and I are traveling, and we share one checked bag, we each get charged a baggage fee?)
• You can only travel with one life jacket as checked baggage, but it may be confiscated by the TSA. (OK, I’m completely confused. Can I travel with a life jacket or not?)

But seriously….business rules require detailed analysis. And they tend to change frequently, so it’s important to isolate them from other requirements components so you can manage that change effectively.

3. Stakeholder Analysis

Stakeholder analysis is so much more than making a list of names, titles, and roles. Thorough stakeholder analysis can dramatically improve engagement and participation, and it can help your team work together more effectively.

4. Interface Analysis

I can’t think of a single project I’ve worked on in my career that didn’t have some interfaces involved. Human interfaces, system interfaces, data interfaces, hardware interfaces….all of these have to be thoroughly analyzed and understood by the team.

5. Data Analysis

All too often we treat data as an afterthought in analysis. But without data, processes can’t be performed. Interfaces can’t display and collect the right information. Reports can’t be produced. And don’t get me started on data transformation and migration – those can be so complex that sometimes they become projects in and of themselves.

6. Establish Context

Where does your project fit? Who all will be affected by what you do? What are the limits of your team’s responsibility and authority? What is it really that the organization wants you to accomplish? How will you know if you’ve done that? If you can’t answer these questions about your project, it’s time to take a step back and understand your context.

For help on establishing context, check out our instructor Heather’s 4 Step Process for Considering Project Context.

7. Elicitation

Version 3.0 of the BABOK identifies 18 different techniques for elicitation. That’s a lot! Are you considering all of them? Or are there a handful of “comfortable” techniques that you rely on? I always tell my classes, “There is no one-size-fits-all in elicitation!”

Supporting BA Skills

In addition to these core analysis skills, we believe that there are 4 supporting skills that are necessary to be successful in a collaborative team environment:

1. Communication

“I know you think you understand what you thought I said but I’m not sure you realize that what you heard is not what I meant.” – Alan Greenspan, former Chairman of the Federal Reserve of the United States

Thank you, Mr. Greenspan. Can you explain that again?

2. Decision Making

Getting a group to make a decision can be really challenging. As analysts, it’s typically not our job to make the decision, but it often is our job to facilitate a group that needs to make one. Remember to think through:

1. Who needs to decide
2. When the decision is needed and
3. A decision-making approach (such as consensus, compromise, or voting)

Putting a group in a room together to “discuss options” and “make a decision” almost never works unless there’s a process in place to support the decision-making.

Download our free Decision Making Template to help plan and track your project decisions.

3. Critical Thinking

Critical thinking has become something of a buzzword these days. You can find a dozen different definitions on the Internet. To me, it’s really the heart of what we do as analysts. We question. We dig. We use logic to reach conclusions. We try to avoid allowing preconceived ideas and thoughts to interfere with true understanding. We propose and test theories. And if we try something and it doesn’t work, we figure out what went wrong and try again.

4. Planning

Ready…fire….aim!!!!

No. Just…no. If you’re still jumping right into your projects without any planning, take a pause. Plans don’t have to be long, detailed, or formal to be useful. They’re great thinking tools to help us make the most of a limited resource – time.

[box]We’ve compiled the data from a survey we did asking our community to determine if their team had its “stuff” together. Get the results and you see what signs your fellow BAs agreed with and our advice on how to overcome the most common. [/box]

In the meantime…whatever you do, don’t blink!

All the best,
Kathy

P.S. – Watch this if you don’t get the reference about blinking.