Business Analyst

summonerm

Hi guys,

I would really appreciate your opinion on this. I came to Ireland 2,5 months ago and I'm trying to find an IT BA job. I have 7 years of experience and don't have any unfinished projects behind me. I've been communicating with several recruitment agencies and my CV was sent to several companies, I'm still awaiting for a feedback.
Now, I have several things that bug me regarding a company's eagerness to hire me, and would really like your opinion:

1. I had a certain amount of freedom on my former job while performing BA, and I didn't bother with drawing of use cases, state, activity, or any other diagrams. I had my way of making notes through communication with end users, and based on them prepared detailed instructions for developers, with user interfaces, the entire background DB design, control messages and the entire logic of a future application or a part of it. Although I think that making of UML diagrams is a matter of practice and shouldn't be hard to learn, my question is: Is that a serious obstacle for finding a BA job? How should I behave on the interviews regarding that? Point it out as a weakness?

2. There's a standard question asked by recruiters: Are you more on a business or a technical side? I answer that I'm equally good in both, since DB design, UI design, detailed programming manuals, and report creation through use of complex SQL queries are in my opinion considered as technical stuff, while gathering requirements, understanding them and organizing them in my head, and being a point of contact for users during the entire SDLC and after, are considered as business part of a BA. What is your opinion?

3. Although I gained my experience in the insurance industry, the nature of my job was to perform BA on various areas - financial, HR, law, and insurance. Therefore I can adapt to any business environment and solve any problem because that is what I do, when having enough information at disposal. The only thing that would be somewhat difficult is to be familiar with a glossary each of these areas use, especially because English isn't my native language. But I guess I'd learn it while the project lasts. So what are my chances to find a job in a sector different from insurance, in your opinion?

Sorry for such a long story, but I obviously have a lot of free time, since I've been trying to find a job for 2 months already. Any help\advice would be greatly appreciated

LuckyCharms

Personally, i would be applying directly and tailor each application specially to that job.

Are you having trouble getting interviews or getting job offers? What's your CV like, how long, what do you focus on. Do you submit tailored cover letters? Do you apply directly or just contact the recruiters?

So if you are applying for a BA job where the main focus is on user requirements, uat, testing etc, then focus on your abilities on those specific requests with examples to back it up.

Being well rounded is great but companies look for specific abilities, you being able to complete 5 out of 7 of those but having another 5 completely unrelated proficiencies isn't going to land you the job over someone who matches 7/7.

The above information is obviously tailored towards getting an interview, after that it becomes more about selling yourself and hitting the competency marks that the company is looking for.

Mrs OBumble

summonerm wrote: »

1. I had a certain amount of freedom on my former job while performing BA, and I didn't bother with drawing of use cases, state, activity, or any other diagrams. I had my way of making notes through communication with end users, and based on them prepared detailed instructions for developers, with user interfaces, the entire background DB design, control messages and the entire logic of a future application or a part of it. Although I think that making of UML diagrams is a matter of practice and shouldn't be hard to learn, my question is: Is that a serious obstacle for finding a BA job? How should I behave on the interviews regarding that? Point it out as a weakness?

Don't mention it.

There are a zillion different methodologies out there. Your job is simply to use the most appropriate one for the situation. If the company has a preferred approach, you need to make it work for whatever you have to do.

I've recently gotten to grips with writing everything as "user stories": the stories are bollox, the real work is in the ultra detailed "acceptance criteria" that goes along with them. It upsets some people that I insist on writing them down ... Agile zombie quote "you don't really need to document that, so don't" ... but I do it anyways 'cos writing it down is how best to think it through.

I'll do DFDs, Information Engineering noun and verb decompositions, swim-lane diagrams, process models, use-cases, user stories, sequence diagrams, product requirements docs, functional specifications - whatever anyone wants if if helps communicate and get to grips with the mess that is most people's ideas.

jimmycrackcorm

No BA I've ever worked with had used UML. All BA's have necessitated good oral and written communication, so I think your level of English will be called into question.

Two months is not a long time in the job seeking process, in my experience three to six months is normal.

I also think having a balance between technical and business sides can be a disadvantage. I've worked with great BA's, none of which had a clue about SQL. Trying to be all things to all men probably is a negative in the interview.

beauf

jimmycrackcorm wrote: »

....I've worked with great BA's, none of which had a clue about SQL. Trying to be all things to all men probably is a negative in the interview.

I think being a BA is about being very organised, able to master details and information, and professional. You're either that kinda person or your not. You don't have to start the project with the exact business & technical knowledge but you need to be able to grasp it quickly. At least the relative importance of issues. If take the project longer if the BA has to come up to speed though, and there a risk something might be missed.

BA's and Managers with no technical knowledge on a technical project or more correctly the aptitude to pick it up, can be a disaster.

summonerm

Thanks for replies, everyone.

LuckyCharms wrote: »

...

I still haven't been called to any interviews but my CV was sent to several companies, hopefully one of them will show interest. I'm mostly applying through agencies, with cover letter included, but I got the impression that they don't actually read it. I think that they simply skim my CV, look for keywords and check the percentage of matching between CV and the position I've applied for. If I get to the point of applying directly to companies, I'll adapt my CV based on the desired competences.

Mrs OBumble wrote: »

...

I can see that you're mostly using the Agile methodology. I've never tried it but I'm familiar with it theoretically, and I'd really like to gain some experience in it. I noticed that many ads are asking to already possess a knowledge of it, and it seems like my eagerness to learn it doesn't mean anything, since I assume I'll be immediately disqualified

jimmycrackcorm wrote: »

...

So do you think my level of English is inadequate for this position? Could you at least point out the critical errors I make so I can try to improve them in the future?
If my situation remains unchanged, I'm going to find a job in a warehouse or something because my budget is seriously melting, while keep applying for BA positions.

beauf

summonerm wrote: »

...I've been trying to find a job for 2 months already. Any help\advice would be greatly appreciated

I've rarely seen UML diagrams used. I would say things like use cases, state, activity, or any other diagrams are important, and all the things Mrs OBumble mentioned, can be very important depending on who you are dealing with. Often a diagram is more useful than 20 pages of text.

However there is a move to a qualification for everything. As such a lot of HR and agencies will filter on qualifications. So in that regard its a problem. Even if a lot of these qualifications aren't that useful or a good indication of BA ability.

Though you could argue the ability to complete courses is a measure professionalism, but some people can complete course after course and not be great in real environment. HR and Agencies don't care about that though. Its about box ticking.

beauf

I've worked with people who've obviously done some of these courses and worked in a very formal environment. They love using all these formal process and often there are project and/or payment milestone associated with them. But often they just have no head for detail or doing the work in real life.

I think you might need to go back to the basic of job hunting. Tailor your CV for every job. Target the job you apply for. Don't have a generic CV and spam every job ad. The usual stuff.

summonerm

beauf wrote: »

I would say things like use cases, state, activity, or any other diagrams are important. Often a diagram is more useful than 20 pages of text.

I completely agree that diagrams are way more descriptive than numerous pages of text. I just didn't have to make them and therefore don't possess formal knowledge of creating them. I guess I can simply hope that there's at least some inhouse training provided, or that I'll have a helpful colleague or two. As I've said, I think it's a matter of practice, hopefully I'm not wrong. Also, I cannot give up on the idea that your mental capabilities to analyze business process and find an appropriate solution is more important and harder to acquire than being familiar with diagrams. Again, let's hope I'm not wrong

beauf wrote: »

I think you might need to go back to the basic of job hunting. Tailor your CV for every job. Target the job you apply for. Don't have a generic CV and spam every job ad. The usual stuff.

Sure, but since I'm mostly applying through agencies, you know how it works, my CV is being put in a DB and gathers the virtual dust. For that reason, it has to be somewhat generic. I will change that when applying to a firm directly.

beauf

summonerm wrote: »

... Also, I cannot give up on the idea that your mental capabilities to analyze business process and find an appropriate solution is more important and harder to acquire than being familiar with diagrams. Again, let's hope I'm not wrong

The diagrams are also used to get user acceptance, buy in. To communicate with other people. To agree the process.

summonerm wrote: »

Sure, but since I'm mostly applying through agencies, you know how it works, my CV is being put in a DB and gathers the virtual dust. For that reason, it has to be somewhat generic. I will change that when applying to a firm directly.

Tailor it for agencies too. They want an exact match. They don't read between the lines. Well most of them don't.

Mrs OBumble

summonerm wrote: »

I just didn't have to make them and therefore don't possess formal knowledge of creating them.

There's a logic error right there.

You didn't have to make them, therefore you don't have recent professional experience making them.

But that doesn't mean you don't have either formal knowledge (read a book about or a few articles) or some experience (write a use-case for using the kitchen to cook dinner, draw a sequence diagram for opening a bank account, whatever ...).

fret_wimp2

On diagraming and UML:
UML has been used on many projects i have worked on, across many companies. Its just a method of diagramming out requirements to make them easier to understand. A simple diagram can visually articulate what many pages of text will never get across to a developer.

Should a BA be expected to know it? Depends on the role, if the spec specified it, but as a guideline i would say no, but its a distinct advantage. A BA has to straddle the fence between business and IT a lot of the time. UML gives you the ability to articulate a business problem to IT with a lot less room for ambiguity and a lot more understanding of the problem /solution.

Its a great tool to have in your belt to be comfortable with and be able to discuss the diagrams and where you would use each to best effect.

On the business/technical question:
Its a fair question. Ive worked with a lot of PM's and BA's, some have zero IT knowledge and this can be quite a handicap when trying to relate requirements to an IT team. You dont need to be a coding guru, or be able to performance tune a database, but high level knowledge of IT and how all the parts fit together are necessry for a good BA/PM to do their job. I know BA and PM are different roles, but i see them on may projects as interchangable and both need an understanding in IT.

Its one of the reasons you are there after all, otherwise the business would just talk directly with IT and no extra costs for a BA or PM would exist!

It woks in reverse also, a hard core IT person with zero business knowledge would be equally as handicapped at identifying requirements and mapping them to actual work to be carried out to solve the problem.

On experience in one or more industries:
Of course more experience is a plus, but nobody ever has all the experience for a new job. You just need to prove in an interview and on your CV that you are adaptable, and also how your current experience makes you ideal for that job. Sell yourself. market yourself correctly.

beauf

fret_wimp2 wrote: »

On diagraming and UML:
UML has been used on many projects i have worked on...

Out of curiosity, have you ever seen a BA use it who doesn't come from a development background? I've only seen developers use it. Or a developer in a BA role. I've never seen it used outside of IT projects either. Have you seen it used by non IT people modelling non IT processes/systems.

fret_wimp2

beauf wrote: »

Out of curiosity, have you ever seen a BA use it who doesn't come from a development background? I've only seen developers use it. Or a developer in a BA role. I've never seen it used outside of IT projects either. Have you seen it used by non IT people modelling non IT processes/systems.

Yep, its just as useful to model business processes that would take many pages of writing to articulate.

It gets used more on IT projects as IT folk like diagrams, and its very easy to relate IT requirements using diagrams.

Forget IT or business for a sec. Which would you rather, a diagram showing a process which you can comprehend within 30 seconds, or 3 pages of detail that you need to read 2-3 times before you have half of an idea of whats required?

IMO, the better BA's will use it as a tool regardless of the project.

beauf

I've been using diagrams for decades. But almost never UML. But found no-one other than developers could read it properly. Even then not all developers.

Regardless, if I was applying for jobs as a BA, I would refresh my UML and model some systems with it, so I could tick that box on the CV, and handle any questions on it.

Eoin

summonerm wrote: »

2. There's a standard question asked by recruiters: Are you more on a business or a technical side? I answer that I'm equally good in both, since DB design, UI design, detailed programming manuals, and report creation through use of complex SQL queries are in my opinion considered as technical stuff, while gathering requirements, understanding them and organizing them in my head, and being a point of contact for users during the entire SDLC and after, are considered as business part of a BA. What is your opinion?

I'm not sure that your interpretation of the business side of things is what they mean - what you're describing feels like an essential part of the role of a BA who produces software requirements.

But not all BAs produce software requirements - and I think that's what they're asking. A BA in one company might be asked to look at the business processes, and a BA in another company might be asked to put together a business plan that's very commercially focussed.

Mrs OBumble

beauf wrote: »

But almost never UML. But found no-one other than developers could read it properly. Even then not all developers.

This plus lots.

A job I was in a few gigs ago wanted to get into it, so I started learning UML along with the rest of the team. But the business just didn't get it, so the UML was useless for communicating with them - which was the guts of my job. So I gave up on it.

One of the issues is that there are about 9 (?) different types of diagrams for describing different aspects of a system, and you have to know them all and understand what to use for what.

My last job did use sequence diagrams (and I've even contemplating introducing them to something I'm working on now) - but that's the only part that I've found to be of ongoing use.

Oh - and while a picture paints a thousand words, you actually do have to write at least of 500 of them anyway, to make sure that everyone who looks at the picture understands the same 1000. Diagrams are very important, but they don't do the job alone.