Skip to main content

Tag: Communication

Strings Attached: The Art of Adapting Templates in Business Analysis

I’ve recently started learning to play the ukulele. I made a decision early on that I’m not interested in learning ‘properly’, I don’t want to commit to formal lessons, I just want to try a fun new hobby. For that reason, the (very little) I’ve learned has been learned largely from YouTube.

When I say I’m not learning ‘properly’, I’m really just learning chords and tabs, I’m not reading sheet music and I’m pretty much just strumming along to the YouTube videos. That is perfectly fine for what I am aiming for, I never want to be a professional, I just want to play some simplified versions of songs I know.

 

In the dim and distant past I took piano lessons. Back then I could read sheet music (in treble and bass clef), knew about timing and some of the theory behind music. That knowledge has all gone now, and I have no idea how to play a piece of sheet music on the ukulele!

Now, you probably didn’t come here to read about ukulele playing, but there is relevance here, I promise! It’s all down to application within a context.

 

From Ukuleles To BA Templates

One of the things that I see a lot on social media is people asking for (and providing) BA templates. There’s a huge draw in using a template, it means that you don’t have to start from scratch. Things like templates and checklists can be very useful to make sure there’s consistency, and to make sure things don’t get forgotten.  (I have a travel checklist for that very reason.)

Yet a template without an understanding of the underlying theory and rationale can be dangerous. It can lead to slavish adoption (“well, I need to put this diagram in, because there’s a section for it… the template is ‘best practice’ after all”).  Just like my ukulele playing will always be restricted by my lack of music theory, someone who picks up a template without understanding why the template was created that way and what techniques can potentially accompany it will likely run into issues.

 

Advertisement

 

An Example: “BRD for the Financial Services Industry”

Let’s take an entirely fictional example and imagine that somebody produces a Business Requirements Document for the Financial Services Industry.  It is pitched as a document that will likely be used in a waterfall or incremental delivery environment, and includes a context diagram, use case diagram, scenarios, functional requirements, non-functional requirements and so on.

It’s hard to criticize any of those sections, there will be times when all of those are useful. But what if the person picking it up doesn’t know what a context diagram is? Even if they do, the whole act of eliciting information to construct a context diagram is an artform in itself.

Or, what about if you’re making a tiny change to the label on a single field? Are you really going to fill in all of those sections? You might, in some circumstances, but in all probability something more lightweight would be appropriate. In fact, a prototype alone might suffice…

Of course, this is a deliberately provocative example, but I’m sure you see the point. There really is no ‘one size fits all’ in business analysis. So much is down to context, and understanding the context is key.

 

However: Templates Can Be Useful

It is worth clarifying here that I am absolutely not arguing against templates, nor am I arguing against the appropriate sharing of templates on social media. They are extremely useful, when used appropriately by skilled practitioners. They can even act as a guide to less-experienced practitioners providing this is accompanied by a desire to learn the underlying theory and techniques.

However, templates are also most useful when they are flexible. What works in one situation won’t work in all, so cut a section, or add a section! It’s important to think about the purpose of the artifact, its consumers and how persistent it is (i.e. how long it is expected to remain current for).

Like so much in change, pragmatic and intelligent application is what matters.

Demystifying MVPs, Prototypes and Others in the BA Landscape

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:

  1. 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

 

Advertisement

 

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

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.

 

Advertisement

 

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

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.

 

Advertisement

 

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

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:

  1. Take a chronological account of events and tie them together with other events.
  2. Be able to distinguish what events lead to other events to establish cause and effect.
  3. Be able to make connections between seemingly disconnected pieces of information.
  4. Keep track of the players and how they affect the events.
  5. Identify and extract the key information.
  6. Gather related information to fill in the blanks to build a more complete picture.
  7. Apply critical thinking to assess your own understanding.
  8. Be able to apply and project your own understanding based on the facts.
  9. 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).

 

Advertisement

 

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.