Tag: Best Practices

Soft Systems Methodology for Business Analysis

Written by Giorgos Sioutzos on April 13, 2023. Posted in Articles.

Soft systems methodology is an approach that an analyst can embrace when phasing messy and complex problems. SSM is a way of organizing, thinking and learning in a problematic situation.[1] [2]This methodology allows the observer, faced with a vague and unstructured problem situation, the possibility to approach as holistically as possible, concentrating, combining and co-housing all existing perceptions and to suggest ways to improve the existing situation.

Business Analysts can use Analysis with SSM before the analysis and design of an information system begins (i.e. before using UML or a traditional structured development methodology).

The Methodology

A basic pillar of the methodology is the distinction between the real world and the systems thinking about real world. The methodology recognizes the complexity of the modern world and tries to reconcile the mental models we try to construct to simplify the world with the real needs and environment upon which any change will be implemented.

In addition to eliciting the perspectives from different stakeholders, it is also important to investigate different perspectives of the problematical situation.

This involves analyses of:

The intervention, including the actors involved,
The socio-cultural context including roles, norms and values and
Existing power structures

The following diagram depicts seven-stage model of SSM (adapted from Checkland & Scholes, 1990, p. 27)

We can group the activities in the real world versus the activities in systems thinking.

Ιn real world:

First: we learn/analyze the problematic situation
Ultimately: we intervene with the aim of bringing about improvements

Systems thinking include:

Identifying relevant systems of human activity with ‘key definitions’
Creating mental models from the basic definitions

Tools

1^st Step:

To understand the complex problem situation we use the rich image.

Emphasis is placed on illustrating the following:

roles in the system and views,
disputes and controversies,
system limit,
elements of the environment

An example of rich image is given below:

Source: elabor8.com.au

2^nd Step:

In the next stages of the methodology (systems thinking) we create basic definitions and then a mental model of the system.

The basic definition can follow the following structure:

Do P by Q in order to contribute to achieving R” (P = what? Q = how? R = why?)
CATWOE is a good way to think holistically about actors.[3]

A mental model is an explanation of how something works. The phrase “mental model” is an overarching term for any sort of concept, framework, or worldview that you carry around in your mind.[4]

The following diagram represents the structure of a simple mental model.

3^rd Step:

Finally we return to the “real world” for the last 3 stages of the methodology, aiming to make effective changes to the problem situation.

Collaborative learning is achieved through the SSM process. Development of shared meaning and understanding across individuals and groups are enabled and can ensure faster requirements elicitation and more precise requirements that will add value to the different stakeholders.

Conclusion

The internal and external conditions are complex, interdependent and unique. Either the change of only an internal or external component creates a different dynamic and a different system and may trigger a chain of events that can affect indirectly other components. The “Ceteris paribus” assumption in some microeconomics models seems to be utopia in the modern business environment. Systems thinking and the holistic approach are basic characteristics for effective conduction of business analysis. SSM encapsulates the systems thinking mindset and can be a useful methodology in the pre-analysis and/or early analysis phases.

[1] Checkland P. Systems thinking, systems practice. Chichester: John Wiley and Sons; 1981

[2] Checkland P, Poulter J. Learning for action: a short definitive account of soft systems methodology and its use, for practitioners, teachers and students. John Wiley and Sons Ltd: Chichester; 2006.

[3] CATWOE Analysis: A Holistic Approach to Problem Solving – SlideModel

[4] Mental Models: Learn How to Think Better and Gain a Mental Edge (jamesclear.com)

360° Feedback for BA Teams

Written by Christina Lovelock on April 12, 2023. Posted in Articles.

Does your BA team actually care what other people think of the BA services provided?

Many business analysts do not consider their internal stakeholders to be ‘customers’. So when we try to understand ‘what customers think of us’ it’s common to only consider the ultimate end user of the organizations’ products or services.

Feedback

It is important for BA teams to seek regular feedback. This enables continued service improvement and growth. Knowing what our stakeholders think of our services provides both suggested improvement areas and a baseline from which improvement can be evidenced. It also helps BA leaders make the case for strategic and financial decisions, such as recruitment or investment in professional development activities.

Zones Of Feedback

Using a 360 approach allows us to consider the different groups of customers and stakeholders whose opinions matter. The perceptions of the performance and capacity of the BA team all impact the reputation, effectiveness and influence of business analysis within the organisation.

If the BA team is considered to be unresponsive or inflexible in our approach – internal customers may try to work around the BAs or actively avoid engagement. Ensuring the BA practice or team has a positive reputation is key to being engaged at the right time and being able to carry out appropriate business analysis activities.

Zone 1 – The BA Team/Practice

As with any team, its important for managers and leaders to understand if its members are happy. Do people like being a member of this team? By asking questions about wellbeing, workload and future plans, we can understand if people are happy in their BA role. This includes:

How are we doing as a team?
What could we do that would make your role easier?
What can we learn from other places you have worked?
Are you hoping to progress within the organization within the next 18 months?
Is your workload manageable?

When team members feel that they are supported and appreciated, they are much more likely to perform well in their role, and stay longer within their organization.

This should be one of the zones from which feedback is sought most frequently. This can be a combination of anonymous quantitative feedback (quick polls, pulse surveys etc.) to inform simple metrics and more detailed qualitative feedback based on conversations to allow a deeper understanding of views.

Zone 2 – Multi Disciplinary Teams

These are the teams which individual BAs contribute to. This might be project or delivery teams brought together for a fixed time period, or product teams with ongoing responsibilities for product development and maintenance. It is useful to understand the experience and perspective of the customers who work with business analysts day-to-day. Do these close colleagues understand and value the contribution made by business analysts to the team?

Feedback should be sought at sensible times, such as delivery milestones, when a BA leaves an assignment/team, or as in input to structured performance review cycles.

Where projects/stakeholders continually request the same business analyst(s), it suggests a lack of faith in the BA team and a reliance on the skills/knowledge of an individual. If that is the case, how can the BA team share knowledge and skills and improve consistency of the BA services delivered?

It’s also worth considering if feedback received is actually about BA capacity (being over loaded/ too stretched) rather than capability, and how that issue could be addressed.

Zone 3 – Other Professional Disciplines

This zone includes all the related and adjacent professional disciplines within the organisation, who the business analysts sometimes interact with. This includes business functions such as HR, finance, marketing, compliance, business teams and subject matter experts. Often they don’t form part of multi-disciplinary delivery teams, but BAs may often interact and engage with them. Its useful to understand the reputation of BAs amongst project managers, product owners and developers – even ones who don’t regularly interact with BAs. How likely would they be to spot the need for business analysis activities and seek out a BA?

Zone 4 – Pipeline Professionals

This is the potential talent pipeline into business analysis from elsewhere in the organization. Roles such as IT helpdesk, call center operatives and front line business teams. Do they know business analysis exists within the organization? Do they aspire to become BAs? Are there routes for them to follow? Do we provide opportunities to share our skills and knowledge to make business analysis visible, accessible and desirable? In a competitive recruitment market and for a competitive advantage, we cannot afford to ignore internal development routes into business analysis.

Zone 5 – Senior Leaders

This zone includes all senior leaders and decision makers. Not just whichever executive has reporting line responsibility for business analysis, but all influential leaders. The skillset of business analysts has a huge amount to offer those in leadership positions: BAs are objective critical thinkers, able to identify and define problems and investigate feasible solutions. Few zones of the organization need access to these skills more than the leadership team!

Do they know how business analysts offer value? Do they know how to get BAs involved? Are they factoring business analysis time and resources into their strategic plans and estimates? Do they genuinely want more evidence based decision making? If so, they need more business analysis!

It’s hard to get the time and attention of these leaders, but for us to help them (and the organization, to the best of our ability), they need to know we exist.

External Stakeholders

Any of these zone could also extend to cover external stakeholders, such as third party suppliers, partners, regulators, and external clients. While it may not be possible to engage in formal feedback processes due to organizational relationships, it is still possible to seek appropriate informal feedback to strengthen relationships, understand expectations and ultimately improve results.

Methods Of Obtaining Feedback

A variety of different approaches can be used, and this needs to take into account the culture of the organization and the expectations of different groups.

Consider a mix of:

Informal catch-ups over coffee
Email requests
Online surveys/ system
Formal recognition and review processes.

“We haven’t done it before” and “no one else does it” are not good reasons to avoid seeking feedback!

Conclusion

By thinking about these zones of stakeholders it is possible for the BA team to get a 360° picture of our performance, perception and reputation. If we don’t like the feedback, or don’t feel it reflects reality – then what action does that prompt? We can’t change opinions for the positive, if we are too scared to ask about current perceptions.

If BA teams can be brave and lead the way on establishing a 360 feedback culture, it will lead to better results and better relationships in the long run. It will also normalize the giving and receiving of feedback, which is a key contributor to high performing teams.

Agile Requirements Management: The Art of Collaboration

Written by Steve Farrall on March 30, 2023. Posted in Articles.

In this article I want to expand on how to manage requirements, particularly focused on delivering user stories to development teams ready for sprint refinement sessions. The starting line is a set of requirements that have already been formulated and issued, for example as part of a tendering process for a new service or upgrade to an existing service.

The Tool

We adopted the Confluence wiki collaboration tool as it is well integrated with the preferred Jira sprint management tool from the same supplier, Atlassian. The objective was to build a knowledge base for the product that is sharable and retains useful insights posted by stakeholders and the project team; this will facilitate future enhancements but also be invaluable in answering the inevitable question – “Why did we do that?”

The start point is to load each requirement as a separate Confluence page; this approach means that you can link to individual requirements using the page URL but also provides a ready-made folder to hold related content. This has an initial overhead in loading the requirement pages but provides lots of advantages downstream, so its well worth the effort; we managed to load in excess of 800 requirements for one contract.

You may be thinking why not use a table embedded in Confluence page to hold all the requirements but this is hard to manage and you cannot easily address each requirement.

Tip – Setup Subject Areas

Setup a subject area hierarchy in Confluence and file requirements appropriately, this will facilitate creating views of subsets of requirements using the ancestor filter option in the reporting macro.

Trace Requirements

Add at least one trace for each requirement, one for each feature impacted by the change or new feature that will need to be developed.

In parallel, features can be added to the wiki, again as separate pages – one per feature; it does not matter that the feature page has little content at this stage, the aim is to have a place holder that is ready to receive content and will allow everything to start to become joined up.

If the feature is already in place, then you can just plug in the link in the trace page and you are ready to move forward.

Tip – Identify Impacts

Each impact will need a separate trace, however traces can be grouped together for delivery as a single story. Trace pages are filed as child pages to the parent requirement, so everything is kept together.

Validate the Solution

Validate the proposed feature changes with the Product Owner and SME’s, this is achieved using workshops and reviewing the trace page content and adding clarifications to pages during the sessions, so everything is up to date and immediately available to the team.

The sort of points to consider are – does the Product Owner agree with the introduction of a new feature or a change to an existing feature, are there better options to consider such as buying a third part add-in; these kinds of questions need to be answered before moving into a more detailed analysis of the requirements.

Tip – Agree Solution

Stories to be written are agreed before they are actually written to reduce the risk of wasted effort.

At this stage a story title may be added as a reminder to the author of what needs to be covered, this will then be replaced with the URL to the story page once it has been created.

The Collaboration Solution

I’m guessing by now people will be wondering how on earth will all those requirement, feature and trace pages be manageable once they have been loaded into Confluence.

This is where you can use a feature of Confluence known as the Decision macro, at first glance it does not appear to offer much – the ability to create logs of decisions to manage, so each decision is a separate page but you get a consolidated view that pulls them together – a bit like a spreadsheet.

The next step is to realise that requirements, traces and features are really just decisions – a decision to request a feature in a product, to deliver a product feature using an agile user story etc. The nice thing about decision pages is that they can be customised, we devised templates for each type of decision – requirement, trace, feature etc. So now we have logs of all our requirements, traces and features but each can be managed separately as a Confluence wiki page.

Tip – Setup Filters

Logs can become quite large, so the solution we adopted was to use the requirement subject areas to create filtered views that only included traces for a particular branch.

Create User Stories

Write the user story content to fulfil the requirements including the detailed process flows and business rules.

As stories may relate to multiple requirements they are filed in a separate branch and not under a specific requirement, they are still linked back to the requirement via the trace pages.

Tip – Story Content

Add as little or as much content to ensure that the requirement will be met including process flows and business rules.

This is more effective than trying to develop business rules once sprints have started.

User stories may be grouped together where a lot of stories need to be managed.

Validate User Stories

Check the proposed changes with SME’s, are the business rules correct, you may include mock-ups of user interfaces to facilitate the process and give context to the proposed changes.

Tip – Workshops

Workshops can be used to present user stories prior to development to mitigate the risk of the wrong solution being delivered.

Conclusion

Finally, we created a Jira ticket for each story and link it to the Confluence story page; Confluence is a better tool for content than Jira but they are both only one click away from each other. Click on the Jira link in the story page and you are taken to the Jira ticket and similarly you can navigate back from Jira to the Confluence story.

In fact, you can navigate right back to the requirement(s) behind each story, all the links will be setup and ready to use with no additional effort.

Don’t forget to update your feature pages with the story releases – cut and paste job mainly; otherwise, you will need to read through all the stories for a given feature, in chronological sequence, just to find out what it is currently meant to be doing in production!

Does Your Personality Define Your Business Analyst Approach?

Written by Jake Thompson on March 29, 2023. Posted in Articles.

We all have personality; it is what comprises us as individuals and human beings to present ourselves in our personal and professional lives. Whether our personas experience duality separated by self-promoted boundaries, or the personalities of work and life are balanced as one big personality. But when you reach down into this core sense of self, a philosophical question came to mind when originating this piece: does our personalities define our business analyst approach? It is notwithstanding that I have little to no current, existing or previous knowledge in the realm of psychology, but it is worth chewing on the thought for a minute to examine it from a philosophical perspective. This core question begets more questions:

– If personality does affect the BA approach…then how?
– Is it the way we approach traditional standards or is it the manner of how we execute?
– How do we relate to our stakeholders to elicit requirements, validate them, overcome objections, and comprise the entire business analysis plan?

The unseen correlation between two independent variables became almost dependent immediately upon further self-analysis: personality does define our business analysis approach, right? Generally, speaking, I argue the point that it does. Genuinely think about how you interact with your stakeholders, how you go about performing your day-to-day, and even long-term, duties as a business analyst. Are those not influenced in which your persona, professional, personal, or combined, is presented when doing so?

For example, an extroverted personality with a deep mindfulness to detail would take the time to build the relationship with their stakeholders and those working on a project with them, but in significant detail to ensure nothing is missed. While this can be both beneficial and negative, this is an oversimplified example, of course and does not encapsulate every personality type; and yet it sufficiently illustrates the point made. Think of yourself and how you collaborate with stakeholders: what type of persona are you showing up as?

Applying that personality, however you summarize, influences the approach you have to business analysis. Do you go “by the book” and like to stick to the facts and in a Waterfall methodology? Or do you prefer to have projects take on fluidity and a more Agile perspective? It all boils down to personality…and you, as a business analyst, take the reins to own it. Neither personality nor approach is perfect but understanding this about us as professional individuals working with myriad backgrounds in our line of work, will only tap into our potential.

We may never know the extent of that potential, as there may not be enough time nor resources to perform the adequate studies over multiple fields related to understanding this eccentric analysis. But we can penultimately, begin to understand that in which we personify ourselves as human beings, personifies how we operates in the field of business analysis, and beyond.

The 6 Most Important Requirements Practices

Written by Karl Wiegers on March 22, 2023. Posted in Articles.

Authors sometimes make things longer and more complicated than necessary. Some readers might feel that I’ve been guilty of this myself. The third edition of my book Software Requirements, co-authored with Joy Beatty, is about 245,000 words long, nearly 640 pages in a rather small font. Maybe that seems like overkill, but to be fair, the requirements domain is large and complex.

Books like Software Requirements, Mastering the Requirements Process by Suzanne and James Robertson, and the IIBA’s Business Analysis Body of Knowledge describe dozens of valuable techniques for requirements elicitation, analysis, specification, validation, and management. They’re all useful when thoughtfully applied in appropriate situations. But if you don’t have time to wade through these large volumes, you might like this TL;DR version of the six most important requirements practices that every project team should perform. This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson.

Practice #1: Define Business Objectives

Organizations undertake a project to solve a problem, exploit a business opportunity, or create a new market. Defining the project’s business objectives communicates to all participants and other stakeholders why they are working on the project. The organization could hope to achieve both financial and non-financial business objectives with the new product. Try to quantify the business objectives, and make them measurable, with statements like these:

Capture a market share of X percent within Y months.
Reach a sales volume of X units or revenue of $Y within Z months.
Save X dollars per year currently spent on a high-maintenance legacy system.

Using business objectives aligns all of the team’s work and key decisions. Without defined business objectives, you can’t craft a clear product vision statement or establish the scope of either the entire project or any development increment. The team can’t make good decisions about scope changes or proposed functionality unless they know how those changes match up with the business objectives.

Keeping the scope in focus helps the team avoid scope creep while still adapting to changing business realities. And how can you know if the project was a success unless someone defined its business objectives and success criteria up front?

Practice #2: Understand What Users Need to Do with the Product

I strongly advocate taking a usage-centric approach to requirements development and solution design, rather than a feature- or product-centric approach. Understanding the tasks that users need to perform and the goals they want to achieve lets the business analyst (BA) derive the functionality that developers must implement.

When you focus on exploring features rather than user goals, it’s easy to overlook some necessary functionality. It’s also easy to include functionality that seems cool but doesn’t help users get their jobs done. Use cases are an effective technique for maintaining this usage-centric mindset.

Seeking to understand what users need to do with the product implies several other important BA activities, including these:

Identifying a wide range of project stakeholders
Characterizing distinct user classes that have largely different requirements
Identifying individuals to serve as the voice of the customer for each user class (product champions)
Selecting appropriate requirements elicitation techniques to engage with users
Establishing decision-making processes to resolve conflicts and priorities across user classes
Building and evaluating prototypes or early releases to stimulate user feedback

Practice #3: Prioritize the Requirements

I doubt that any project has ever implemented every bit of requested functionality. Even if you could implement it all, you can’t do it all at once. Your goal is to deliver the maximum business value to your customers at the lowest cost and in the shortest time. Achieving this goal demands that you prioritize requirements so the team can work on them in the most appropriate sequence.

Prioritization involves considering how much each proposed requirement contributes to achieving the project’s business objectives. Prioritizing requirements lets the team decide which of the work items remaining in the backlog to defer or omit because of time and resource constraints. There are numerous requirements prioritization techniques available, including these:

In or out
Pairwise comparison and rank ordering
Three-level scale
MoSCoW
Relative weighting
$100 test

Some of these methods take more effort than others, but those methods also help the project manager or product owner make finer-grained choices. Choose any technique that lets the right stakeholders make good business decisions throughout the project to avoid a frantic “rapid descoping phase” late in the game.

Practice #4: Explore Nonfunctional Requirements

People naturally focus on a product’s functionality when discussing requirements, but those are only part of the solution. Nonfunctional requirements contribute heavily to user satisfaction and suitability for use. When speaking of “nonfunctional requirements,” people most commonly think of quality attributes, sometimes called the “-ilities.” These product characteristics include usability, maintainability, security, reliability, and many others. To help designers devise the most appropriate solution, BAs need to discuss nonfunctional requirements as part of requirements elicitation.

Developers generally don’t directly implement requirements that describe safety, reliability, portability, security, or other characteristics. Instead, these attributes serve as the origin of many functional requirements and drive design decisions. Table 1 indicates the likely categories of technical information that different types of quality attributes will generate.

Table 1. Translating quality attributes into technical specifications (from Software Requirements, 3rd Edition)

Another challenge is that it’s not possible to optimize all of the desired quality factors at once. Designers must make trade-off decisions among the various attributes. Therefore, the team needs to determine which ones are most important to customer success and optimize those. Carefully specifying quality attributes lets you build a product that delights its users, beyond merely doing what it’s supposed to.

Practice #5: Review the Requirements

How do you know if your requirements are accurate? How can you tell if they’re clear enough so all the team members know what to do with them and other stakeholders know what to expect in the solution? No matter how you choose to represent requirements knowledge, it is sometimes ambiguous, incomplete, or simply incorrect.

One of the most powerful quality practices available is peer review of requirements. Convene some colleagues to review both textual requirements and diagrams. Different project participants—BAs, designers, developers, testers, users—will find different kinds of problems during these reviews. Requirements reviews pose some particular challenges. Rather than simply inviting people to look over the requirements, provide some training so reviewers know how to participate effectively and can find as many issues as possible.

A related requirements validation practice is to write conceptual tests based on requirements. Testing requirements is something you can do early in each development cycle to reveal many errors before they are cast into code. Requirements and tests are complementary views of the same knowledge. Requirements describe how the product should behave under certain conditions; tests describe how to tell if it’s exhibiting the correct behaviors.

Practice #6: Plan for Requirements Change

No matter how well you understand the problem and how carefully you prepare the requirements, they won’t be perfect, complete, or static. The world changes around us as we work. New users and new ideas appear. Business rules surface and evolve. Projects inevitably grow beyond their originally envisioned scope. Every team must anticipate requirements changes and establish mechanisms for dealing with them without derailing the team’s commitments.

When you know the project outcome is incompletely defined and likely to change a lot, an incremental, agile approach is a good way to cope with it. You plan to build the requirements—and the solution—in a series of small chunks, expecting the direction to change and accepting the uncertainty of what you’ll have at the end and when you’ll have it.

When the likely degree of change is less extreme, plan to accommodate some growth (along with risks, imprecise estimates, and unexpected events) by building contingency buffers into development schedules. Establish a requirements change process so the right people can get the right information to make good business decisions about which proposed changes to incorporate to add value with minimal disruption.

Don’t use the expectation of change as a justification for skimping on requirements thinking, though. Excessive requirements churn often indicates that objectives were unclear or the elicitation approach wasn’t effective.

Neglect These Practices at Your Peril

Of course, there are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.