By: Ginny

Ginny — Sat, 29 Jul 2006 00:43:50 +0000

I recently read a white paper that discussed competencies needed by Business Analysts. One of the interesting points it made was that different levels of BAs would use different tools, do different tasks, and have different views of their work. For example, in eliciting requirements a junior BA would assist by doing surveys and interviews, an intermediate BA would lead group sessions such as RAD and brainstorming, while a senior BA would identify which people should identify the requirements and what the priorities are. For business process reengineering, they suggest that tasks range from use-case modeling (junior), through workflow analysis (intermediate), to "ensure business goals are met" (senior). It takes time to learn and develop your analysis skills so that you can envision larger parts of the business and how the requirements for one area impact others. Only someone who has the vision to think strategically will be comfortable with the "visioning" part of a project. Those who are still developing their skills should be brought in when the project is more defined.

By: Frederica

Frederica — Wed, 19 Jul 2006 05:01:18 +0000

When my role in my technical system switched from coder to BA, one of my chief personal goals was to start teaching the central service organization that provided requirements the ins and outs of the technical processes that had, throughout the years, been implemented to render the business rules. It made sense, since the tech team knew the business rules, that the business should know the technical rules. As time moved on that goal was realized. As the lines between vision, requirement provider responsibility, and technical-process knowledge became blurred, however, it became more and more obvious that the business was relying heavily on the BA to figure out their requirements for them without the BA having actual access to the end-users. Anxiety began at the point that the BA was helpless to gather requirements (since they had no access to the end customer, which was the realm of the central services organization) but was still relied upon to guide the customer meetings, no longer guiding, but doing all the thinking for the central service business based on a vague mission statement or goal. Anxiety is valid at this point, since once the project gets underway, bickering starts as to the actual roles of the BA vis a vis the end user, the logic of the BA determining business rules, and the effectiveness of a service organization that doesn’t have access to the end users. Barbara is right – The roles of BAs are not the same everywhere. In-house technical BAs should insist that their customers are working as hard as they are in the early stages of a project, and refuse to continue with a project if they have to lead every conversation that doesn’t involve the business simply restating their executive summary business goal. BAs should allow their anxiety to guide them into insisting on shared responsibility that ultimately serves the project, stakeholders, SMEs, and BAs best.

Comments on: Are Business Analysts Anxious?

By: Ginny

By: Frederica