{"id":19425,"date":"2023-02-13T05:00:00","date_gmt":"2023-02-13T04:00:00","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=19425"},"modified":"2024-07-22T15:29:13","modified_gmt":"2024-07-22T13:29:13","slug":"are-you-an-analyst-or-a-scribe","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/en\/are-you-an-analyst-or-a-scribe\/","title":{"rendered":"Are you an analyst or a scribe?"},"content":{"rendered":"\n

\u201cAre you a business analyst? So, you basically write down the requirements people give you, right?\u201d You might have met quite a few people in your career that think like that. Or maybe you\u2019re a business analyst, but due to time constraints in your project, you can\u2019t do much more than that. Anyways, comparing an analyst to a scribe can\u2019t be further away from the truth. Let\u2019s see what the BABOK Guide<\/a> has to say about it.<\/p>\n\n\n\n

What is BABOK?<\/strong><\/h2>\n\n\n\n

Let\u2019s start with the simple question \u2013 what is BABOK? BABOK stands for Business Analysis Body of Knowledge. BABOK Guide was written by members of IIBA \u2013 The International Institute of Business Analysis<\/a> \u2013 which is the largest non-profit professional association in the world focusing on the field of business analysis. To put it in numbers \u2013 they have chapters in 40 countries and 30 000 members worldwide.<\/p>\n\n\n\n

The purpose of the BABOK Guide is to define the profession of business analyst and be the primary source of knowledge in that field. It consists of 6 knowledge areas covering knowledge, tasks and skills necessary to be effective in their execution. They are:<\/p>\n\n\n\n

  1. Business Analysis Planning and Monitoring,<\/li>
  2. Elicitation and Collaboration,<\/li>
  3. Requirements Lifecycle Management,<\/li>
  4. Strategy Analysis,<\/li>
  5. Requirement Analysis and Design Definition,<\/li>
  6. Solution Evaluation.<\/li><\/ol>\n\n\n\n

    Let\u2019s take a look at each of them.<\/p>\n\n\n\n

    Business Analysis Planning and Monitoring<\/strong><\/h2>\n\n\n\n

    When you plan on doing something complex, the first thing to do is to create a plan. Business analysis usually delivers us a plan of what we have to develop or change in our organization to reach our goals. But the analysis in itself can be a very long and complicated process. In big projects, we have to conduct dozens of interviews and workshops, manage even more requirements, make sure we contact all the required stakeholders and at the end review our solution with the critical ones.<\/p>\n\n\n\n

    How can we make sure we don\u2019t overlook anything? How will we communicate with everyone? That\u2019s where business analysis planning comes into play. This knowledge area includes 5 tasks.<\/p>\n\n\n\n

    Plan Business Analysis Approach<\/strong><\/h3>\n\n\n\n

    Here we determine if we are going to use a more predictive or adaptive approach, how formal our analysis is going to be, what level of details will satisfy us, how big the change is, how much time we have and other general issues. After that, we review and agree on the approach with the key stakeholders.<\/p>\n\n\n\n

    Plan Stakeholder Engagement<\/strong><\/h3>\n\n\n\n

    We have to plan our approach to establishing and maintaining effective working relationships with stakeholders. Stakeholders are all people that are either interested, impacted by or involved in our project. In this task, we have to identify all of them and analyze them \u2013 which ones have the highest impact, decisive power, and interest in our project? What are their communication needs? And so on.<\/p>\n\n\n\n

    Plan Business Analysis Governance<\/strong><\/h3>\n\n\n\n

    In this process, we identify the decision-makers among our stakeholders and the information required for decisions to be made. Without this information, we might get stuck, when we have our requirements ready, but no person to accept them. Or even worse \u2013 we moved on as our requirements got accepted, but later we learn that by the wrong person.<\/p>\n\n\n\n

    Plan Business Analysis Information Management<\/strong><\/h3>\n\n\n\n

    Business analysis information is all the requirements, diagrams, design, stakeholder concerns, etc. that we have gathered or prepared. Here we decide where they will be stored, rules of indexing (e.g., requirements IDs), their level of abstraction and attributes. Also, who will have access to read and edit them?<\/p>\n\n\n\n

    Identify Business Analysis Performance Improvements<\/strong><\/h3>\n\n\n\n

    While all the other tasks we usually do once and throughout the project just to make sure that their results are up to date, this one is ongoing. In the beginning, we set some measurements (or they can be set by our organization) regarding e.g., deliverable dates or frequency of changes. Then stakeholders evaluate our work from time to time and on the basis of their reports, we can find preventive, corrective or improvement actions to better our approach.<\/p>\n\n\n\n

    Elicitation and Collaboration<\/strong><\/h2>\n\n\n\n

    This knowledge area focuses on obtaining information from stakeholders as usually, this is the lion\u2019s share of analysts\u2019 duties. It covers everything from preparing your sticky notes and a venue (at least it used to be so a few years ago) to communicating your findings to stakeholders and making sure they can work toward what is best for the whole company and not only their department.<\/p>\n\n\n\n

    Prepare for Elicitation<\/strong><\/h3>\n\n\n\n

    Here we focus on everything we will need to gather the requirements. We define the purpose or what information we expect to get, when, from whom and where. We also select the proper techniques e.g., interviews, workshops or questionnaires. Finally, we communicate with stakeholders, so they can come properly prepared.<\/p>\n\n\n\n

    Conduct Elicitation<\/strong><\/h3>\n\n\n\n

    The work of a business analyst is not one of a scribe (although it is perceived by many as the same). We need to draw out the information we require, identify relevant information, facilitate meetings and keep everyone focused on the topic. Gathering information can be done in many ways \u2013 by talking to other people, going through documents or experimenting. BABOK Guide suggests 18 different techniques we can use.<\/p>\n\n\n\n

    \"Gathering<\/a>
    Fig. 1 Gathering information by BABOK<\/figcaption><\/figure><\/div>\n\n\n\n

    Confirm Elicitation Results<\/strong><\/h3>\n\n\n\n

    After the information is gathered, we have to review it. This is done to check if it is accurate and consistent with everything else that we have. It can also help us discover any errors, omissions, conflicts and ambiguity.<\/p>\n\n\n\n

    Communicate Business Analysis Information<\/strong><\/h3>\n\n\n\n

    After we have prepared some business analysis information, we have to communicate it to our stakeholders in the proper scope and style depending on the recipient. It has to be done to ensure that all stakeholders have a shared understanding of the requirements.<\/p>\n\n\n\n

    Manage Stakeholder Collaboration<\/strong><\/h3>\n\n\n\n

    Stakeholders ever so often have different assumptions and needs (e.g., never-ending conflict between UX and SEO). It is our job as an analyst to encourage the stakeholders to work toward a common goal. Even if sometimes reaching that goal can get one of them fired (e.g., automation, which will result in some layoffs).<\/p>\n\n\n\n

    Requirements Lifecycle Management<\/strong><\/h2>\n\n\n\n

    Requirement lifecycle management focuses on working on a specific requirement. How does it connect to other requirements? Does it impact some parts of our organization negatively? Does the new information we\u2019ve gathered change the existing requirement? What if a stakeholder wants to change a requirement, he\/she has submitted earlier in the project? Tasks from this area will help us deal with all those situations.<\/p>\n\n\n\n

    Trace Requirement<\/strong><\/h3>\n\n\n\n

    We should always keep track of a requirement\u2019s history and know the relationships between requirements, designs and releases or iterations. This way we can clearly identify the effects of introduced changes.<\/p>\n\n\n\n

    Maintain Requirement<\/strong><\/h3>\n\n\n\n

    Some requirements represent an ongoing need (e.g., compliance with a legal act) and can be reused in different projects. As such its accuracy and consistency should be always maintained, so it remains valid over time.<\/p>\n\n\n\n

    Prioritize Requirement<\/strong><\/h3>\n\n\n\n

    Everyone knows what the prioritization is. But depending on the company, project or stakeholders there can be many bases for it:<\/p>\n\n\n\n