Tag: Communication

Demystifying MVPs, Prototypes and Others in the BA Landscape

Written by Nuno Santos on March 7, 2024. Posted in Articles.

Let’s get some confusion out of the way. There are many different concepts and related acronyms that aren’t always used in the best way. Let’s try to clarify them.

Terms like MVP (Minimum Viable Product), MMF (Minimum Marketable Feature), MLP (Minimum Lovable Product), prototype, and proof of concept are all concepts used in product development, but they serve different purposes and have distinct characteristics. Here’s a breakdown of the differences between them:

Prototype:

Purpose: A prototype is a preliminary version of a product used for design, testing, and demonstration purposes.
Focus: It primarily focuses on illustrating the product’s design, user interface, and user interactions.
Development Stage: Prototypes are created early in the product development process to visualize ideas and concepts before full-scale development begins.

2. Proof of Concept (PoC):

Purpose: A proof of concept is a small-scale project or experiment designed to verify the feasibility of a particular technology, concept, or approach.
Focus: It concentrates on demonstrating that a specific idea or technology can work in a real-world scenario.
Development Stage: PoCs are often done at the very beginning of a project to assess technical feasibility.

3. Minimum Viable Product (MVP):

Purpose: An MVP is the most basic version of a product that contains just enough delivery work to satisfy early customers and gather feedback for further development.
Focus: It focuses on delivering core functionality to test the product’s intended value to the customers.
Development Stage: MVP comes after the idea and concept but before extensive development.
Goal: The primary goal is to validate assumptions and learn from user feedback with minimal development effort.

4. Minimum Marketable Feature (MMF):

Purpose: MMF is a subset of features within a product that is sufficient to make it marketable to a specific target audience.
Focus: It concentrates on delivering features that are essential to meet the needs of early adopters and generate sales or user adoption.
Development Stage: MMF typically follows the MVP phase, where you refine the product based on initial feedback and prioritize features for marketability.

5. Minimum Lovable Product (MLP):

Purpose: MLP aims to create a version of the product that not only satisfies basic needs but also elicits an emotional response from users.
Focus: It goes beyond functionality to provide a delightful user experience and build strong user loyalty.
Development Stage: MLP often follows the MVP and MMF stages and is focused on making the product more appealing and engaging.

In summary, while MVP, MMF, and MLP are related to the development and release of a product, each serves a different purpose in terms of features, user experience, and market readiness. Prototypes and proof of concepts, on the other hand, are more focused on testing and validating ideas and technologies before committing to full development. In IIBA’s Guide to Product Ownership Analysis (POA®), the concepts of MVP, MMF, and Minimal Marketable Release (MMR) and Minimal Marketable Product (MMP) are introduced in terms of decision-making on what to build. The figure below is from the POA Guide and orders these four concepts. To know more about MVP with PoC and prototyping, check out a great article (with a video interview) with Fabricio Laguna (“The Brazilian BA”) and Ryland Leyton here.

Fig. 2: MVP, MMF, MMP, and MMR in the POA Guide

Business analysis Behind Proof of Concept (PoC)

We may use a PoC when the goal is to make a very small experiment around a business idea, from which we need to assess its feasibility.

A well-known way to explore ideas in an early phase of design is by conducting Design Sprints.

Business analysis work within this process is of extreme importance. First of all, a BA professional may use their facilitation skills to facilitate the entire workshop. When framing the BA scope to the ideation process, their work starts when applying the “How Might We” technique. If you want to know more about the “How Might We” technique, you can check it out here.

After ideating a range of “How Might We?”’s, the BA work includes facilitating the following workshops, from which the ideas are refined until a (possibly very bad) prototype is built and tested with users. BAs are usually comfortable with conducting the tests. At the end, they gather the insights from the tests and assess the PoC.

Business Analysis Behind MVP

When planning to build an MVP, don’t forget you’re targeting and validating if a business idea, through a product, has value for customers that you believe it has. However, before investing in a solid product, the mindset is that you’re making the least effort possible to have something that technically works.

This means that the work around framing a problem and further elicitation, analysis, modelling, refinements, etc. relies on hypotheses to be validated rather than fixed requirements, allowing for greater flexibility and adaptation to changing customer needs.

Business Analysis If You’re Not Targeting an MVP

Sometimes, when building an MVP, it is planned in a way that has a minimum set of features that can be delivered to customers. As already discussed, that’s not an MVP but an MMF instead, so the mindset for building it focuses more on scope modelling to decide which features have to be included.

Also, if the mindset focuses more on delighting customers (sometimes disregarding the business value delivered), that’s not an MVP but an MLP instead. The BA work focuses more on user research, interviews, and partnering (if existing) with UX/UI professionals. Personas and empathy maps are commonly used techniques.

After that, you may define your strategy to test your assumptions. There are different techniques, which depend on the testing context. And such contexts have different approaches to use.

As a BA, we can support decision-making about the technique to choose. But also to help in setting up those tests.

Mentoring For Success

Written by Victor Medugu on February 21, 2024. Posted in Articles.

The year 2023 brought about significant achievements in my mentoring journey as four of my mentees successfully secured Business Analyst roles in the UK.

My passion for mentoring was ignited during my transition to the Learning and Development department at the International Committee of the Red Cross several years ago. This transformative experience marked the beginning of my dedication to fostering growth and professional development in others.

Mentoring aligns with the 70-20-10 model, specifically falling within the 20% designated for social learning. In this context, learners engage in collaborative knowledge exchange with peers and mentors, creating an environment conducive to skill development and personal growth. The 70% is designated to pivotal role of practical experience in shaping competence on the role, continuous learning by doing. The 10% is accredited to formal learning conducted in in either in online sessions or in workshops or classrooms.

A mutually beneficial relationship between the mentor and the mentee characterises successful mentoring. The mentee receives individualised counsel and access to a wealth of knowledge, and the mentor finds joy in helping someone progress. This stimulating exchange fosters self-assurance, leadership skills, and a greater comprehension of one’s area of expertise. Consequently, mentoring emerges as a keystone for achievement, bridging the knowledge gap between theory and practice and enabling people to travel with direction and clarity.

Essentially, mentorship spreads like wildfire, encouraging a culture of never-ending growth and success. A mentor facilitates the growth and learning of the mentee by offering insightful counsel, encouragement, and support. The mentor’s experience and skill set serve as a beacon, providing guidance and insight along the way to success. This connection extends beyond traditional schooling, providing insights from the actual world and strengthening abilities that are frequently absent from textbooks.

Business analysis is a profession with a T-shaped skill set, it places strong emphasis on personal qualities. These qualities are not only crucial for success in the field but also form the foundation for effective mentorship. Key among these qualities is relationship building, as mentoring thrives in an environment of openness, trust, active listening, and the ability to provide and receive constructive feedback.

Dr. Linda Philips-Jones, in her enlightening article “Skills for Successful Mentoring,” outlines essential qualities for a good mentor, including the ability to inspire, offer corrective feedback, and, notably, open doors. I resonate with the concept of “opening doors” in mentoring, as it encapsulates the mentor’s role in guiding a mentee toward new opportunities. I prefer to frame it as showing the mentee the door, emphasizing the mentor’s responsibility to guide and support the mentee in achieving new skills and heights.

A mentor’s effectiveness hinges on maintaining a friendly and approachable disposition. Accessibility and availability are paramount, even in today’s fast-paced world filled with numerous commitments. Mentoring in the professional realm of business analysis involves not only imparting technical skills but also guiding protégés to succeed as consultants within the dynamic field of business analysis.

According to Memon J et al. (2015), mentorship can evolve through various life stages, including initiation, cultivation, and separation. Moreover, there may be a definition stage that facilitates the establishment of a meaningful friendship between the mentor and mentee. Each stage introduces distinct challenges and opportunities, contributing to the comprehensive development of the mentoring relationship.

In the context of actively seeking a role, a mentee should possess the crucial skill of effective networking, a great place to start is LinkedIn. This goes beyond using the platform solely for job searches; it includes joining industry-specific groups to acquire valuable information, knowledge, and opportunities. LinkedIn functions as a tool for recruiters to directly approach individuals for interviews. However, before initiating contact with recruiters, thorough preparation is essential. This preparation involves gaining a solid understanding of fundamental Business Analysis concepts, including requirement gathering/elicitation, analysis, and management.

A comprehensive approach to processes is essential, involving the ability to assess and enhance them by understanding the current state and making improvements for a better customer experience. Effective communication with a diverse range of stakeholders, both internal and external, is key, utilizing various requirement gathering methods. Identifying the right individuals to meet with and providing relevant responses often requires creating a stakeholder matrix to map those involved in the project.

Documentation plays a vital role, involving the use of process models to create organizational templates such as requirement catalogues, functional specifications, or Jira boards. Finally, extensive collaboration, active participation in meetings, and volunteering beyond one’s immediate task and job description are important aspects to contribute effectively in a professional setting.

The most gratifying moment in mentoring comes when a mentee reaches out with the news of securing a job, expressing gratitude for the support provided. While not every mentee may secure a position immediately, the success of even one mentee is deeply rewarding, showcasing the tangible results of effective mentorship.

Mentoring goes beyond simply obtaining a business analyst role; it encompasses on-the-job coaching as well. It aims to ensure that the mentee grasps the crucial knowledge needed to seamlessly integrate into the role. Nevertheless, many mentees appear to prefer a coach within their organization, as it accelerates their acclimatization, helps them comprehend the tacit knowledge of the workplace, and enables alignment with colleagues who can facilitate a smoother transition into the role.

As I reflect on the successes of 2023, I look forward to continuing my mentoring support to colleagues in 2024.

Top 10 Tips For Requirements Gathering

Written by Suchita Panchal on February 8, 2024. Posted in Articles.

When the requirements are NOT clear, a project will not be successful.

Where would you go If you don’t know where to go?

Building or presenting a solution demands knowing the requirements. When you know what the stakeholders require, you can deliver them the right results. Understanding requirements and passing them on to the team is a crucial task.

Successful requirement gathering is all takes to deliver the right solutions. This article presents the top tips for requirements gathering, a beacon for successful deliverables.

Let’s begin by understanding requirement gathering!

What is Requirement Gathering?

Requirement gathering is a process of discovering the specific requirements of a system through users, customers, stakeholders, and other team members. It is also referred to as requirement elicitation. Considering its two main types, business requirements are what an organization will accomplish with the project. On the contrary, technical requirements are how the project should be executed.

Requirements Gathering works as a roadmap while working on a project. It allows team members to focus on the deliverables; thus, developing or presenting the right solutions.

Here are the top 10 tips for successful requirements gathering:

#1. Engage Stakeholders: Involve all relevant stakeholders from the beginning. Identify and engage with key stakeholders who have a vested interest in the project’s success. Their input is critical for understanding needs and expectations.

#2. Define Clear Objectives: Clearly define and document the project’s objectives and goals. This helps in aligning everyone’s understanding and ensures that requirements are gathered to meet these objectives.

#3. Use Various Techniques: Utilize a variety of requirement-gathering techniques such as interviews, surveys, workshops, observations, and prototyping. Different methods can uncover different perspectives and insights.

#4. Ask Open-Ended Questions: Instead of closed-ended questions that elicit yes/no answers, ask open-ended questions to encourage stakeholders to provide detailed information and elaborate on their needs and expectations.

#5. Focus on User Needs: Prioritize user needs and understand the end-users’ perspectives. Their input is crucial in designing solutions that meet their requirements and improve user satisfaction.

#6. Up-to-date Documentation: Accurately document all gathered requirements. Use standardized templates or tools to ensure consistency and clarity in capturing and organizing requirements.

#7. Requirements Validation: Validate the requirements with stakeholders to ensure accuracy, completeness, and feasibility. Verify that the gathered requirements align with the project objectives.

#8. Consider Non-Functional Requirements: Don’t overlook non-functional requirements such as performance, security, scalability, and usability. These requirements are critical for the overall success of the solution.

#9. Effective Change Management: Understand that requirements might evolve throughout the project lifecycle. Implement a robust change management process to handle and document changes effectively.

#10. Transparent Communication: Maintain clear and open communication channels among stakeholders, ensuring everyone is updated on requirement changes, progress, and decisions. Clear communication mitigates misunderstandings and ensures alignment.

These tips can serve as a guide to help ensure a comprehensive and effective approach to gathering requirements, leading to successful project outcomes. Tailoring these approaches to suit the specific context and needs of your project is also essential for achieving the best results.

Become a Better BA: Study History

Written by Kimberly Yoss on February 7, 2024. Posted in Articles.

As a business analyst or someone aspiring to be a business analyst, do you seek out better understanding in your daily life as well as at work—exploring the angles and the what-ifs?

I think many business analysts have a mindset to explore and uncover truths that others might not.

Let me share a recent related experience.

During a trip to France several months ago, I crowded into the museums amid the other tourists. Despite the bustling, I re-connected with the beauty, the feeling of inspiration, and the magnificent presence of the best works of art in the Musee d’Orsay, the Claude Monet House in Giverny, and the Dali Museum.

I noticed something was different this time.

Moving mindlessly with the flow of the other tourists from one piece to another felt flat and meaningless. Most tourists approached each piece with a camera first, skimming the surface with a click and a view, posting to social media, and then turning attention to the next piece.

I wedged myself in to get closer as I listened to the audio guide. Skimming was not what I was here for this time. I was hungry for the history of each piece: the background of the artist and the details of the time and place in which the piece was created. Give me history, context, and the human perspective.

Learning and embracing history has quite a few benefits for building on context, scope, and possibilities.

It fosters knowledge and deeper understanding, contributing to a broader perspective.
It exposes multiple details associated with an event, which helps improve understanding.
It establishes connections between events (even seemingly unrelated events).
When expressed like a story with characters and settings, it improves comprehension and retention.
It can provide a base for drawing conclusions and, therefore, applying learning.

That trip to France has ended. The journey to apply the art of historical understanding to the challenge of business analysis is ongoing.

As CBAPs, we look to BABOK for guidance in our work. We use it to provide the pillars of understanding needed to do what we do in the best possible way.

Wouldn’t it be cool if we could tap into a fresh methodology that has the power to augment the resources in BABOK?

…and in walks history. You thought you wouldn’t need it after college, probably even after high school, right? Let’s explore this.

To study history effectively, one needs to engage in most of the following tasks:

Take a chronological account of events and tie them together with other events.
Be able to distinguish what events lead to other events to establish cause and effect.
Be able to make connections between seemingly disconnected pieces of information.
Keep track of the players and how they affect the events.
Identify and extract the key information.
Gather related information to fill in the blanks to build a more complete picture.
Apply critical thinking to assess your own understanding.
Be able to apply and project your own understanding based on the facts.
Do not be afraid of research or large quantities of information.

An effective business analyst needs to be able to:

take in a tonne of seemingly disparate information.
research and uncover additional information.
Talk to many different people.
synthesise all the information.
put it into context (many times we have to build an entirely new context from all the information!)
…and then be able to express it in a way that multiple groups of people will understand it and be able to draw conclusions from it.

We look to BABOK for guidelines on how to approach this process.

If you study history, you are honing skills that BABOK teaches. In effect, you have another tool to become a better analyst.

History is usually presented as a set of sometimes-chronological facts that you need to piece together and tie to other facts. From this, you can determine cause and effect to get a bigger picture of how different events are related (represented by #1 and #2 stated above).

Think about the BABOK task “Conduct Elicitation.” The purpose of this task is “to draw out, explore, and identify information relevant to the change.” The task has three types: collaborative, research, and experiments, all of which rely on gathering and organising usable information and facts.

The BABOK task “Analyse Current State” contributes in a similar way. This task’s purpose is “to understand the reasons why an enterprise needs to change some aspect of how it operates and what would be directly or indirectly affected by the change.” The inputs to this task are elicitation results, and they include elements of external influencers, organisational structure, and culture to support the analysis.

Another parallel I find interesting is between #7 and #8 above and the BABOK tasks “Analyse Potential Value” and “Recommend Solution and Recommend Actions to Increase Solution Value.” You must be able to absorb and synthesise the information and come up with your own understanding, so you can use that understanding to build context and perspective for future understanding. In the two BABOK tasks, the purpose is to “estimate the value” of multiple options (or courses of action, in the case of the “Recommend Solution” and “Recommend Actions to Increase Solution Value” tasks) and determine which best meets the requirements of the enterprise based on the information available.

Finally, I find a parallel between gaining a deep understanding of the players in history and the need to know our stakeholders in business analysis (represented by #4 above). A deep understanding of the stakeholders is so important in business analysis that it is a core concept in the Business Analysis Core Concept Model, integral to every knowledge area in the BABOK. You cannot completely understand your project and cannot design a solid solution if you don’t have a strong handle on who the stakeholders are, how they are connected, and what they need.

Same in history. You understand the Impressionist era much less if you don’t know that Monet, Renoir, and other painters during that time period actually worked and played together.

For the passionate and effective business analyst—as well as for any history buffs reading this—I think it comes down to being curious, being structured, and doing your research.

Lost in Translation: The Perils of Ambiguity in Business Communication

Written by Adrian Reed on November 22, 2023. Posted in Articles.

In recent years, I’ve traveled a lot less than I did before the pandemic. One thing this has led to is me seeing processes and practices with fresh eyes. When you travel regularly, the novelty wears off and a sort of ‘autopilot’ kicks in, and a period of not traveling means that everything is less familiar and more open to scrutiny.

I was recently thinking about the questions that are commonly asked when checking in bags before a flight. I can’t even remember if these questions are asked verbally any more, or if there’s some sort of sign or declaration, but there certainly used to be questions such as:

“Have you left the bag unattended at any time?”
“Did you pack the bag yourself?”

I suspect, like many people, if you were asked these questions a semi-autopilot would kick in and you’d say ‘no’ without thinking. After all, presumably these questions are aimed at catching smugglers or criminals of some other type. The questions almost seem redundant for ‘normal’ people.

Let’s examine one of the questions, as I think some of the patterns here are important for business and business analysis more generally….

What does “unattended” mean?

Let’s take the first question (“have you left the bag unattended?”). This question is, upon examination, really quite vague. In fact, I’m pretty sure the actual question airport staff is more specific, but humor me and let’s imagine they ask it in this way.

A first challenge is what the word ‘unattended’ means to one person might be quite different to another. Take the following situations, do you consider them to mean that the baggage has been left ‘unattended’?

You’ve just taken a connecting flight and have had to re-check your bags. Your bags have been handled by baggage handlers, and have been left unattended in the hold of the plane
You traveled to the airport by bus. The bags were in the baggage compartment of the bus and you didn’t have access to them during the three hour bus ride. There were several stops along the way where passenger bags were loaded/unloaded. Anyone could have accessed your bag at those times.
You drove to the airport. It was a long drive so you stopped for gas and a meal. Your car was parked in a car park for over an hour
You traveled as a group in two taxis. Your bag was in the other taxi, accompanied by your friends but not you

It’s tricky, isn’t it? Technically, if you’ve checked your bags into a previous flight, they have been unattended for a period of time. Yet, you’d likely say ‘no’ to this question… because you know that this isn’t a circumstance that actually counts as ‘unattended’. I suppose as travelers we intuitively know what’s being asked and what matters. Or at least we think we do…

After all, if we were to literally interpret the question “have you left your bag unattended at any time?” then there is no way that ‘no’ would be a valid answer. Of course it’s been left unattended at some times… when it’s in the closet not being used!

Beyond Airports: Why Definitions Matter

You probably don’t work in an airport, so might be wondering why I’m obsessing over the wording of a check-in question. This pattern of ambiguity potentially leading to misunderstandings, confusion or (more usually) people making assumptions is rife in organizations and projects too.

Much like the term ‘unattended’ has ambiguity attached, other seemingly ‘obvious’ terms can be problematic. Take the word ‘customer’, it sounds clear, doesn’t it? Perhaps you’ve even written a requirement or user story which articulates what a customer can do. Yet even such a simple-sounding word leaves room for ambiguity. For example:

Does someone have to have already bought something to be considered a ‘customer’? Or does the term ‘customer’ include prospects/people in the buying pipeline too? Or do there need to be two terms, ‘prospect’ and ‘customer’?
If the person paying for a product/service is different from the person using/benefiting from it, which one is the customer? Are they both customers?
Is the term used to mean internal as well as external customers?
Are there different customer types? Does a requirement or story apply to all types or only some types of customer?

Things can get even more complicated than this. Who is the ‘customer’ of the judicial system, the prison service, and so on. It very much depends on who you ask, which is why it is important to actually ask the question!

Definitions Make For Concise Requirements And Stories

This comes back to a key point that is (sadly) often overlooked: definitions matter. A glossary might not be considered a new or exciting artifact, but it can really help ensure people are on the same page. With a clear and shared understanding of key terms, requirements and stories can be more concise.

A small investment in a shared glossary can save lots of time in the long run. Starting early is the most effective way of doing this. And believe me, if you don’t create one, there will come a point in time where you wish you had!