So you want to get a job as a Business Analyst? Here are the things we look for.

We’ve written a few blog posts about how to be a sucessful BA.

But people often ask; what do we look for in a BA?

One of our biggest challenges is finding good Business Analysts and Product Managers. We interview a wide variety of individuals but it’s really tough to find good hires. Since we specialize in such a detailed field we really have to look for specific skills. Having relevant experience and having consulting experience does not suffice.

Our interview processes is also a bit more unusual than most companies. We start off by having the candidate fill out a questionnaire, we conduct a phone interview. Then we have two onsite interviews that are more specific to job required skills for the business analyst and product management job.

This process is more thorough than most; however we feel we can get a better feel for the candidates’ background and culture fit by doing these series of evaluations.

During this whole process we look for certain skills at each step. If a candidate does poorly at any of these steps, we won’t move him/her on though the remainder of the process.

All throughout the interview process we ask ourselves:

Do they have strong analytical skills?
Have they written software requirements documents before?
Are they detail oriented?
Are they a good cultural fit?
Do they have any consulting experience?
Are they coachable/ trainable?
Are they personable?
Are they professional?
Would I like to work with this person?

Answering ‘yes’ to all of these is a rare find.
Most important to us: we have to have BA’s and Product Managers who possess strong analytical skills, are very detail oriented, solid technical skills and are someone we would like to work with.

Mission Elicitation - Phone Meetings

The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a scribe, and a computer to complete your task, good luck.

I have a feeling that most meetings like this fail to meet their real goal, identifying the majority of gaps. A major implementation that requires gaps to be identified often have one big kickoff meeting where you were able to get all the important people to free their schedules. Of course, they couldn't be all in one place, so you have to meet over the phone. This can be disastrous. Not only does everyone over the phone lose context around presentations and discussions, but the people forget who is on either side of the phone. White boarding turns into phone charades. Scribes miss out on who said what. To-Dos are lost in the background noise.

Okay. Take a moment and breath deep. Think of pleasant things, like pre-existing documentation, SMEs that agree on the existing and future business processes, and meeting notes that make sense when you go back to read them.

Relaxed now? Alright, lets make sure we prevent as much of this as possible. There are several steps to mitigate as much trouble as possible. If at all possible, get a tablet pc for the meeting. If that is not going to happen, make sure you have access to a process mapping tool such as Visio. Secondly, make sure you have an online collaboration tool such as Go-To-Meeting, WebEx, or MS Live Meeting. If you don't have one of these tools, get a trial or find an open source (read: free) solution. The ones I mentioned would be ideal since your client will most likely have them already installed which means that there is less of a chance that the first 15 minutes of your meeting will be people discussing which button someone should have clicked instead during the install. Finally, find a scribe. If you do not have someone on your team who can help you, you might have to ask a participant to help you scribe while you try to facilitate and elicit.

Alright, you have your basic tools. First order of business, send out the meeting invite. Don't make this the standard meeting invite you see everywhere else, subject line and no description. Make sure that you include the objective of the meeting and the rough agenda. Step two, make sure everyone is introduced over the phone. Always good to go over who is in attendance and the role they are playing in the meeting. While introducing everyone, it is wise to have the meeting objective and agenda displayed on your projector and online screen sharing tool of choice. Make sure that you are located close to the phone so that you can repeat what was asked or stated and by whom.

While the meeting is going on, be sure to bring up a notepad or word doc on the screen to jot down any action items that come up. Be sure to write down who owns the task and their contact information if you do not already have it. Just having the task title isn't a nice thing to come back to and try to figure out, so add some context. Simply writing down "Get everyone's buy-in" is tempting, but please include the people involved in 'everyone and on what document/process the buy-in is needed on. At the end of each day, send out your notes to all the participants along with the list of to-dos to the owners. You might have to keep track of the to-dos and make sure their owners complete them.

When a white boarding session strikes, pull out your tablet pen or Visio program and start tossing up a copy so that everyone is involved. Much easier than describing which line connects to which box that resembles something more of a rhombus. Doing this will allow for the people over the phone to quickly understand the topic being discussed and add in their knowledge to the debate. True kudos if you are actually able to secure or setup a webcam that will allow you to broadcast the white boarding, removing the lost in translation possibilities.

These are just some basic pointers to holding elicitation meetings over the phone that can save headaches and money for your project. Do you have any phone elicitation pointers or standard operating procedures?

Why Bother?

Why even bother? When's the last time you asked yourself that? Was it something trivial -- "Oh, I forgot to get canned lentils on aisle 6, but I'll be back in the store tomorrow, so why bother to go back and get them now?" Or was it something more meaningful, like, "Nobody ever reviews my process flow diagrams for this project, so why bother to spend any real effort on them?" Hopefully the majority of your "why bothers" are trivial, but I'd expect there's a more serious one every now and then.

My personal favorite "why bother" is around making the bed. I've had this argument with every person I've lived with for decades now, from my mom and dad, to my college roommate, to my wife. For the longest time, I simply couldn't see the point to making the bed! I go to sleep at night, get up in the morning, and then will go to sleep at night again ... so why do I need to make the sheets neat and tidy for a few hours in between? Their answers, invariably, were "because it's the right thing to do," and I simply didn't buy it. It wasn't until I saw a more personally meaningful benefit that I believed in the importance of making the bed.

So what does my opinion on making the bed have to do with requirements? Well, probably not much ... but hopefully it'll provide a good parallel with a common frustration on requirements projects. It's easy to get caught up in the day-to-day challenges (aka frustrations) of software development efforts, and when you're caught that way, it's easy to have those challenges carry over into your perspective on your own work. At home, you may feel like you're already doing too much housework and making the bed is just one more chore you're too tired to do. At work, you may feel like your deliverables don't matter, or like there's nothing you can do to have a positive impact on the project, or like ... well ... why bother?

If you've been involved with requirements engineering for a while now, this may sound like an all-too-familiar scenario. I know that I've found myself feeling this way more often than I'd like over the years. What I've discovered, though, is that these "why bother" moments are opportunities for me to learn and, more importantly, make a positive impact on my project.

Chances are that if you're feeling frustrated, others on the project are too. If you can recognize the challenge, you can use your requirements role to help shake the entire project out of its slump. Play games in your next requirements workshop. Bring cookies to a document review "just because you think everybody deserves a cookie." Open a meeting by saying that you don't see any reason to keep creating requirements and see what the reaction is (OK, maybe this one isn't the BEST idea!). By shaking yourself out of the "why bother" mindset, you make a difference to the other people on your project, and hopefully you can also see how your work makes a difference to those people and the overall project itself.

One simple change of perspective can impact countless numbers of people - and that's why we bother.

(Editorial Note: I now DO make the bed, and I do it because it's important to my wife, it's what I want my son to learn to do, AND it's the right thing to do!)