TSM - The First Step in Business Analysis

As I mentioned in the article called “Business Analysis Framework” of the 26th issue of the magazine, I will continue the series of articles in this area. The topics of my future articles were concisely presented in the form of steps and diagrams in order to provide a consistent overall view both for a business analyst as well as for any other member of the team who fulfils these responsibilities. Within the same article I was mentioning orientation as the first step that a business analyst should take when starting a new project.

How should a business analyst orient? This is the topic of the present article, and I consider it to be an important one, since it is during this step that certain expectations are involuntarily set and each part involved lines up to the start position for the project. I consider this step as an informal one because of the fact that it is not documented anywhere. Orientation is not part of any process and I found no books to describe the way in which a BA should prepare even before beginning to write the requirements. This step is all the more important as the BA role on the project is a new one and it is not clear yet what responsibilities fall on him.

I would like to draw a parallel here in order to make myself better understood: in sales there is a first step called market research (or prospecting).

Prospecting is the set of means which facilitate getting into contact with the potential clients who need the products and services you offer. This is the perspective you also have to consider for business analysis. You can find, indeed, support on planning an approach on the business analysis side (BA project approach), but this corresponds to the 3rd step on the diagram above and it refers to tasks/ activities, techniques or defining the deliverables for the project.

I don’t wish to anticipate the future articles too much and I come back to the informal orientation step which we want to carry out successfully.

The information you need to know is presented below.

On the team

I am talking here about the developing and testing teams in the case of companies where the departments are separate and about the SCRUM team, in the case when they are working cross-functionally.

The new business analyst role in the team might set some very diverse expectations among the colleagues and the other parts involved. Some colleagues may have already worked with a business analyst before and, as well, they may not know his attributions very well. Each member has a different perspective and experience which can help you get the requirements as complete as possible. Collaboration within the team is the key factor which will bring about the success of the project.

In order for things to unfold as smoothly as possible and for the results to be at least according to expectations, try to understand the expectations of each member of the team.

You can find below some guiding points which may help you to better figure out the expectations the others have as far as you are concerned:

• the seniority of the team members working on the project (the advantage of a newer member is that he can come up with new and creative ideas, while a senior member can give you more details on their work history and how things have evolved).
• how each of them shares and organizes their work.
• what exactly they most like about their current working manner and what it is they would like to change.
• which problems occur frequently in the current requirements.
• the way the requirements are received and who contributes to them.

On the client

The client will have a different image for almost every member of the team, according to the manner and the context in which the two parties have interacted. Some of them may be disappointed, but from my experience so far, the expectations of the developing team to have a technical client cannot be fulfilled but to a rather small degree.

The client is, in most of the cases, business oriented and he will set the direction to be followed both on the business side and on the technical side. The requirements are most of the times business ones, and by no means technical. The later have to model upon the business requirements, and not the other way around.

The main objective for a business analyst is to understand the business need based on which the development is carried out and to successfully fulfil it.

In order to clear things out right from the beginning, you can do the following:

• create a list of all the involved parties and include their importance and degree of implication in the project (Stakeholder Matrix) – ask the project manager for help.

• design a communication matrix and validate it with the project manager. Here, the following valuable pieces of information are included:

  • everyone’s role in the project

  • who communicates, what and when

  • who do you have to communicate with and in what situation.
• find out how the client is used to communicate with the company you are representing and how often.
• find out what type of communication is mostly used and in which situations: written, face to face, within video-conferences or teleconferences.
• which are the points he wishes to improve
• find out whether they are open to solutions from the part of your company or they wish to have it all done according to the book, on their home model.
• search the history of the client and his relationship to your company.
• find out the future plans the client has in connection to the product you are developing.
• who is the final client and what influence he has in the process of development (in the case of Outsourcing companies, where there may be a separate final client/ user).

On the project

Make sure you are informed about the formal or informal RACI matrix (R-Responsible, A-Accountable, C-Consulted, I-Informed) and try to also include the business analyst’s role in it, so that everyone knows what they are supposed to do. If it exists only on the informal level, try to obtain the parties’ agreement and put it in a written form so that anyone can refer to it as needed. Make reference to it anytime it is necessary.

Useful information:

• the Business Case for the project;
• the used methodologies and practices on the project;
• the tools being used;
• where to find documents on the project;
• who are the domain experts (SME – Subject Matter Experts);
• who can deliver a training on the product or service you are developing.

Everything I have discussed above can help each one of you line up with the start for the new project. The information on the team, client and project is accessible to anyone who is interested in learning it. As I have already mentioned previously, these topics do not address only the business analysts, but all of those who are fulfilling this role.