Skip to main content

Tag: Elicitation

How Product Discovery Deals with Requirements

If you are working in products, you certainly have realized product management handle requirements differently. There is a shift from eliciting stakeholders’ wishes to discovering better and faster ways to solve stakeholders’ problems. This article presents how discovery techniques popular within product management fit in the three types of requirements: business, stakeholder and solution. Understanding where the techniques fit in this spectrum will allow a better understanding of how and when to use them.

Keywords: Requirements; Elicitation; Product discovery

 

What is Product Discovery and this “Modern” Elicitation

There may have been times in the past where business analysis was (incorrectly) seen as a passive discipline.  Some might have viewed that a business analyst’s job when “gathering” requirements, most of the time, was attending meetings where they interviewed a group of people. Typically, these people had significant roles in the product (although most of the time they wouldn’t be the future users of the solution) and the business analyst would simply be a clerk and register all their dictated “wish list” items.

This approach is based on the premise that your sources know what they need and dictate the solution, yet how often is this actually realistic?  More often there will be experimentation, change and the need for flexibility. The emergence of agile development methods and frameworks like Dual Track Agile, influenced organisations to split their efforts into product discovery and delivery.

 

The main shift on the premise of product delivery, compared to bespoke or market-driven requirements engineering, is that teams have to discover what the user’s problems are based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. For business analysts, this means being involved in both the discovery and delivery processes, and it requires a shift in how requirements are elicited and managed. BAs need to challenge stakeholders’ perceptions on any assumed solutions and get to the underlying need using modern requirements techniques. They have to discover the requirements rather than gather them.

 

The Requirements Engineering Cycle

The cycle that typically involves elicitation, documentation, validation, and management of requirements is often associated with the broader field of Requirements Engineering or Requirements Management within the context of software development or project management. This cycle is iterative and continuous throughout the project lifecycle. Here’s how it works:

  1. Elicitation: Requirements are gathered from stakeholders, users, and other relevant sources. This step involves understanding their needs and expectations for the software or project.
  2. Documentation: The collected requirements are documented in a clear and comprehensive manner. This documentation can take various forms, such as a Software Requirements Specification (SRS), user stories, use cases, or other requirement documents.
  3. Validation: The documented requirements are then validated to ensure that they accurately represent the stakeholders’ needs and are feasible to implement. This involves checking for consistency, completeness, and correctness of the requirements.
  4. Management: Throughout the project, requirements are actively managed. This includes change management to handle updates or modifications to requirements, traceability to link requirements to design and testing, and prioritization to determine which requirements are most important.

The requirements process doesn’t end after the initial elicitation, documentation, and validation. It’s a continuous and iterative cycle because requirements may change over time due to evolving project goals, stakeholder feedback, or other factors. Therefore, effective management of requirements is essential to ensure that the project remains aligned with its objectives and stakeholder expectations. It often involves feedback loops, revisions, and ongoing communication with stakeholders to refine and adjust requirements as needed throughout the project’s lifecycle.

 

1.    Discovery Techniques for Elicitation

“How might We…” Technique

The “How Might We” technique is a crucial aspect of the design thinking process and is often used in design sprints to frame problem statements and generate creative solutions. The “How Might We” technique involves rephrasing challenges or problem areas into open-ended questions that invite elicitation through brainstorming and creativity. The challenge is to rephrase it as an open-ended question that begins with “How might we…?” The “How Might We” statements invites participants to generate creative ideas without feeling restricted by existing limitations. It shifts the focus from problems to possibilities, and it helps teams explore solutions from different angles, often leading to innovative and unexpected outcomes.

 

Jobs-To-Be-Done

“Jobs-To-Be-Done” (JTBD) encourages us to appreciate why a product or service was “hired”, not only in a functional dimension, but also in circumstances and emotional dimensions.  The book “Jobs to be Done – Theory to Practice” by Anthony Ulwick describes a framework that you can use to define your jobs, from setting your different customers, the different kinds of jobs (core, related, emotional, consumption chain and purchase decision jobs), and setting the desired outcomes.

The behaviours of the customers that afterwards lead to definition of the “hired” job are identified by observation. Observation is a common elicitation technique. In this case, rather than observing (or shadowing) in order to replicate a given process, an observation within JTBD aims to relate a behaviour to customer’s outcomes.

 

Continuous Interviews

Teresa Torres described a set of “continuous discovery habits” to engage customers in a continuous cadence. The main shift in doing interviews is that questions don’t focus on what customers want. Rather, questions should focus on their past experiences to discover an opportunity.

As the name states, it uses interviews techniques. Once more, a very popular way to perform elicitation. As mentioned, the main shift is that questions that are asked focus on their past experiences to discover an opportunity.

 

The Mom Test

the Mom Test is another interesting approach for conducting stakeholder interviews. It has similarities with “Continuous Discovery Habits”, as the questions should focus on their past experiences to discover an opportunity. The premise of the Mom test is: your mom will always like your idea, but doing the right questions can make her tell what you really need to hear. Elicitation by performing these kinds of interviews allows us to depict the problem in question, rather than waiting for the interviewees to tell us the solution they want.

 

Advertisement

 

2.    Discovery Techniques for Analysis

Value Proposition Canvas

The Value Proposition Canvas is a strategic tool used in business and product development to understand and communicate how a product or service creates value for customers. It’s typically used in conjunction with the Business Model Canvas to create a holistic view of a business. The canvas helps businesses design their offerings by gaining a deep understanding of customer needs and how their products or services fulfil those needs.

It demonstrates a clear understanding of customer pains, gains, and jobs to be done, and introduces alignment of the pain relievers, gain creators, and product(s) benefits.

 

User Journeys

User journeys, also known as customer journeys or user experience (UX) journeys, are a product discovery technique that originated from the field of User Experience Design (UXD) and User-Centered Design (UCD). User journeys provide a visual representation of the user’s interactions and experiences while using a product or service. They aim to capture the user’s perspective, emotions, actions, and touchpoints across different stages of their interaction with the product.

 

 Opportunity Solution Trees

Opportunity solution trees are a visualisation of potential solutions to a customer problem. They involve breaking down the problem into smaller opportunities, generating multiple solutions for each opportunity, and then evaluating and selecting the most promising solution.

It is our analysis work in getting insights from conducting the Continuous Interviews, allowing us to identify opportunities for our product.

 

 

3.    Discovery Techniques for Documentation

Epic Alignment

Epic alignment” is from Nils Janse’s book with the same name, proposes a single source of truth about the requirements, in form of a “lightweight” documentation that is based around epics. The structure that is proposed for this documentation includes information that is incrementally added to what we know about a given epic throughout the product development stages (namely, Ideation, Discovery, Prioritization, Refinement, Development and Testing). The structure of these documents allow to follow the information about an epic, which user stories are included, and the details that are needed for their implementation.

 

4.    Discovery Techniques for Validation

User story mapping

The last technique I want to discuss in the article is user story mapping. This is a technique where team members collaboratively discover how a set of user stories solve a customer problem. The method consists of sequencing the user’s activities, and allows further elicitation to take place so that detailed stories and tasks can be captured. This in turn ensures that the solution will  support the user’s activities that were presented.

Classifying this technique in a single stage can be tricky. I rather believe it encompasses elicitation, analysis and validation of requirements.

It’s a technique where team members collaboratively discover how a set of user stories solve a customer problem. End users may be involved in the collaborative process as well, most probably giving inputs in the user journey and the sequence of activities – which makes it an elicitation technique. Sequencing activities may be an output of previously performed elicitation, resulting from analysis of that information. Lastly, acceptance criteria may be included in the details of the story mapping, which forces the team to start stepping up into the requirements validation. In the case of users not have been part of collaborative process, the model may be used to validate together with users that the user journey is indeed correct.

Complexity Science Terminology Applied to Business Requirements

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

 

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

 

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

 

Advertisement

 

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

 

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

  • Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
  • Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
  • Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
  • Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
  • Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
  • Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
  • Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.

Best of BATimes: Six Effective Elicitation Questions to Ask Your Stakeholders

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

 

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

  • Organizational risks
  • Missing stakeholders
  • Requirement gaps

 

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

 

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

  • Identify new stakeholders
  • Identify and mitigate risks/constraints
  • Redefine needs or identify new needs
  • Elaborate requirements
  • Prioritize requirements

 

Advertisement

 

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

 

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

  • Collaboration
  • Integration
  • Sharing of best practices

Keeping attuned to organizational changes can help to:

  • Mitigate risks
  • Estimate project deliverable dates
  • Manage scope
  • Identify constraints
  • Understand interdependencies

 

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

  1. I ask the SME/s to describe the process for me.
  2. Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
  3. As they explain the process I ask, “What parts of the process would you improve and why?”
  4. I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.

 

The Beautiful Game as a Modern, Event-Driven Business Process Structure

The Beautiful Game

Whether you call it football or soccer, “the Beautiful Game” as it is widely known, has simple rules of play. But playing soccer is another matter. It is a highly dynamic, agile process. In the flow of a single match, an eleven-player professional team can make more than 500 passes and there can be dozens of game stoppages.

In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.

The Modern Business Process Modeling Solution

The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile.  A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.

If a business analyst, process analyst, quality analyst, or manager adopts that modern business process paradigm and a modeling notation that is aligned with how today’s business relationships and processes work, then perceiving and modeling something as dynamic and agile as the beautiful game as a process, IS NOT ONLY POSSIBLE, BUT ELEGANT.

Universal Business Process Definition[1]

The Universal Business Process Definition is not constrained to a strictly procedural notion of a process. It is an event and outcome-oriented business process paradigm. The Universal Business Process Definition’s four common-sense rules define all processes, workflows, and activities, regardless of a process’s scale, the overarching project methodology, the model’s required degree of abstraction, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

The Universal Business Process Definition, and the Business Process Normalization technique are defined in the Universal Process Modeling Procedure (UPMP), published by ProcessModelingAdvisor.com.

Business Process Modeling and Notation[2]

Business Process Modeling and Notation (BPMN) is a graphical notation for illustrating modern business process elements.  It overcomes the limitations of the last century’s procedural flowcharting and process mapping notations.

BPMN was defined by the Business Process Modeling Initiative (BPMI) and is maintained by the Object Modeling Group (OMG). BPMI states that the goal of BPMN is:

“To provide a notation that is readily understandable by all business users.”

BPMN is the best-suited notation for illustrating modern business process and workflow structures. It includes sequential flowcharting elements, but BPMN also includes symbols for illustrating concepts that are relevant to today’s dynamically collaborating systems and business processes. Namely, events and messaging.

 

Advertisement

 

The Beautiful Game as an Example

We don’t need process models about playing soccer. We’d rather be playing or spectating. But we’ve all observed enough about playing soccer to use it as a commonly understood example.  Playing soccer happens to be similar to how modern-day business processes and operating relationships work. Let’s use soccer to demonstrate how to apply a modern business process modeling paradigm and modeling notation to discover and illustrate a sound, modern business process structure.

Event-Driven Business Process Flow

A contextually and structurally sound model of the Play Soccer process can be discovered by answering the Universal Basic Business Process Flow Elicitation Agenda[3] and the Universal Event and Outcome-Oriented Business Process Flow Elicitation Agenda[4], found in The Universal Process Modeling Procedure.

This basic, event and outcome-oriented (non-procedural) BPMN process flow diagram communicates the normal, dynamic flow of Play Soccer as a set of collaborating, specialized activities.

The Play Soccer process is initiated by a kick-off at center field. It is comprised of 4 activities: Tend Goal, Defend, Play Midfield, Play Striker. Activities are performed by the players of two teams. The expected outcome of Play Soccer is that a match has been played to its allotted time limit, according to its rules.

A free kick from center starts a match.  Once the match starts all players in their assigned positions maneuver freely, whether they possess the ball or not.  The expected succession of the keeper’s, defenders’, midfielders’, and strikers’ activities is determined dynamically, by the players, while the match is played, by receiving or intercepting passes, stopping shots, and by making passes or taking shots.

The player with the ball will pass the ball to any one of up to 10 other teammates or take a shot; Either the intended teammate will receive a pass, or an opposing player will intercept a pass or stop a shot, to possess the ball. Any player that possessed the ball will then maneuver (according to their assigned position level and their own skill) and then pass the ball to any one of up to 10 other teammates or take a shot. This succession of activities continues, until a stoppage in play.

The success of the expected outcome (pass made or shot taken) of one Play Soccer activity will determine the initiating event (pass received/intercepted or shot stopped) of another Play Soccer activity. The actual flow of a game is determined dynamically, by the players who are assigned to perform Play Soccer’s activities.

This basic, event and outcome-oriented process view of Play Soccer is contextually and structurally sound, but still basic. It is upon this solid, defining structure that one can elicit, add and communicate logical details that are relevant to how the Play Soccer process will “flow” and, that this model’s readers likely expect to see. What about conditional activities, like throw-ins, corner kicks, penalty kicks, substitutions, fouls, out-of-bounds, injuries), and delays (like injury time-outs, and half-time)?

 

Logically Refined Business Process Flow

The logical details about the periodic conditions, activities, and delays in the execution of the Play Soccer process can be straightforwardly discovered by asking and answering simple agendas that are defined in The Universal Process Modeling Procedure[5]. This refined BPMN process flow diagram communicates the conditional activities and delays that are expected to periodically occur throughout the dynamic flow of Play Soccer.

The BPMN process diagram shows that game events, not a sequential procedure determine what and when certain activities are performed in the Play Soccer process.

Even with all those refinements made, the contextually accurate and sound basic structure of the Play Soccer process, that we previously established, has not changed. These refinements can be graphically included or excluded, without any rework of the basic contextual meaning or basic diagrammatic structure of Play Soccer.

Activity dependencies are contextually accurate, without depicting a sequential procedure and sequential flows. Dynamic, alternate activities, paths, and timings throughout the process are accounted for in the model. Undue model complexity, and the analyst’s time that would have been spent on it, has been avoided. Process navigation decisions, and alternate flow paths are in fact modelled, but need not be explicitly illustrated as sequence flows.

Conclusion

The Beautiful Game serves us as a beautiful example of a process that is a set of dynamically collaborating sets of specialized services. It is not a sequential procedure.  Modern business processes are not just sequential procedures either.

The Universal Process Modeling Procedure, with its Universal Business Process Definition and elicitation agendas, provides a modern process modeling paradigm, capable of event-driven as well as sequential business process elicitation and modeling. BPMN is a modern process modeling notation, that includes the graphical elements to represent business event-driven, not just sequential process flows.

With these tools in-hand, process analysts, quality improvement professionals, and business analysts, are capable of eliciting, perceiving, normalizing, defining and graphically illustrating structurally sound, modern business process structures.

Copyright 2022, Edmund Metera

[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera, 2018, 2022) www.ProcessModelingAdvisor.com
[2] Object Modeling Group, www.OMG.org
[3] Universal Process Modeling Procedure, Step 3 – Define Basic Business Process Flow (Metera, 2018, 2022)
[4] Universal Process Modeling Procedure, How to Specify Event/Outcome Oriented Business Process Flow (Metera, 2018, 2022)
[5] Universal Process Modeling Procedure, Step 5 – Refine Business Process Flow(s) (Metera, 2018, 2022)

To BA or Not To BA: Why Every Team Needs Business Analysts

The importance of having a business analyst (BA) on your team can’t be overstated. Acting as the bridge between stakeholders and technical teams, the BA wears many different hats. On any given day, a BA can be expected to work on a number of different tasks, whether that’s defining business cases, validating solutions, or even working with data (See this article on the role of BAs in an increasingly data-driven landscape). Able to straddle both worlds and speak the language of businesspeople and techies alike, BAs really are one of the most versatile members of the team.

 

The Story of an Ask

Many businesses are concerned with their ideal state, while the nitty gritties of how to actually get there are very much back of mind. “Often, the client is not able to fully explain what business problem they wish to solve and how to translate their business requirement into language the technical teams can understand,” explains Lizande Botha, a BBD project manager for a major financial services client in Africa “which is why BAs are a vital part of the process”. Put simply, BAs are responsible for translating a business ask into detailed requirements that can be understood and actioned by technical teams.

But how do we get to this point, when the ask itself is unclear? “The first question I tell the BA to ask the client is: What is the problem we’re trying to solve?” explains Botha, adding that the cardinal role of the BA is to ensure that the client ask is clearly defined. “For clients who really are unsure of what it is they want, the BA needs to keep digging and asking questions to truly get to the core of the problem” she adds.

 

Advertisement

 

Once this key piece of information has been gathered, the BA can start drilling down into the different possible solutions, what the budget is for the project, and other confines or expectations the client might have. Understanding the requirements and clearly defining the scope of any given project from the get-go can be make or break – so much so that CIO magazine reports that up to 71% of failed software projects can be attributed to poor requirements. Thus, consulting with a BA at the start of a project can avoid potential stumbling blocks.

While this early engagement is vital, the job of the BA doesn’t start and end there. Leveraging rapport built with business stakeholders, they must check in regularly to provide progress updates, while ensuring that on the engineering side things are running on course and to the requirements of the client’s business. They’re even able to partake in platform or application testing. Truly, the BA’s impact is felt throughout the project lifecycle!

 

BBD’s Drive to Help and Resolve

BBD’s teams are all complemented with BAs who are well equipped with experience and a thorough understanding of the industry they’re operating in. As each industry offers complexities unique to its environment, BBD strives to best match their analysts to sectors where they can bring their experience and real-life learnings to the table, explains Botha. This is a high priority for BBD, a software solutions company which delivers software solutions for clients across the industry spectrum, from financial, education, public sector, gaming, and beyond. Assigning BA’s that already understand the nuances, jargon and processes of a particular industry enable us to expedite the solution process” says Botha

But beyond managing teams to ensure the best hands are on board, BBD is ready to tackle any problems their clients have. And when it comes to understanding what those problems are, BBD has BAs on call to bridge the client-engineer gap and ensure the success of all of their solutions.

Looking for a software partner to help you on your next ask? Get in touch with BBD.