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.

Why are BAs so undervalued?

Perhaps I have a chip on my shoulder but of the standard Troika that kicks off most projects (BA, PM, Arch) the BA is the most often undervalued role. In every single metric I can come up with to measure organisation esteem (Salary, reporting lines, training budgets) of these roles BAs come out third.

Considering the calibre of BAs in most organisations this is pretty understandable, with little organisational support, no clear career path in, no clean career path up or out, a fledgling professional body, and little formal power over a project it's no suprise that BAs end up being dogs-bodies instead of drivers. This is a symptom not a cause though.

In reality a good BA does more to make a project delivery exceptional business value than any one besides the business representatives. Good project management, architecture, technical delivery, etc, all these help you deliver well, and make it cheaper and faster; but if you want it to be actually better for the users - getting the requirements and functional design right is the way to do it and that's the BAs job.

So why the disconnect between the high value and the low valuation? At source I think it comes down to four things:

A) Most BAs are bad at their job, so even if the good ones are tarred by association
B) Deliverables are not as visible or "epic". PMs and Architects get to produce big gannt charts, architecture road-maps, present to steering committees etc. BAs sometimes get this level of visibility much less often, and generally only as a project representative - not as part of something bigger,
C) No organisational power centre to promote the role, and ensure the wider concerns of BAs get an ear. There's no equivalent of the PMO or Enterprise Architecture office for requirements.
D) Facilitators less valuable than deciders in the eyes of modern business culture. This is the big one. Deciding is just considered more powerful and important than facilitation. The ability to allocate resources and make calls is just intrinsically higher status than the facilitating and agreement promoting role that BAs play. It's just our culture.

Categorising Tools for BAs

People talk a lot about "BA tools" and "Requirement Management" without really defining terms.

I think it's worth at least defining some of the different types of tools that are out there so you can compare apples with apples. As a candidate list:

Collaboration: Systems that help groups of people work together to build a body of knowledge. Word documents on share drives, Wikis, doc management systems, etc in this area. These sort of tools can be used for everything.

Requirement Tracking: Systems that allow BAs to collect "requirements" as a list of statements and then track which are in and out of scope, which are included in a release, who approved them, and the like. These tools are primarily used in the Elicitation and Requirements Analysis knowledge areas. As mentioned Adam's "Bright Green Projects" looks like a great pre-rolled offering in this space. Requisite Pro falls mainly into this camp.

Solution Modelling: Systems that assist you in building a rigorous description of the systems functionality. This covers tools like Enterprise Architect, any of the BPM tools, ERWin, etc. These tools are primarily used in the Solution, Assessment, and Validation knowledge area

Solution Validation: All of the testing tools, coverage, execution, automation that this conversation has been conveniently ignoring.

All of these are "Requirement" management according to the BABOK definition of a requirement - and no tool falls neatly into any camp, but neither does any tool adequately cover all areas.

IBM's suite probably covers every area but it really is a behemoth.

P.S. Tools are the caps one of BA Capability improvement - not the foundation. Tools can often do more harm than good in an immature environment.

BA work is about building bridges between different domains, and tools (almost) invariably hurting in one domain, as much as they help in another. Microsoft office is worse in a completely different way though. Wiki & Issue tracker is a decent compromise - but is also not without problems.

Changing tools without a mature BA practice will likely just leave you with a new set of problems and higher monthly licensing costs. I would strongly suggest that the money and time you could spend on tool setup is better spent setting up a BA Community of Practice and put on a spread so your BAs can tell War Stories to each other over lunch.

Plan vs Change Centric

The definition the latest BABOK has for Plan and Change centric project delivery methods is very useful. It's not exactly ground breaking to break methods/processes into different camps based on whther they are Agile or Waterfall - but the terms are pretty loaded. I think these terms capture the essential differences between these two camps.

It's not that one camp has different component tasks, it's just that one puts the plan as the central tool for delivering change, the other puts the change being delivered at the centre of planning.

You see this really clearly in the way that BABOK 2.0 describes the Requirements Anlysis tasks. The same basic activiteis are always done, but how and when they are done changes depending on process.

It's just nice to have a neutral non-emotive term.

It also reinforces that good BAs are good BAs regardless of methodology. If you know how to do it right for Waterfall you're going to be able to hit the ground running with Agile. The hardest bits don't change. Empathy, communication, listening, lateral thinking, modelling, and problem solving are always the core-skills.