Tag: Methodologies

The Business Analyst’s Approach to Problem Solving

Written by Giorgos Sioutzos on April 27, 2022. Posted in Articles.

As a business analyst you will have to understand your clients’ needs and constructively provide valuable solution options. You will have to find the real roots of the needs and approach problems in a way that will enable change.

Your task is not just to collect requirements. It’s to elicit requirements in order to ensure long – lasting change. It is common for clients to come up with the solution in mind. For example, a client may request an addition of a step to the process. Diving more and trying to figure out the actual need behind this request may reveal that there is another way of treating the actual need.

The following stages are commonly used by Business Analysts when problem solving is required.

1) Problem Definition

Τhe first step in the approach is the problem definition. Gathering information, ascertaining its validity against other sources of information, and analyzing the available information are key at this stage. The way a problem is identified first and then defined can have a significant impact on the alternatives that may be emerge. Identifying the problem will also delineate the goals and objectives that the alternative solutions should cover. The more complete a problem statement is, the easier it will be to identify alternatives, selection & evaluation.

Common pitfalls in this stage include:

Too wide or too narrow definitions of the problem can impact the quality of the solution. Analysts are asked to find the balance between small and large range so that there are several alternatives.

Focusing on the symptoms rather than the causes is a common mistake in defining a problem. Of course the subjectivity involved in characterizing the symptom often makes this mistake inevitable. Many techniques such as the “5 Whys” can help in avoiding this pitfall.

Choosing the right problem means that while there may be parallel problems we must choose with a systemic approach the problem that is most possible to some extent another problem. Systemic thinking is of paramount importance as there is usually an interdependence between seemingly unrelated problems.

2) Alternative Solutions

Once the problem is identified, the analyst, should, together with the technical team to search for possible solutions.

Solution options has to be aligned with the project scope, the overall business needs and the technical feasibility. Solutions options must be realistic from business and technical side and of course valid in the eyes of the stakeholders.

A common mistake in this step is to abandon an alternative too quickly. This often happens under the pressure of time and other circumstances. However, because an alternative seems convenient, this does not make it ideal. It may have harmful side effects, or it may be less effective than other alternatives that would result if given enough time at this stage.

One way to limit the error of the incomplete “pool of alternatives” is to involve key stakeholders in discussions of identifying different solutions. It’s a good way for different perspectives to be presented and contribute to different solution alternatives.

3) Identify the best solution

For every solution option an assessment shall be done against the other solution options. The business analysts in collaboration with the key stakeholders identify the criteria that will be used for this comparison.

A cost-benefit analysis is commonly used for each solution option in order to figure out the benefits against the costs. However sometimes the full benefits or costs cannot be monetized, and indirect benefits or costs may be derived by the implementation of a solution. So, it is not a good idea to compare different options based strictly on a cost – benefit analysis as it is not easy to think about all costs and benefits and give them a value.

An analyst understands the cognitive limitations of human information processing capabilities and the difficulty of making optimization decisions. It is worth noting that the best alternative is choosing an environment of delimited rationality. An environment of delimited rationality is created as the limits of the decision-making process are set by the available information and the context.

Problem solving is vital in all aspects of business from people problems to technical problems and from short-term to long-term problems. And problem-solving involves two completely different, possibly conflicting thought processes: creativity and decision making. A business analyst shall continuously try to improve problem solving skills by implementing in practice useful techniques and approaches and continuously following up the outcomes.

Goldilocks And The Three BAs

Written by Christina Lovelock on March 9, 2022. Posted in Articles.

Once upon a time, there were three BAs, they all wanted their analysis to be “just right”, but what does that actually mean?

Balancing Act

‘Just-enough’ and’ just-in-time’ sound like straightforward concepts, but how much is enough? This very much depends on the context and the needs and preferences of your Goldilocks. We always want our business analysis outputs to be accurate, but we also need them to be proportionate and appropriate to the situation.

So ‘enough’ business analysis means: establishing clear expectations and exclusions, sufficient breadth and depth of investigation, engagement with representative stakeholders, utilization of suitable analysis techniques, and a focus on creating analysis outputs and assets that meet a specific purpose.

We can look at the characteristics of ‘over-analysis’ and ‘under-analysis’ to help test the balance, and ensure our analysis efforts and outputs are just right.

The First BA: Over-Analysis

This BA finds it difficult to know when their analysis is ‘finished’.

We can always speak to one more stakeholder or hold one more workshop! It is easier to frame analysis outputs as ‘sufficient to meet the purpose’ (which may be to inform further activities, share knowledge, facilitate agreement, enable decisions, etc.) rather than ‘finished’. We must also remind ourselves that new information will always emerge, this does not mean our analysis was wrong but reflected what was understood at that point in time. The purpose of the analysis is to increase knowledge and test assumptions. Some assumptions will be proven wrong, and new perspectives will emerge.

The characteristics of over-analysis:

Feeling overwhelmed and experiencing Analysis Paralysis
Too much detail, no summary or high-level routes into the detailed analysis
Endless meetings/discussions/workshops with no progress
Number of requirements out of control
Too much focus on edge cases
No prioritization of analysis effort
Repository of unread documents
Total reliance on BA to navigate the analysis, opaque to others
Regularly finding duplication of requirements or analysis assets
Audience for analysis outputs unclear
Being ‘90% done’ for weeks or months.

The Second BA: Under-Analysis

This BA does not challenge assumptions or apply analytical thinking.

Stakeholders may have low expectations of this BA, treating them like an order-taker or scribe. When we accept a very narrow role or are told we cannot deploy the full range of analytical techniques required for the situation, the quality and veracity of the resulting analysis will be compromised.

The characteristics of under-analysis:

Always engaging the same small group of stakeholders
No stakeholder analysis
Solution pre-defined
No clear problem definition
Applying a very limited range of analysis techniques
Only creating user stories
No consideration of edge cases
No templates or reuse, always starting from scratch
No peer-review by other BAs
Process-view only, no consideration of data
Technology view only, no consideration of business
Opinion over evidence, deference to HiPPOs (Highest Paid Person’s Opinions)
No challenge of ideas/assumptions/processes
Undocumented assumptions
Writing things down with no critical thinking or analysis.

The Third BA: Just Right

This BA understands the audience and purpose of the analysis and is confident in the business analysis skills and techniques which will achieve the required outcome.

A key aspect of creating analysis outputs that are accurate, appropriate, and proportionate is agreeing on who will use the analysis and for what purpose. It then entails considering possible routes to achieving that purpose, how the analysis will be carried out, and getting further agreement on that approach.

A ‘definition of done’ for the analysis deliverables is very valuable, and creates a shared understanding and agreed set of expectations from all stakeholders.

Questions for getting analysis just-right:

WHY am I doing this? What is the purpose of the analysis?
WHO am I engaging with? Who is missing? Are the stakeholders representative and proportionate? Are they appropriate for this stage? Who will use what I produce?
WHAT am I creating? What format, what length, what systems will I use?
HOW will I approach the analysis? What business analysis techniques will I apply? How will I select techniques that are appropriate to the audience, timescale, and other constraints? How will I ensure I am producing analysis and not simply documentation? How will I achieve validation and approval of the analysis deliverables?
WHEN is the analysis needed? What can be achieved in that timeframe, what cannot be achieved? What constraints does that place on the engagement and investigation? What dependencies exist?
WHERE will the analysis be shared and stored? How can I ensure transparency and increase engagement?

Conclusion

The first BA is drowning in the detail and doesn’t know where to stop. The second BA is doing what they are told, and not bringing analytical tools and thinking to the situation. The third BA is asking a lot of questions, and quite possibly annoying people who think they should ‘just get on with it’, but certainly has the most chance of producing analysis outputs that are useful and valued.

The recipe for getting business analysis just right is to be aware of the characteristics of over and under analysis, to apply a suitable range of analysis techniques which explore multiple perspectives and to understand the expectations of Goldilocks.

The Delicate Balance

Written by Liina Pruulmann on March 1, 2022. Posted in Articles.

As a new analyst in the User Account Management team in Playtech I often find myself making a challenging choice. On the one hand there is the option to build a new feature, create a new configuration, etc. On the other hand, there is the option to create a new automated rule and custom tags to simulate the same outcome. The dilemma of dev vs no dev. And it is often not a clear-cut case.

As fellow analysts or product owners know, a proper feature for a set of use cases is… neat and tidy. It is easy to refer to when answering questions from users. It can be reused. It can be further developed. It feels like something got done.

The challenging alternative is to choose an already existing powerful tool (for example Automation Service Engine) that can be used to create business rules based on defined parameters. This is awesome! No more dev for us. We have created a tool that replaces custom dev. But wait, we need to do some small tweaks to this tool before it becomes capable of achieving the desired outcome.

After having done some soul searching on this eternal dilemma, I have found it comes down to these 5 considerations:

Backwards Compatibility

We have 118 operators with a total of 385 brands. When adding new configuration options, we need to be extra careful to make sure that current setups do not suffer. Often this means we need to come up with a default value that would maintain the status quo in addition to the new value that would enable the new behavior. Boy have I ever felt the caricature of “repairing an airplane mid-flight” to hold truer.

Let’s take Self-Exclusion for example. It is already quite complex and at the same time business-critical. If we make a minor change and this feature then starts acting even in a slightly different way, we’ll potentially have several major regulatory breaches that can end up in large fines or even lost operating licenses for whole countries.

Futureproofing

If we invest time here now, will it be reusable for future cases? Will there be similar requests in the future? In what ways do we need to design flexibility into the feature? This comes down to the infamous “gut feeling”. I have a gut feeling that in the future we will see a lot more focus on active intervention in regulations. Licensees would have to actively monitor their player base to determine at-risk players and proactively suggest different self-governed limits or indeed apply limits without consent (but still with a duty to inform). This would mean a well-rounded interface that would incorporate communication features, at risk player discovery (using machine intelligence), flagging said players, and responsible gaming features well at hand. This would be a considerable interdisciplinary effort. Would it be worth the investment?

Maintainability

We are the guardians of the system. We should know the best ways to solve business and regulatory requirements by using either existing features or creating new ones where appropriate. The more ad hoc solutions we offer, the more cumbersome it becomes to maintain. The limitations of the human memory in combination with the problems of organizational memory mean we would soon have no overview how different configurations are achieved or know how the system behaves when using combinations of said ad hoc solutions that are not specifically designed to work together. I would argue that if there is a combination that is only meant to work together and excludes all other options, then this can effectively be considered a new separate feature. The goal is to have fewer dependencies and fewer configuration options within one feature.

Fast Release Cycle

Every party involved in software product development wants to have a solution that requires the least amount of work possible. Our time is extremely valuable, and the cost of missing opportunities is even higher.

The time constraints also come into play regarding go-live dates, certification deadlines and so on. If there is a faster option for developing a new feature that must be adopted by all parties down the line… often the best solution is to go ahead with the workaround. Sometimes the workaround becomes permanent, sometimes we get to phase two.

Adaptability

I am picturing the IMS setups of existing licensees as brides on their wedding day. It took months of preparation and multi-party negotiations to get every detail right (and somehow still over budget?) If possible, no-one must touch the setup that works. Do not fix what is not broken, right? Mostly people are just too afraid to upset the bride.

But it is also our hope that when we create a cool new feature that would benefit existing licensees, they may become interested in improving their business processes, security, or customer experience. Indeed, they are paying for a continuously developing platform so they can benefit from new features, and we are actively promoting them.

These features need to be extremely easy and fool-proof to adopt. If a client gets burned once they will be even more hesitant to change their working setup the next time.

No Clear Answer

Usually, you can get some sort of an answer to almost any problem by creating the famous Pros and Cons table. The problem is – I cannot draw a table (I tried) with all these considerations and two columns – one to tick if in favor of dev and other for no dev. It is not a binary choice, but more like a scale. Sometimes the scale is only slightly in favor of one or the other in each aspect, sometimes more decidedly so.

Finally, I would like to give you some insight into how I adapted to this situation – maybe fellow analysts will recognize the steps below:

A new-to-me, established, fully functional, super customizable system. There cannot be a problem too big that cannot be solved with a few simple tweaks.
Uh-oh. Tweaks are not enough. New features are the order of the day! Everything should be solved with new features.
Wait… could we add a small checkbox here in this feature to create a configuration option?
Too many configurations! Who on earth can keep track of them all?
Aha! A rule engine… and tags! Let’s see how many problems could be solved just by using them?
Write an article
Continue to learn and develop.

Problem Definition – The foundation of Effective Problem Solving

Written by Giorgos Sioutzos on February 2, 2022. Posted in Articles.

The problem identification task is about really asking the question, what problem are we solving and we’re looking to try to answer.

But before we can identify the particular problem and really understand that we first need to understand how does this gets initiated? How does the problem identification task get started? What causes us to start looking into this? Well, there are really two ways that this can be initiated. Number one is through the organization or client. This is done through some type of request. The other source of problem identification there from a self-initiated discovery and kind of move forward to understand, is there value in fixing that or adjusting for that potential change?

Below you may find four tips for the most effective Problem Identification

Don’t Start with the Solution

It’s very important to only focus on the problem and the structure of this problem at the step of problem identification. Just naturally, as we hear a problem, we start brainstorming and thinking through the solution. However, in that way probably fail to identify the real problem.

Find the root cause

It’s not only about identifying the problem but it’s about identifying the right problem and really getting to the root of the problem. What I mean by that is one problem may actually be the effect of another lower-level root problem. A common technique used is the 5 whys. The method is remarkably simple: when a problem occurs, you drill down to its root cause by asking “Why?” five times

Keep it Simple

Simplicity does not mean a lack of understanding. It may mean a good solid understanding. Try to approach any complex situation by breaking it down into more simple elements.

Exploit the collective wisdom and synergies

None can go far alone. We need collective wisdom and accepting different perspectives. It’s the only way a complete understanding of the problem to be achieved. Don’t forget to leave yourself open to different ideas and perspectives that may be contrary to your established beliefs and thinking patterns.

As a business analyst, there are many cases where the customer comes up with claims on changing something, like changing something in a standard process by inserting an approval step. Instantly we naturally try to find a solution contrary to trying to identify the real problem. Instead of instantly focusing on the solution alternatives trying to figure out what is the real problem can really provide a path towards meaningful solutions that will provide value to users.

Identifying the real problem and determining it in the most effective way is the fundamental step for having an effective solution. Problem identification is the first step of the rational process of problem-solving.

Turn your specifications into living, digital documentation

Written by Line Karkov on December 8, 2021. Posted in Articles.

Digital transformation requires the use of new tools and new ways of working – also for business analysts. We often facilitate this for other groups of people, and we should be ready to look at our own habits and preconceived notions as well and embrace new mindsets and tools. This article offers a take on what ways of working could look like for the digital business analyst.

Collaboration is becoming increasingly digital, and this also gives business analysts many opportunities to work smarter and better. That is, if you are ready to let go of documents and spreadsheet, and instead embrace digital tools for wikis, notes and backlog management. With a wiki tool, you can easily build your requirements documentation using webpages in a tree structure. Your first pages describe your scope. Each of those pages can then be broken into details on several pages that branch out. If you are familiar with mind maps, you will see that this is basically the same structure. In fact, a mind map can be a great first sketch of how to structure the content of the wiki.

The wiki structure allows your documentation to grow dynamically without you losing the overview. This structure is very well suited for agile development. If you focus on establishing the scope first, you will soon have some documentation that is accurate, though it is high level. You can describe the scope of your initiative first, and sign that off with your stakeholders. Based on that, you can discuss deliverables with your developers, and establish your backlog with features or epics. The features or epics can then be prioritized with your stakeholders. You can then detail out the requirements on your wiki, and the team can break down the user stories based on the wiki. This means, that while your scope is fixed and signed off, your detailed requirements get fixed and signed off incrementally in the same pace as the team is developing. I have experienced this to be a good way to be able to handle scope creep (because I have the scope to keep the requirements in check) and to avoid analysis paralysis and requirements rot. Because it is digital, I can create links from my backlog items to the relevant parts of the specification.

The basic concept can be illustrated like this:

Why not just add my requirements to the backlog items, and avoid all the linking? Well, because I want my documentation to describe my product holistically, including its context. And I want my backlog to describe the increments that the product is built in. So I need both. I can then communicate, what my product is and does without also having to communicate the increments it was built in, which is completely irrelevant to most of my stakeholders. I can easily share a wikipage with a link or present it in a meeting. This means fewer powerpoints to produce.

Once the product is built, I no longer need the backlog – my documentation is what describes the product. And with that documentation established at the very early stages of the product development phase, I can communicate what the product looks like through its whole life cycle, from the birth of the idea to the decommissioning of the product. Each page is automatically version controlled, which makes the change control much more granular, and changes easy to manage without keeping extensive change logs. In some digital tools, you can even set up approval workflows to make sure that the right people sign off on changes. I like to think of it as the DevOps mindset implemented in requirements analysis.

You can add any kind of content. A webpage has no limits when it comes to content – pictures, text, tables, links, and attachments. Your documentation can contain much more than a traditional requirements specification, such as personas, test data, samples of production data and other types of examples. Because of the tree structure, I always know which objective or process a detailed requirement supports. Obviously, various kinds of diagrams play an important role. Traditionally, you would argue that you must do your modelling using a modelling or BPMN tool. The reason for this is that your models can then be reused by others. In theory, this is true. However, I have never experienced this reuse in my 15 years as a business analyst.

Over the past couple of years, I have practiced using pen and paper for visualizations, and I have integrated this into my ways of working. It is a great way to work because it helps me focus and process information. It is also free of the constraints a computer program sets when you create digital visualizations. To my own surprise, this approach is very compatible with digital documentation. Simply take a photo or scan a drawing and add the image to the page. It can then be enriched with text for elaboration. This is particularly useful when describing scope, features or epics and application landscape. Digital and analogue are not contradictory, but complementary.

I have recently published two articles on BA Times related to using pen and paper, which provide some tips for getting started:

Start your visual facilitation journey with letters

The icon library: My favorite analogue tool