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.
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 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:
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
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:
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.
by Ovidiu Mățan
by Mircea Vădan
