So you want to be a Business Analyst?

So you want to be a Business Analyst?

“Analyst – analyse thyself….”

Introduction

This is what Business Analysts do in the real world when embarking on a new project: they analyse… 

• Why? Why are we doing this project - what is the business problem/need and so what measures and targets for those measures will define what success is. These are known as objectives.
• What? What needs to be done (from business/logical perspective) in order to affect the measures to the point where the project can be declared successful (i.e. it has got the targets) – these are known as requirements.
• How? How will the requirements be realized? What are the rules that will deliver the requirements? These take the form of process models, process definitions, data models, data definitions and various non-functional requirement rules.

So – as any good BA should do when undertaking a new project – analyse what are your objectives in wanting to move to a new career as a Business Analyst.
Put another way, how will you know (once you have done it) that it was a good move to make?

When you know your objectives, deduce the requirements necessary to affect things such that you achieve your target measures for your objectives.
Put another way, what do you need to do to be able to move in to Business Analysis?

When you know what your requirements are, define the process you will need to follow to deliver your requirements.
Put another way, what is the process you will follow to become a Business Analyst? How will each step of each process execute? What data will you need to provide/will you get at each stage of the process?

Throughout this analysis and your progress towards your goal, define as they arise and refine as you progress: 

1. costs to achieve your objectives (e.g. initially you thought around $10k to train as a Business Analyst – actual quotes refine this to $7,040) 
2. constraints that will curtail what you are able to do (e.g. budget and timescales) 
3. dependencies that affect the order and timing in which things can be done (e.g. can’t get the ISEB Diploma in Business Analysis until you have 4 ISEB Certificates in Business Analysis, you can’t get the IIBA CBAP until you have 5 years’ experience) 
4. issues that are outside of your control but are affecting your progress (e.g. availability of training courses) 
5. risks to your career move that may (or may not) arise from the issues (you may not pass the ISEB Certificates or fail the Diploma) 
6. assumptions you are making in the absence of the facts that allows you to make progress (analyzing the RISK that your assumption may be wrong!) (e.g. It is assumed that the ISEB Diploma in Business Analysis is the most relevant professional qualification to get. If wrong, then a number of jobs requiring another qualification could be ruled out).

Defining Objectives

Perhaps it comes down to feelings. You are unhappy in your current business analys role and you aim to increase your happiness by being a Business Analyst. Objective: Increase personal happiness. Target value up to you do define (measured in what units)?
Perhaps it is also down to money – you have reason to believe that you will earn more as a Business Analyst. Objective: Increase personal wealth. Target value $?,???.?? per day/month/year/life?
And then again, perhaps career plays a part: you suspect that you will have better prospects as a Business Analyst. Objective: Increase career prospects. Target value up to you do define (measured in what units)?

Most likely it will be a combination of the above and other measures as well. Whatever your objectives are make sure you define what they are and what value equates to success. Otherwise, how do you prove this proposed career is a good idea?

Example Objective: Increase the reward (not just salary, but also benefits such as pension, car, healthcare etc) of Business Analyst jobs that I am eligible for. Target: Jobs deliver salary and benefits over $90k per annum.

What about objectives that you can’t measure? Happiness might fall in to that category. Status could as well. If you can’t measure them, then they are – in effect – principles you adhere to. Your career move will – in principle – be geared at increasing your happiness but you can’t really measure that and prove that any increase in happiness is solely due to the career move.

Principles are fine where they are a supporting reason for undertaking the career of Business Analyst. Be aware though that any project which only intends to deliver principles can never prove success and having no measures cannot be used to offset the cost of the project. Define principles that really are principles but focus on objectives.

Example Principle: increase my professional status as a Business Analyst - un-measurable.

You will need Objectives (and Principles to a much lesser extent) in order to make the case for the career move to various interested parties (stakeholders in Business Analysis parlance). Examples of these key stakeholders could be

• yourself
• your partner
• your employer
• your bank manager

Basically anyone who can stop you directly or indirectly from becoming a Business Analyst will need convincing to an extent. These are your key stakeholders or sponsors – people (or organisations) that can kill your project to start a career in Business Analysis. Proving that this career move is a good idea should convince them if they are at all rational. The proof will be the quantified benefits of your objectives minus the quantified costs of the move backed up by the reality of the proposal as documented in constraints, dependencies, risks, issues and assumptions.

For this reason, SMART objectives and not principles should convince them:

• Specific (clearly defined)
• Measured (the target that defines that an objective has been achieved)
• Achievable (key stakeholders’ sense check)
• Relevant (they are benefits – not just measures that will change – e.g. you will increase your knowledge of Business Analysis, but as there is no inherent benefit in this it contributes only to becoming a Business Analyst and it is the benefits of that which are of interest to your key stakeholders)
• To die for (this is usually stated as timely or time-bound, but more critical than that is whether you and your key stakeholders actually care about this objective: this measure matters to you and your key stakeholders. You and they will be pleased when the target is achieved. Conversely – and critically – will you simply declare the project a failure if this objective is not achieved?)

If the key stakeholder is not rational (partner?!) flowers, chocolates and flattery might help!

Make no mistake – this is where your proposed career move will succeed or fail because:

1. you are defining what success actually is (objectives and target values)
2. you are assessing the feasibility of achieving your objectives (costs, constraints, dependencies, risks, issues and assumptions)

Make a mistake in any of this and everything that follows based on it will be based on a mistake.

When you have analysed your objectives, if all your key stakeholders haven’t yet agreed to them, make sure they do! If you do not then you could get some way along the path to being a Business Analyst and a stakeholder who has not agreed can pull the plug on the whole enterprise. E.g. your partner can say “I never agreed to you spending that much on training to be a Business Analyst!!!”.

Deducing Requirements

So now you know what success looks like, what capabilities do you need in order to achieve it?

For each objective consider what capabilities you need in order to hit that objective’s target(s).

Example:

Objective: Increase the rewards of Business Analyst jobs that I am eligible for. Target: Jobs delivering salary and benefits over $90k per annum.
Principle: increase my professional status as a Business Analyst – un-measurable

Requirements:

1. I need to be able to prove that I am qualified as a Business Analyst
2. I need to be able to prove that I can do Business Analysis
3. I need to be able to apply for relevant jobs
4. I need to be able to understand IT jargon

What you will find is that one Objective will have many requirements associated with it. And what is more, one requirement will typically contribute to achieving more than one Objective. Those requirements that contribute to many of Objectives are obviously more important than those that contribute to just one, but that doesn’t take away from the fact that each and every requirement exists in order to achieve your agreed Objectives. Lose any of the requirements that do that and you will fail (to an extent) to achieve one or more of your Objectives.

In other words, you can prioritize your requirements: MoSCoW – Must have, Should have, Could have, Would have (or Wish):

• Must have: requirements that contribute to objectives to the extent that failure to have them means the objective will not be achieved
• Should have: requirements that contribute to Objectives but failure to have them will mean still achieving Objectives, but with a lower score
• Could have: requirements that only contribute to Principles (not at all to Objectives)
• Would have: requirements that do not contribute to any Objective or Principle but seeing as you are doing work in this area, if you can, do these. No-one will care (in a measurement of success way) if you do not deliver them

Example:
Given the Objective and Principle above:

• must have requirement “to be able to apply for relevant jobs” – if you can’t you simply won’t be able to achieve the objective
• should have requirement “be able to prove I am a qualified Business Analyst” – if not all relevant jobs need this proof (assumption – check it out and turn to a fact ASAP) then so long as you can apply for some relevant jobs you will achieve the Objective just not for as many jobs as you might have
• could have requirement “be able to prove I can do Business Analysis” as you assume (check it out and turn to fact ASAP) that the job interviews you are going for won’t need this in addition to a professional qualification so it only contributes to the Principle of “increase my professional status as Business Analyst”
  - would have (wish) requirement “be able to understand IT jargon” as it does not directly contribute to either the Objective or Principle but seeing as you’re in learning mode then it would be good if you pick this up as well

Process Rules

So now you know what your requirements are that will deliver a successful move to Business Analysis, what is the process for satisfying each requirement?

In many ways, this is the easiest part of your analysis if and only if your requirements analysis (and therefore your Objectives analysis) is correct. Otherwise, you a deriving a process to deliver the wrong requirements – an expensive waste of time!

Each requirement will have at least one process for achieving it. That process will document the order that the process steps must be taken in, the logic they will execute and the data required during the process. These are all rules that are required by the process in order to deliver the requirement(s) it relates to.

Example:. “be able to prove I am a qualified Business Analyst”.

Process:

1. verify assumptions (the only one made during Objectives analysis that the ISEB Diploma is the most relevant qualification)
   • take a look at jobs postings and determine which professional qualifications they look for most
   • speak to recruiters to see what clients look for
   • canvass Business Analysts (personally and on forums) to find out what they think
   • calculate whether ISEB is the best qualification
   • compare with other qualifications such as the IIBA CBAP – but remember you have to be a practicing Business Analyst for 5 years before you can go for this!
2. research options for training
   • search internet and compare options
   • get recommendations from Business Analysts (personally and on forums)
   • filter by budget and time constraints
   • select training course
3. book on to training course
4. undertake training
5. publish qualification
   • Curriculum Vitae
   • personal website
   • current employer

Now you know what process to go through, you can plan for it, create a detailed budget and execute it.

The key message here is what route you will take will depend on your objectives, requirements and constraints.

Like any project there is no substitute for doing the analysis except wish-fulfillment guess work. Do you want to base your future career on that foundation or do you want to stack the odds massively in your favour?

As I said, this is like any other project…

Author: Guy Beauchamp
Guy started out in IT in 1985 and transitioned to Business Analysis in 1990 - he now works as a trainer for Business Analyst Solutions (www.BusinessAnalystSolutions.com) - a niche supplier of all services for and related to Business Analysis."