The Business Analysis Masterclass

A fact is a fact until it’s no longer a fact. Situations change, and you once thought was true was proved to be false. Rule #1. Remember that nothing is forever.

?️ Course Overview: Navigating Your Stakeholder Landscape

In this session, we dive into the "why" and "how" of Stakeholder Analysis. I believe this is one of the most critical activities in any initiative because projects don't exist in a vacuum—they are powered (and sometimes hindered) by people.

Key Takeaways:

• The Definition: A stakeholder is anyone—positively or negatively—affected by your initiative.

• The Strategy of Grouping: Not all stakeholders are equal. We explore how to categorize them by interests, needs, or influence to keep your project on the path to success.

• Primary vs. Secondary: We distinguish between those directly impacted and those who are on the periphery.

• Building the List: I share my personal approach, which starts with analyzing existing processes, moving to organizational charts, and finally, using brainstorming techniques when documentation is scarce.

? Reflective Exercises

To get the most out of this, take a moment to consider these questions based on a project you are currently working on:

1. The Hidden Influencer: Looking at your current project, is there someone you haven't officially listed as a stakeholder but who could be "negatively affected" by the change? How might their influence impact your timeline?

2. The Actor Audit: Think about the "actors" in your project. Are there any non-human actors (like a specific software system or a legacy database) that you need to account for in your analysis?

3. The Brainstorm Challenge: If you had to lead a 10-minute brainstorming session today to identify stakeholders, who are the three most diverse people you could invite to ensure you don't miss any "secondary" stakeholders?

"The more exact you are in your categorization, the better—but you have to start somewhere."

Mastering the RACI Technique: A Practical Guide

As a professional, I've found that the RACI technique is one of the most valuable tools in my project management toolkit. It’s an effective way to clarify roles and responsibilities within an organization or a specific assignment.

RACI stands for Responsible, Accountable, Consulted, and Informed. Each of these roles has a distinct function:

• Responsible: The person who actually performs the task.

• Accountable: The person who is ultimately answerable for the task's completion and quality.

• Consulted: The subject matter experts who provide input and guidance.

• Informed: Those who need to be kept up to date on progress.

The RACI matrix is a powerful way to visualize these roles, as it allows you to see at a glance who is involved in each task and what their role is. It's also an excellent way to develop a communications plan, as it helps you identify who needs to be informed and how much detail they require.

Reflective Exercises

Now that you’ve learned about the RACI technique, take some time to reflect on how you can apply it in your own work.

1. Identify a project or assignment where the RACI technique could be useful. What are the key tasks and who are the stakeholders involved?

2. Create a RACI matrix for this project. Assign the roles of Responsible, Accountable, Consulted, and Informed to each task and stakeholder.

3. How will this RACI matrix help you manage the project more effectively? What are the benefits of clarifying roles and responsibilities in this way?

4. Think about how you can use the RACI technique to improve communication with your stakeholders. What information do they need to know and how often should you communicate with them?

Have you ever felt like you’re constantly putting out the same fires at work, only for them to flare up again a week later? It’s frustrating, right? Usually, that happens because we’re fixing the symptoms we see on the surface, rather than the root cause hiding underneath.

In this module, I’m going to walk you through one of my favorite tools: The Five Whys.

Don’t let the simplicity fool you. Originally developed by Toyota and famously used by leaders like Jeff Bezos, this technique is a game-changer. We’re going to move past the "technical jargon" and get straight to the heart of how you can use this to communicate better with your team, understand your customers' real needs, and—most importantly—fix problems so they stay fixed.

By the end of this session, you’ll be able to:

• Peel back the layers of a problem like an onion.

• Lead a team "interrogation" that feels like a friendly chat, not a police lineup.

• Use the "Human Factor" to understand why people do what they do.

Reflective Exercises

I’ve designed these activities to help you bridge the gap between "knowing" the technique and "doing" it in your daily life.

Exercise 1: The "Recent Frustration" Audit

Think back to a problem you dealt with in the last week—maybe a missed deadline, a broken process, or a misunderstanding with a colleague.

• The Surface: What was the first thing you complained about?

• The Deep Dive: Now, try to ask "Why?" just three times regarding that event. Does the third answer look different from the first?

• Reflection: Did your initial "fix" actually address that third answer, or just the surface?

Exercise 2: The "Tone Check" Challenge

The Five Whys can feel aggressive if we aren't careful.

• Scenario: Imagine a team member forgot to send an important email.

• Drafting: Write down three different ways to ask "Why didn't that email go out?" without using the word "Why." (Hint: Try "What led to..." or "Walk me through the steps...").

• Reflection: How does changing the phrasing change the "vibe" of the conversation?

Exercise 3: Building Consensus

Consider a problem in your department that everyone seems to have a different opinion on.

• The Exercise: If you sat five of those people in a room and performed the Five Whys, where do you think they would finally agree?

• Reflection: Why is a "group consensus" on a root cause more powerful than just one person’s expert opinion?

In the late 1960s, computer scientist Melvin Conway proposed his theory that an organization's system reflects its communication structures. This theory holds true as organizations tend to replicate their internal accountability, power structure, politics, and preferred communication flow. Typically, conversations flow vertically from top to bottom, as depicted in the organizational chart. To illustrate this, let's observe a conversation within a company. The CEO, an old-school individual who avoids using computers but adores his smartphone, instructs Smith to deliver a report by Friday morning. However, Smith is uncertain about the CEO's expectations, so he urgently contacts Jones, asking for the report by Thursday noon to allow for review. Reviewing ensures Smith doesn't appear foolish if the CEO has questions. Jones grasps only part of Smith's request, initiating a cascade of communication. Steps 1, 2, 3, and 4 become a confusing back-and-forth process, often revisiting previous steps. Due to a lack of direct communication between steps 1 and 4, they must resort to a reverse backchannel to relay information. This unofficial communication channel arises as a result. While it would be simpler for Jones to approach step 4 directly, such a deviation from protocol is not encouraged.

An entity-relationship diagram (ERD) is a graphical representation of the relationships between entities in a database. It depicts the structure and organization of data, illustrating the entities (objects or concepts) and their relationships through connectors and symbols. ERDs are primarily used in database design and development processes to analyze and communicate the logical structure of a system.

ERDs are created to visualize how different entities relate to each other and to define the attributes (properties) of these entities. They serve as a blueprint for designing the database schema and provide a clear understanding of the data model to stakeholders, including developers, designers, and business analysts. ERDs enable the identification of key entities, their attributes, and the relationships between them, such as one-to-one, one-to-many, or many-to-many. This visual representation helps ensure data integrity, enhance system performance, and simplify the development and maintenance of databases.

By using ERDs, data professionals can effectively analyze complex systems and identify the various entities and relationships involved. The diagram acts as a communication tool, enabling stakeholders to discuss and refine the database design before implementation. It allows for the identification of potential issues or redundancies in the data model, facilitating improvements and optimizations. ERDs also aid in documenting the database structure, which can be valuable for future reference and system documentation. Overall, ERDs offer a systematic approach to understanding and representing the relationships between entities, ensuring a well-organized and efficient database design.

In this video, I dive into the often-overlooked but incredibly powerful technique of observation—also known as job shadowing or simply "following people around."

While interviews and focus groups are popular, observation allows us to see what people actually do, rather than what they say they do. This is crucial because we often fall into routines and forget the small details of our daily tasks.

? Key Takeaways:

• Passive vs. Active Observation: * Passive: Observing and taking notes without interrupting. This helps capture the "natural flow" and avoids biasing the outcome.

  • Active: Asking questions and prompting discussions during the observation. This is best for tasks that don't require high levels of concentration. You can even try doing the task yourself to gain a deeper understanding!

• Preparation is Key: Decide who to shadow and what questions to ask beforehand.

• Observation, Not Evaluation: Those being observed mustn't feel like they're being "judged" or "monitored" (the "Big Brother" effect). If they're suspicious, it's time for a different approach.

• Expect Revelations: Observation often reveals that what's supposed to happen (the official procedure) is quite different from what's actually happening (how employees have customized the process for themselves).

? Reflective Exercises

Now, let's put these concepts into practice with some reflective exercises. Take some time to consider the following:

1. Identify an "Observation Opportunity"

Think about a process or task in your current workplace that could be improved.

• What's the process?

• Who are the key people involved?

• What specific things would you be looking for during an observation?

2. Choose Your Approach: Passive or Active?

For the process you identified above, which approach would be more effective?

• Passive: Would it be better to just watch and see the "natural flow"?

• Active: Would it be helpful to ask questions and maybe even try the task yourself?

• Why? Explain your reasoning based on the nature of the task and the potential for bias.

3. Communicating the "Why"

How would you explain the purpose of your observation to the person you're shadowing to ensure they don't feel evaluated?

• What specific language would you use?

• How would you emphasize that your goal is to understand and improve the process, not to judge their performance?

4. Anticipating Discrepancies

Based on your knowledge of the process, what "revelations" do you anticipate?

• Do you suspect there's a difference between the official procedure and how the task is actually performed?

• How might these differences be beneficial (e.g., a more efficient "workaround") or problematic (e.g., a safety risk)?

The "Observation Postscript" eLearning video is a compelling look at the power of observation in product development. I discuss the challenges and potential of understanding customer needs, specifically when it comes to developing new products.

The video explores several key topics including:

• Understanding user needs: Exploring how observation can reveal needs that users might not be able to articulate themselves.

• The power of prototyping: Discussing how prototypes can be used to gather real-world data and feedback through observation.

• Integrating data and observation: Showing how quantitative data from sensors and qualitative data from observations can be combined for a more comprehensive understanding.

• The evolution of products: Exploring how observation can lead to innovative features and the development of new product categories.

Reflective Exercises

Exercise 1: Identifying Hidden Needs

In the video, I emphasize that people often have difficulty articulating their needs. Think about a product or service you use regularly. What are some of its features that you find particularly useful, but wouldn't have necessarily thought to ask for initially?

My reflection: I'm a big fan of my noise-canceling headphones. I never thought I needed them until I started working from home and realized how much background noise can be a distraction. Now, I can't imagine working without them! ###

Exercise 2: The Power of Prototyping

The video mentions the importance of prototyping in gathering real-world data. Consider a project you're currently working on or a product you'd like to develop. How could you use a prototype to gather feedback through observation? What specific things would you be looking for?

My reflection: I'm currently working on a new mobile app. I could create a low-fidelity prototype and observe users as they navigate through the app. I'd be looking for things like where they get stuck, what features they use the most, and overall user experience.

Exercise 3: Integrating Data and Observation

I discuss how integrating quantitative and qualitative data can lead to a more comprehensive understanding of user needs. Think about a situation where you've used both types of data to make a decision. How did each type of data contribute to your final decision?

My reflection: When I was choosing a new car, I looked at both quantitative data (like fuel efficiency, safety ratings, and price) and qualitative data (like test drives and reviews from other owners). The quantitative data helped me narrow down my options, while the qualitative data helped me make the final decision based on my personal preferences and needs.

Exercise 4: Identifying Product Evolution

The video explores how observation can lead to innovative features and the development of new product categories. Can you think of any other examples of products that have evolved in this way?

My reflection: One example that comes to mind is the evolution of smartphones. They started as simple mobile phones, but through observation of user behavior and needs, they've evolved into powerful computers that we carry in our pockets.

This lecture will cover reference material I find that I find useful and would like to share with you

https://www.batimes.com/articles/career-choices-for-a-business-analyst-what-options-does-a-ba-have.html