Tag: Methodologies

Always Ask Why: A Practical Example

Written by Adrian Reed on October 18, 2023. Posted in Articles.

I don’t know about you, but I find that I can’t turn my business analysis brain off. I find myself wanting to improve just about every process that I experience, and I often find myself conducting business analysis on the processes that I experience as a customer.

This happened to me recently when a company asked me for a physical ‘wet signature’ on a form. This wouldn’t be unusual if I was in the same physical location as the person requesting the signature, but I wasn’t—they were literally going to email me a PDF form for me to print out, sign, scan in and email back. Even though Adobe PDF has a signature function (and I have a graphics tablet, so I can literally do the same signature electronically), this wasn’t good enough. It had to be old-school pen on paper. I eventually complied, deciding that I’d rationalize it by calling the process “retro” and “vintage”…

Badly “Improved” Processes Might Be MORE Risky:

In situations like this, I always want to ask ‘why’ to understand the underlying reasons that things work in a particular way. In this case, if we were to ask why I suspect the underlying answer would be that an old paper process had been replaced, with each step being recreated electronically. In this context, ultimately, a signature acts as a way of authorizing something to happen.

You can almost imagine the conversation with a group of Subject Matter Experts (SMEs). One of them is adamant that we couldn’t possibly accept electronic signatures. The legal & compliance SME says that electronic signatures are completely valid, but there is reluctance from other stakeholders for other reasons. Perhaps there’s a perception that by getting a physical signature there is less risk… or perhaps there are other reservations. Some might be genuine, others might be founded on unsubstantiated fears or assumptions.

Left unchecked, there is a risk that ‘we’ll do things the way we’ve always done them, just in an electronic format’. This can lead to the worst of both worlds where risk is increased and customers are inconvenienced:

Alternation: I could have altered the PDF before I printed it and signed it (it’s relatively easy to edit a PDF). Unless they check it word-for-word they’ll never know, and since it’s scanned, auto-comparing will be difficult.
Verification: They didn’t actually have my signature on file. If they weren’t comparing it against anything, then really what is the point? I could have scrawled any old signature and it probably would have been accepted.
Security: Unencrypted email isn’t a secure transmission format. Even though it was relatively low-risk mundane information, it’s liable to interception en route. Plus emails can be spoofed so there’s a risk of a customer being impersonated.
Scanners: How many customers have scanners? What about people who just take photos on their phone, will that be sufficient?

These are just four examples, but they illustrate a key point: The process probably isn’t achieving what it actually set out to do. Yes, you are getting a physical signature. But if the aim is to get a secure, authenticated nonreputable authorisation for something… then the process is failing!

Always Ask Why: “Good” Questions Make A Difference

The key to avoiding situations like this is to ask why, in varied ways, lots of times. Do this and you’ll get to the core purpose of a process, or process step. In their book “Mastering the Requirements Process: Getting The Requirements Right”, James & Suzanne Robertson call this “The Essence”. In this example ‘getting physical signature’ might be the current step, but the essence is ‘authorize transaction’ (or whatever).A key point here is that if you understand the essence, you can question any underlying assumptions or business rules. It’s possible to ask “how else might we be able to do this”. If the aim is to ‘authorize transaction’ then there are countless other ways of doing this that are more secure and verifiable than a scanned PDF in an email. You could even use the Brown Cow model to question any underlying assumptions that have been made.

Asking these questions will help encourage stakeholders to think about the true essence of the process, and about how it might change in the future. A half hour discussion now might save tens of thousands of processing time later, once the process is implemented.

This is yet another area where BAs add significant value by helping to ensure things improve in a way that maximizes the benefits that will be delivered both to the organization, and to its customers.

How Product Discovery Deals with Requirements

Written by Nuno Santos on October 4, 2023. Posted in Articles.

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:

Elicitation: Requirements are gathered from stakeholders, users, and other relevant sources. This step involves understanding their needs and expectations for the software or project.
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.
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.
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.

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 s olution t rees 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 u ser 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.

Before You Get Into The Complexity of AI

Written by Timothy Figueroa on September 20, 2023. Posted in Articles.

Before you get into the complexity of AI you should dial in your approach to developing and prioritizing AI use cases. Align AI strategy to the corporate strategy and priority so AI use cases make sense to that organization.

The full value of AI implementations, for an organization, are not realized unless the manager responsible for AI in the organization aligns AI strategy and use cases to the corporate strategy and priority.

There are many examples today of AI implementations that bring value but are not linked to the Corporate Strategy and Priority of that organization. The result is difficulty understanding and measuring the value of the AI use case to that of the organizations goals and priorities.

This may come about where a leader hears about a cool AI technology like “Generative AI” and they want that implemented in some fashion in their line of business and then they accomplish this objective.

The lack of AI strategy alignment to corporate strategy and priority misaligns the AI use case resulting in AI implementations whose values are hard to assess in the context of the overall organizations KPI’s, its customers, lines of business and more.

Where AI use cases are carefully aligned and planned with the Corporate Strategy and Priority in mind it is easier to assess the value pre-implementation, in the short term and the in the long term. Aligned AI Use Cases may then, in time, become a jumping point for new products and services as the organization gains confidence in the AI space.

An alignment example might be, where the top corporate goal is to “better serve customers”. Drilling into this may mean, to the organization, where the customer interacts with the current corporate website and the portal does not support natural language queries for targeted information retrieval in a self-serve way and customers today bypass the portal and phone customer service instead, asking for the information wanted.

The impact of this portal deficit to the organization is that they maintain a larger customer service staff, support training, and maintain infrastructure; who are tasked with processing customer information query requests manually.

The possible AI use case that proposes to solve this deficit may be to enhance the current website by implementing an AI powered information retrieval feature that is easy to use and is self-serve. The AI solutions may be varied but the AI Use Case would be aligned to the corporate priority, would make sense to the organization garnering broad support and would solve a known problem. The AI user case would be measurable in terms of the current KPI’s used to measure performance.

Where the AI Strategy is linked to the Corporate Strategy, management at all levels can assess value and priority prior to any AI use case approval. As well, management would be able to articulate AI use case deliverable expectations, and how these expectations may enhance the existing environment, talk to impacts to the customer or organization, the market, possible effects to product and service offering and, in some cases, impacts to their industry.

Before you get into the complexity of AI, consider your AI strategy and use case approach. Think about linking your AI strategy and use case development to the Corporate Strategy and Priorities of that organization, this will assure alignment, measurable value, and organizational support. I believe this to be the first step to AI success.

Best of BATimes: Business Analyst Role in COTS Projects

Written by Maksym Lysikov on September 13, 2023. Posted in Articles.

Many tech companies offer commercial off-the-shelf (COTS) products.

Such products allow to meet their clients’ business needs relatively fast, comparing to the development of the new IT solutions from scratch. However, a COTS product for a complex solution such as ERP, CRM, laboratory or hospital information systems requires considerable time and effort to be invested into the configuration. Hence organizations usually involve a separate implementation team of professionals familiar with the COTS product to adapt it for the company’s needs.

COTS vendors normally provide the implementation service to their clients. This can vary from company to company, but oftentimes it includes discovery phase, configuration or customization of the system according to the business needs, user training and making sure the project goes live.

This article describes the BA role in the implementation of the COTS projects and cooperation between a COTS product team and BA from an implementation team.

BA in Implementation Project

One might say that COTS projects do not require business analysis since there seem to be no significant development activities. However, COTS projects could vary from completely out-of-the-box to complex solutions with lots of configuration and additional customization (codding) involved. In the latter case we can and shall involve the standard business analysis activities:

Plan your business analysis work. Ask yourself what is your business analysis approach (adaptive vs predictive)? Who are your stakeholders? Do you have a requirements governance process in place?
Requirements elicitation and analysis. This covers discovering the current and desirable states, conducting workshops and interviews, document analysis, etc. Don’t forget to elicit and document any gaps if a COTS solution is not capable to meet some of the business needs.
Requirements modeling. COTS projects normally do not require the complete functional specification since the solution is predefined already. However, there are many other requirement views which can be useful for the configuration project. We will discuss that in the section that follows.
Solution evaluation. Define your KPI and measure if they improved compared to the legacy solution.
Configuration. System configuration is normally out of business analysis scope, but some companies tend to involve business analysts in such activities. In any case, the BA should know how the system works and understand the solution limitations.

Requirements Modeling

As mentioned before, it might not be required to document all the functional requirements for the already predefined solution like COTS product. However, not documenting requirements at all could result in certain drawbacks:

Apparently, external stakeholders, like end users, and internal stakeholders, like testing or support teams, will need at least some documentation that describes how the system behaves.
Without modeled requirements, there is no way to validate the requirements before they are actually implemented and the system is demoed for users. What if you only validate your assumptions by demoing already configured piece of functionality? That is right, you will most likely need to reconfigure the system again once you receive the feedback, and then again and again. Nevertheless, you still can present out-of-the-box functionality which doesn’t require any configuration efforts and use it as a starting point to collect the initial feedback from your users.
The change management process can suffer. Imagine that you documented the requirements for the billing module in the bunch of meeting notes, and now 4 weeks after the requirements were implemented the clients insists that some of the billing transactions are not calculated correctly. Would it be easier to refer to the SRS part where all business rules are documented, or try to find the relevant emails?

To address the above issues, the BA can use a variety of the business analysis techniques which will be applicable for the project and audience. For example:

Roles and Permission Matrix: most of the COTS solutions allow roles configuration and assigning permissions. Start with defining and documenting user roles and their permissions. The organization chart can come in handy to define the roles.
Process Modeling: you can elicit and model the current processes using either the standard notations such as BPMN, UML or come up with a simple drawing which doesn’t follow any notation standard but clear for the audience. The next step will be to review the models with stakeholders, define if anything should be changed in the process and update the model. Once done, you can supplement the model with the additional requirements view, e.g. use cases.
Gap Analysis: as the BA on the implementation project you need to identify the areas in your client’s business which are not covered by the COTS package and address it to the product team. Bear in mind that it is always a good idea to think about the potential workarounds you can offer to the client, before escalating the gap to the product team. That way the client can access the desired functionality earlier, the product backlog will not be overloaded and there will be no need to overengineer the product with the functionality potentially used by only 1 client. So at first always assess if it is possible to configure the system in an alternative way or if the client can agree to do certain steps manually.
User Stories: this is a simple and popular way of specifying the requirements, especially if you follow the agile approach and need to deploy the COTS solution incrementally. It is also quite convenient to prioritize the requirements using the user story form.
Use Case and Scenarios: you can document each separate business flow in the use case. Use cases can easily be converted into the test scripts and serve for validation purposes.
Business Rules Analysis: it is always a good idea to elicit and document business rules. Make sure you have a process in place to update business rules due to external or internal changes.
Interface Analysis: your COTS product will most likely not be used as a standalone solution and will communicate with other components. Define and document interfaces specific to your client.
Data requirements: usually a COTS solution replaces an outdated legacy solution and you need to take care of the historical data. And it is better to define data requirements upfront before you realize you cannot import 256 characters long text into the address column for one of the top customer’s client. Ask yourself the following questions: do you need to import the historical data into your brand new COTS solution? will the legacy data fit the new system? how will you handle the cases when the data doesn’t fit the new COTS product?

Provide Feedback to your Product Team

A good way to improve the product is to listen to your user’s feedback. And when it comes to COTS project who is the best candidate to elicit, analyze and document all the client’s concerns and frustrations? Yes, you’ve got it right! It is the implementation BA or anyone else who fulfills this role in an organization. And thus the BA is the one who should establish a process to communicate all business concerns and client gaps to COTS product team.

For example, the BA can create a separate Wiki page per a client where they can list all gaps discovered during the project and communicate them to the product team. The product team can then collect the feedback from all clients, prioritize the gaps for the future releases and share the roadmap with the implementation team.

Conclusion

COTS implementation projects can be a challenge for the BA as they differ from the traditional IT development projects. However, with the right attitude and a bit of creative thinking, we can adopt the BA techniques and establish the process which will bring value to the implementation projects and help improve the COTS product.

Published: 2019/08/08

Beware Proxy Measures

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

Organizations are usually pretty good at measuring and counting things. Whether it’s positive customer reviews, staff engagement, average call handling time or something else… chances are that someone in the organization is tracking it. They might even be creating reports or dashboards so that executives can see how different elements of the organization are performing.

From time-to-time a metric will drift and there will be a desire to get it back on track. Perhaps the staff engagement survey shows that people aren’t happy. Or perhaps there’s a contact center where the average call handling time has drifted from 3 minutes to 5 minutes. Either way, it’s easy to imagine that a concerned manager would want to investigate and initiate changes.

Yet here a danger awaits the unprepared. It would be very easy to make knee-jerk reactions when referring to the data alone, without considering its context. It would be even more dangerous to make decisions based on ‘proxy measures’. By ‘proxy measure’ I mean some kind of indicator or metric which approximates how well something is going, but doesn’t directly measure it.

That might sound abstract, so here’s an example. Like many people, I wear a smartwatch that counts my steps. Doing this has definitely changed my behavior, and I strive to get 10,000 steps each day. Yet if my overall goal is to “stay healthy by staying active” then the step counter is at best a proxy measure. Sure, it’ll indicate if I’ve suddenly slumped into a sedentary lifestyle… but it would be very easy to ‘cheat’ the system. Ten thousand slow steps around the house are probably not anywhere near as beneficial as fast-paced walking (or jogging)… and that’s before we even consider the fact that it’s possible to wave your arms around to get a few extra steps. I’m sure I’m not the only one who has done that to get an extra few ‘steps’ in before midnight…

The Danger Of Unfair Comparisons

The point here is that it would be easy to equate ‘number of steps’ with ‘how active and healthy’ a person is. But that would be a dangerous equivalence to make. Ultimately, the smart watch is (I guess) “measuring the number of arm movements which are likely to indicate steps”. That is the real metric… it can be used to approximate many other things, but that is just an approximation. You certainly wouldn’t want to rely on it for decision making.

A similar pattern exists within organizations where unfair comparisons are made. Let’s imagine a call center manager is measuring the ‘average length of call’, and wants each agent to achieve an average of 3 minutes or less. The manager is probably equating “effectiveness of operator” with “length of call”. But is this truly the case?

Extending this example, perhaps there are two different agents: One (Agent A) has an average call handling length of 5 minutes, the other (Agent B) of 2.5 minutes. Agent A is put on a performance management program, while Agent B is given a bonus. Is this fair? Or could it be that Agent A is thoroughly investigating the customers’ needs, solving root causes so they don’t have to call back again, whereas Agent B is just doing the quickest thing. Perhaps Agent B even cuts an occasional customer off to hit their target…The point here is that without further investigation it would be impossible to know.

A Key Question: “Why?”

As with so many situations, a key question to ask is “why?”. In this case it’s important to ask why particular measurements are being taken. It can be a difficult question for stakeholders to answer, and different stakeholders might have different perspectives on the rationale for measuring and reporting on a particular metric. That’s useful to know too.

Asking this question can help us to determine potential gaps in the way that situations are being assessed. For example, imagine we asked two stakeholders why call handling time was measured. Perhaps they say:

“To measure efficiency of the call center agents”

“To ensure good customer service”

Arguably, the measure on its own doesn’t achieve either of these. It might be that other metrics are necessary alongside this to give a better picture. Customer feedback, customer satisfaction scores and so on might also need to be considered to give a better picture. In some cases it might be useful to stop measuring or reporting on something entirely, as the very act of reporting just acts as a distraction. All of this depends entirely on the context, so further investigation of the situation is likely to be needed.

Questioning The Norm

As with any situation, this is an area where BAs can add value by acting with curiosity. Working backwards to understand why things are measured will help ensure that possible options for improvement are generated. It will often involve questioning the norm, but most BAs are used to that!