Finding Great BAs

Thank g-d we've had a lot of success in our team finding great BAs, and I think a lot of the reason we've managed this is great interview methods.

"Good enough" methods get you "good enough" people.

Thanks to the slow move toward professionalisation of BAs, and the profusion of interview question coaching sites around most people with a decent memory and half a brain won't have any trouble answering the "good" questions.

Any schmuck with Google and time on their hands to know the answers, even to the behavioral questions. Examples are below:

Who do you define a business use case?

Which UML diagram are useful to Business Analysts?

What does the word "requirement" mean to you?

The user wants a new feature that was not previously discussed and you're in UAT - how do you proceed?

"Great" questions for "great" people

For great people you have to go to a completely different level of question. Ones with no "right" answer and lots of scope for follow on questions.

A lot of these are the classic "Microsoft" questions, such as "How would you move Mount Fuji?", "Why is a kidney dish shaped that way?", "What's the best requirement you've even heard?", "My business needs a CRMs - what would you suggest?"

Based on how they response you see if they can:

Separate the "how" from the "why"

Acknowledge and validate their assumptions

Discover your implicit assumptions and needs

Explain their thinking verbally and physically

Really listen to, comprehend, and elicit requirements

Which happen to be all the things that separate good and great BAs.

I've got one question that's a semi-mathematical logic puzzle - but we force people to give their answer on the white board without using words or number. This will tell you in under twenty seconds if someone can put together the explanatory diagram that are so important to any Snr BA or Business Arch.

If you have the time - roleplay

I love to roleplay BA scenarios. Taking a small problem from elicitation, through design, getting interviewees to practice specific skills (Interviewing, use cases, data models, process models, test design, change management, as you go.)

Problem is is takes forever. Half a day is about the shortest amount of time you can do anything useful in.

Lets face it, go with gut

Sometimes you just know within the first five minutes. Really great BAs have a certain way of engaging with people, keeping conversation going, making sure they understand what you say, and being generally empathic while logically rigorous that's just obvious during a short conversation.

Our Results

We've hired people who completely flunked the BA method and skills questions but just gave such awesome interactions during our puzzle section that we know there was something there. Every one of these people has turned out to be a high-performed with just a little bit of mentoring.

On the flip side I've seen people hired who absolutely nailed the BA method and behavioral questions - but who flunked the puzzle section. They're invariably been low performers (for their years of experience) who mechanically replay the same methods, tactics, and ideas year after year. Not a lot of value-add,. Classic case of people having 15 years of experience, but its the same year 15 times over. Great for domain experts - lousy as business analysts.

P.S. All the examples I've listed here are our second-class questions. I'm not sharing out our best ones unless you're looking for a job :).

BA Career Path

There's always a lot of discussion about "BA Career Paths". It's all very interesting but I'm not so sure it's always useful.

I'm not sure the profession is mature enough to provide a real career path for BAs (except on paper). A more pragmatic path may be recognising a real career path is impossible at the moment and focus on providing support for the right on-ramps and off-ramps can be more constructive than defining a formal career path.

The PM shift is a common one, but I've also seen a number of BAs make the switch to Solution and Enterprise architecture, into the business proper, or as strategy/process consultants.

The PM/Architect/BA Troika all have significant cross-over of needed soft and hard skills. Looking at the bullet points of needed skills you've put down for Jnr/Mid/Snr BAs I could use that list for any of the Troika.

I tend to look at BA career "progression" going along three axes, each combination providing a different off-ramp:

Technical vs. Business (Do you get systems working for business, or businesses using systems?)

Project vs. Program (Do you deliver results, or deliver power points?)

Do vs. Control (Are you delivering yourself, or managing the delivery of others?)

There's no intrinsically "Senior" end to any of these axes.

"Snr BA" tends to be different in each organisations - sometimes its the person who sets overall strategy, sometimes it's the person who manages the BAs, sometimes it's the person who elicits the business requirements (In the BABOK sense) and does program of work managements. Sometimes its just someone who's been around for the longest time.

Modelling Behaviour

Whatever type of behaviour you expect from stakeholders, you'll probably be right. The way you act when you expect them to be a certain way (Disengaged, hostile, or intelligent and open) will push them in that direction. Treat people like they already are the sort of stakeholder you want.

I regularly have great engagements with stakeholders who are considered to be "difficult" and it takes is listening to them, treating them like reasonable people, and remembering you're there to serve the business project sponsor - not the IT dept.

The only truly difficult stakeholders are disengaged ones, anyone engaged and passionate enough to cause you problems will probably be a key ally if you can show them that you have their best interests at heart and are there to listen to them, not to dictate a solution.

Deliverables, Objectives & Benefits

When summarising a project and whether it should it's very easy to get mixed up about what information is being presented. It's easy to mix up ideas abut the projects aims, methods, benefits, requirements, and intentions. I like to use a really simple model when describing the one-slide view of a project for business.

It consists of:

Deliver ables: What the project will actually deliver, e.g. a new work flow system.

Objectives: What is the hoped for outcomes of theses, e.g. increased operator efficiency, lowered waiting times for customers.

Benefits: How delivering these benefits will actually the organisations, e.g. Reduced Costs, increased customer satisfaction, compliance with legislation.

These can then be easily linked together. Deliverables contribute to one or more objectives, and objectives deliver to one or more benefits.

You can then quantify how much each deliverable will cost, and how much each objective delivers to each benefit. This feeds straight into your cost/benefit analysis, or more realistically provides a simple way of presenting it that transparently links it back to project activities and benefits.