Transition into a Business Analyst Role

October 10th, 2009

Many people have asked me through emails to advise them on how to make a transition into a Business Analyst role.

The folloiwing is a recent email i received:

Kalyan Kumar wrote:

Appreicate your help in helping me in Transition, I’m in to people management role and Client relation for a body Shoping company helping in placements. I’m an MCA graduate and keen about getting in to Business analyst role. I’ll be happy if you can help me as It’s becoming a big questin for me where to start and how to start.

I would suggest that read about Stakeholders Management and it’s techniques as you are moving into client facing role – which is always a tricky bit for a Busienss Analyst. I have wrote couple of blogs on Stakeholders Management. 

Also is a good source of information and do study some books as well. I would recommend ISEB Business Analyst book by Debra Paul and then further study could be IIBA’s BABOK but that’s for senior stage.

You should understand about interview/workshop techniques for analysis.

Always have a good understanding of client’s business beforehand so you could feel comfortbale why seeing them first time. Client always appreciates an Analyst having a good grip on their business domain and showing it to client during meetings.

Good luck with your transition.

Above blog is mainly about Client facing role but somehow it covers any kind of Business Analyst role. Business Analyst role has multiple facets and i would try to cover them off in my future blogs.

Looking for a few good Green Business Analysts

October 6th, 2009

Agile Business Analysis

September 3rd, 2009

You open a Business Analyst website like, read blogs or receive a digest email from Business Analyst groups and communities; Agile Business Analysis is a hot topic coveredin blogs or discussed in groups/communities these days.

This blog on Agile is actually to keep myself into this Agile Season and to give my readers an idea about Agile Business Analysis.

By using Agile methodolgy, project deleivery is chopped up into short iterations – one-to three-week timeboxes depending on the project lenght. Each timebox begins with an iteration planning workshop in which the customer decides which wok should be delivered.

It is the cutomer’s responsibility to select the highest priority requirements from the requirements catalogue.

The selected requirements are built by developers and demonstrated to the customer. During the User Acceptance Criteria, preparations are made for the next possible iteration.

Most of the companies currently not practising Agile processes. There are advantages and disadvantages of using Agile iteration technique. But one thing i should emphasize on is to keep the balance on iterations. The overall project scope should not go beyond the control limits.

In my next blogs, i will write about How Agile Practices Reduce Requirements Risk.

Happy reading!

Business Analysis Conference London 2009

August 15th, 2009

The first ever Business Analysis Conference is going to be held in the UK, during 28-30 September 2009 at the Radisson SAS Portman Hotel in London.

Please visit conference provider’s site at for more information.

Functional Business Analyst

August 4th, 2009

Recently, I have been given a new role of working as a “Functional Business Analyst”.

That was a new aspect of the business analysis to me. As a Functional Business Analyst you are taking all the responsibilities of a Business Analyst but mainly concentrating at functional side of the systems and processes.

And I am enjoying it so far:)

Buiness Analyst Humor

June 3rd, 2009

Buiness Analyst Humor

Managing Stakeholders Perspectives

May 31st, 2009

This summer i want to write mainly about stakeholders of a project.

“Any person who has some interest in a project or influenced by that project is a stakeholder of that project.”

In this blog i want to discuss about Stakeholders prospectives which is always a very tricky exercise for a Business Analyst.

A perspective is an overview and understanding of a stekholder about an organization or a specific situation. For example, in a bank, a cashier can think it important to give best services to customers. But a marketing director can think about giving best marketing services and sales of the bank. Here a cashier has a different perspective and a marketing director of the same organization(bank) has a different perspective.

A useful framework to manage stakeholders perspectives is CATWOE.

C – Customer

A – Actor

T- Transformation

W – World View

O – Owner

E – Environment

Stakeholders perspectives can be modelled using Business Activity Modelling(BAM) technique which i will discuss in my next blog.

Books for the Business Analyst

May 21st, 2009

A list of Business Analysis books to read:

Click here

I have recently read ISEB Busienss Analyst book by Debra Paul. This book is available to buy from British Computer Society and from Amazon as well.

Good luck with your reading.

Competencies of a Business Analyst

May 19th, 2009

A competency is something a business analyst needs in order to perform his or her job effectively.

The set of business analysis competencies can be divided into three broad groups.

  • Behavioural skills and personal qualitie
  • Business knowledge
  • Techniques

Behavioural skills are arguably more important than technical or business skills, as they are prerequisite for working with other people.
It is often said that it is easier to give a person with good behavioural skills the techniques needed for a job than to graft behavioural skills on to a good technician.

Typical Problems with Requirements Analysis

May 1st, 2009

The following are the typical problems which causes a poor requirements analysis:

  • lack of relevance to the objectives of the project;
  • lack of clarity in the wording;
  • ambiguity;
  • duplication between requirements;
  • conflicts between requirements;
  • requirements expressed in such a way that it is difficult to assess whether they have been achieved;
  • requirements that assume a solution rather than state what is to be deleivered by the system;
  • uncertainity among business users about what they need from the new system;
  • business users omitting to identify requirements;
  • inconsistent levels of detail;
  • users and analysts taking certain knowledge for granted and failing to ensure that there is a common understanding;

The first point often results from a lack of terms of reference for the project. The eighth difficulty, that the users are uncertain of their needs, is by no means uncommon in a world of new business practices and enw technology. The business analyst is the person who must help the users to visualize precisely what they need the new system to perform and then to articulate it.

Another source of diffculties for the business analyst is recognising the different viewpoints behind each user.

A Business Analyst therefore must be very careful about requirements analysis as a large proportion of errors are introduced at the requirements analysis stage. 

The above detailed points are taken from ISEB Business Analysis book by Debra Paul. While studying the Requirements Engineering chapter, i found it worthwhile to share these points with you:)