jueves, 16 de agosto de 2012

No matter if the Sharepoint analyst does not know the answer

by Fernando Hunth  

In projects where we use Sharepoint, as in other project without Sharepoint, the task of the analyst is fundamental .

Many times you need to know the business that you are relieving, but this is not always true in all cases. So here are some tips for those cases.
You , the analyst has been assigned to a new project . Started working on the initial kick off preparing yourself by reading the scope, schedule reviewing the document and calling your first meetings with the various stakeholders of the project. In the middle of the meeting while listening intently a detailed process , you find yourself taking notes and more notes. Suddenly you realize that the notes begin to lose respect and the caller continues talking and talking!.

While your grades are word for word what they are saying, for fear of looking foolish or that the team does not lose credibility in your work, it's best to keep writing, while trying desperately to understand what is being said.
If this is your first project, this is what usually happens to an analyst.
I have participated in many meetings where I saw this many times.
For these cases, there are such tips to handle those situations
No matter how experienced is an analyst, a situation like this will happen again. It is very rare that a business analyst, regardless of their experience - can begin each project with all the knowledge and have answers for all scenarios.
When you're lost in the meeting:

1) Try not to look into the eyes of other members of your project team and looking for complicity in what is not understood.
2) Trying to make sense of what is said
3) Be able to take the information gathered - but no sense - and to produce relevant requirements heard.
There are some simple tricks to get out of the predicament of not knowing the subject and still get something from the meeting.


· 1) Know that "I'm not familiar with the details." Under my roles, working with many clients. And most of the time, I know very little about its internal processes, standards, procedures, policies, etc., Let alone as captured in their systems and / or applications. But that does not stop me from start to know quickly. Can request access to the site rules and procedures for example, and get to know more of what is said in the meeting. When I am with a client or a new project, although it has many skills, sometimes are useless unless you know how to use them in a project. When I am in a new project that I know very little, I have to ask you explain this in more detail? Would you care to explain it in a more easy to understand? The reason for this is so that they can understand the issue at a higher level with less detail before you start to see issues like the particular process workflow functionality or user interface or whatever you are trying to understand . In other words, we are openly admitting that we are not familiar with the details. Being open and honest in asking to be understood, will further strengthen the relationship of trust with the project team and business stakeholders. Handled in this way is to make clear that I do not know yet what is being discussed but soon I will be aware of all the details.
· 2) Find the points of action - even if you're a business analyst - and their flesh hacete if you belong. Another interesting tip is to track action items that come out of a meeting, even if not directly involved. Take the opportunity to some new project to learn as much as you can. No matter where you come knowledge or content, simply immerse yourself in the project topic. It goes without saying that you must first meet your responsibilities, but if you have the opportunity to attend a meeting, better, for example to check a design document or sit with stakeholders, or the convening informal meetings to shore up your knowledge. Although some of the action items that are not entirely related to your work on the project, you will help build your background knowledge which will be useful later in the project.
3) Create a partnership with Business Stakeholder (or where is the knowledge). While it is important for the analyst to have a healthy society with the Project Manager, it is equally important to have a healthy society, open to business stakeholders. After all they are going to be who we meet with the project. Often this relationship is ignored, or lost value. This leads to limit or to break the communication at the worst. If you want to succeed as an analyst, you have to value the partnership with stakeholders. It'll be easier to get vital information quickly when you have a healthy partnership, strong and open.

Probably the hardest trick is to be humble and ask. This trick is simple to understand, but also the most difficult to perform. It is good for the beginning of a new project, be wary of exposing your weakness to the team, so that your colleagues do not know they have a vulnerability about the full understanding. However, if you do not speak now be too late. Because the role of an analyst is so vital to the overall success of a project, you should never pass up the opportunity to start to ask the stakeholders to clarify your comments if you do not you understand. It could be comments on the scope, the out of range, the business needs, requirements, functional specifications, diagrams, or anything related to the project. The point is, no matter what the query, if not very understandable, we ask you to clarify the question. Many times the requirements phase of a project is to be executed quickly, so it's important to set expectations for level of understanding of the subject at the beginning and to avoid being forgotten. And you're worried about the loss of credibility in the beginning of a project not knowing the subject in detail, imagine how much you lose credibility when you do not understand anything after three weeks of analysis or design sessions. I assure you participate in projects where analysts received documentation that served me very little to understand how to build the application.
Many times, I have seen good analysts lose credibility with a project team, as they are not willing to admit not knowing something. Fearing ridicule, the analyst will go ahead with what they know about it, but when it comes to the time to decide on a project and are not as well versed, that is when the conditions are at risk of being incomplete or incorrect. Next time you're in a meeting or gathering project requirements not know the answer to a question or do not know how a business process, probably use one of these tips to help you get a better understanding. You have to be bold enough to let the fear of losing credibility and do what is necessary to have a clear and concise understanding of the subject matter. By doing this, you will place in the position to produce solid requirements, real and accurate.
Getting to obtain these results is very important for the next stages of the project.
Remember that many people are going to be based on those requirements and that the project's success depends a lot on you.

At Baufest every day, we try to improve our relationship with our customers, where they often apply these tips.