Tag: Skills

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

Written by Angela Wick on April 27, 2023. Posted in Articles.

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

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:

I ask the SME/s to describe the process for me.
Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
As they explain the process I ask, “What parts of the process would you improve and why?”
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.

Read All About It – Why Reading is a Critical Skill in BA

Written by Jake Thompson on April 20, 2023. Posted in Articles.

I love reading.

It is to the point of compulsion where I log into my Amazon.com account and sneak in a couple titles
of varying degrees, regardless of what my original intention was. I always mutter a friendly curse
towards the algorithms that market new, old, debut and longstanding authors of novels, novella, and
fantastical stories each time I log in. It is not just limited to online…oh, no, not at all. Traveling, locally,
domestic, or internationally? Same problem. I make it a significant point to dop into any local
bookstore with self-guaranty that I will walk out with, at minimum, one book, genre notwithstanding.

Reading, however, has become so much more than just “getting lost in the story” or falling in love with
characters whom we can only dream to meet, mirror ourselves against or become attached to. It is not
a hobby, it is not just a compulsion, it is not habit. It is something else, something more: a skill. A
critical skill, at that. A skill that, like anything, any one can become proficient, an expert on, but
requires the same thing: practice, practice, practice. While I could spend the time writing this piece on
the top ten books a business analyst should read (and was the original idea for this article) …instead, I
make a proclamation. A quasi-Magna Carta, if you would: all business analysts must take the time in
their schedules to make room for improving this critical and formidable skill.

Today, there are rumors of studies finding that young adults after their high school (post-secondary)
education will never read a book again. It is flabbergasting on one hand, but to lose a critical skill like
reading that is sharpened when you open the cover-to-cover bound print matter (or e-book for you
digital readers), it is breathtaking. We, as business analysts, whether we realize it or not, are
consistently reading. Reading our e-mails, reading our business analyst documentation, reading
requirements. You are reading right now, are you not? That is pending that you continue to read my
piece on this subject matter. We are, in and out of varying intervals and degrees, reading! Some read
faster than others, some take the time to deeply understand and analyze what is on the paper, or page
before us. Aside from this, you are inherently practicing a critical skill in which will only make you
better, as a business analyst.

Google search any reason as to why human beings should read and the results are countless: whether
it be for stress relief, for better memory retention, to prevent disease, it is all relevant. However,
relevancy aside, it becomes relevant to our work. Reading requires us to think, to analyze, to ask
ourselves questions. Is that not what we do now? Think, analyze, ask questions? Of course, overlooking
that I am oversimplifying the business analysis method, reading leads us to business analyzing!

Reading only stands to benefit you to improve in these areas; reading helps establish connections, to
understand concepts. Who does not like conversing in the language of titles, authors and favorite quotes
from that series or book that came out last week, month, year? There once was a video game I played
as a young adult and in the conversation of movies, they spoke about how movies during their time
(when movies/cinema were in their Golden Age), help people out of a bind or jam that they do not
understand. Take out movies/cinema and replace with books/reading, and there you got it.

So, read all about it! And I do not mean that slogan about the latest newspaper (although a reliable
source for information), I truly mean…read all about it. Being able to become a fount of knowledge
and to be able to translate that knowledge into performance as a BA should be your guiding light. As
a business analyst: think about it, analyze it, ask questions about it. Understand it…you will thank
yourself someday

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.

Delivering Analysis: Working With the System

Written by Anna Rajander on March 9, 2023. Posted in Articles.

Business analysis is an evolving profession characterized by change. However, not all businesses embrace evolution and change in the same way. This can result in business and delivery practices constraining the use of newer, more agile approaches to business analysis. This article presents some ideas and techniques to help business analysts identify, understand, and work with constraining business practices.

The Challenge

You may have heard the serenity prayer. It goes something like this:

God, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and wisdom to know the difference.

The origins of the serenity prayer date back to the 1930s and 1940’s. It is one of the most well-known and quoted prayers in the Christian world, with versions adorning posters, fridge magnets and trinkets across the globe. And while the prayer predates the business analysis profession by decades, the sentiment of the prayer is relevant for many analysts – even those of us who aren’t religious.

Business analysis is a profession of change. Indeed, the IIBA defines business analysis as the “practice of enabling change” in an enterprise. Whether it be learning a new technique or method, or applying skills to a new business domain, business analysts are encouraged to constantly experiment, learn and adapt. We are often looking for opportunities to apply new skills or techniques, or engage with enterprises that are using newer, more agile delivery methods. This constant exposure to change can make business analysts very comfortable with change.

It can therefore be frustrating when we find ourselves in environments where prevailing business practices prevent us from delivering analysis in the way we would like. Outdated systems, over-zealous governance, rigid templates and document heavy processes can constrain our ability to used more modern, agile delivery methods and techniques. And inflicting change on stakeholders using outdated delivery practices can seem like a double standard! Yet, working against such practices and processes can cause even more problems, resulting in business resistance, conflicts with stakeholders, delays, and even failure to deliver.

Identifying Constraining Business Practices

Business analysts need to fully understand the business context in which they are delivering change. This includes understanding the business and delivery practices being used to define, design and implement change, and how they impact business analysis. Early identification of constraining business and delivery practices gives business analysts an opportunity to find ways of working with them – rather than against them.

There are several common business analysis techniques that can be used to help identify and understand restrictive business and delivery practices. For example:

SWOT Analysis – A SWOT analysis can be used to help identify business practices that may impede or constrain business analysis activities (in other words, are a threat to the delivery of good analysis), identify opportunities to improve business practices, and identifying any strengths/weaknesses that may help/hinder delivery given the constraints.
Process Analysis and Modelling – Understanding when and how analysis activities will engage with constraining business practices can support the creation of efficient business analysis plans that meets all delivery requirements.
Stakeholder Analysis – Remember the saying It’s who you know – not what you know? This is too often true – particularly when it comes to governance and approvals processes. Understanding who the influential stakeholders are and engaging them early can often alleviate and even remove constraints.
Root Cause Analysis – There is usually a reason why things are done the way they are, although it may not always be obvious. Uncovering that underlying reason for a given business practice can help analysts a) identify areas for improvement, or b) accept it for what it is.

Conclusion

Understanding business and delivery practices that constrain business analysis can help analysts:

Identify and champion opportunities for business improvement
Identify ways of working with or within existing business practices that may better support analysis, or
Accept and work with prevailing business practices as efficiently as possible.

To paraphrase the serenity prayer – accept the things you cannot change, change the things you can, and understand the difference!

Anna Rajander, Dec 2022

Resources:

Serenity Prayer – Wikipedia, accessed Dec 2022.
A Guide to the Business Analysis Book of Knowledge (BaBOK) v3, IIBA, 2015.

Business Analysis Amalgamation with Product Management

Written by Neethu Nair on March 2, 2023. Posted in Articles.

In today’s fast-paced business environment, organizations constantly seek ways to improve their processes, products, and services. Business Analysis and Product Management are two key areas essential to achieving these goals. Traditionally, these functions have been viewed as separate disciplines, with Business Analysts focusing on identifying and analyzing business requirements, while Product Managers focus on the development and management of products and services.

However, there has been a growing trend towards amalgamating these two functions to create a more integrated approach in recent years. By combining Business Analysis with Product Management, companies can benefit from a more holistic understanding of customer needs, more effective use of data, and improved collaboration and communication between teams.

An Overview of Business Analysis and Product Management:

Business Analysis is the process of identifying, analyzing, and documenting business requirements, processes, and workflows. The role of a Business Analyst is to help organizations improve their processes and systems by identifying areas of improvement, gathering and analyzing data, and making recommendations for change. Business Analysts often work closely with stakeholders and other teams within an organization, including IT and project management.

Product Management, on the other hand, is focused on developing and managing products or services. The role of a Product Manager is to identify market opportunities, define product requirements, and work with cross-functional teams to bring products to market. Product Managers must have a deep understanding of customer needs and market trends and/ or the ability to manage budgets, timelines, and resources.

Benefits of Amalgamating Business Analysis and Product Management:

While Business Analysis and Product Management are distinct roles, there are many benefits to amalgamating the two functions. Here are a few of the key advantages.

Better understanding of customer needs:

One of the key benefits of amalgamating Business Analysis and Product Management is the ability to better understand customer needs. By working together, these two functions can create a more complete picture of customer requirements, preferences, and pain points. This can lead to better product design, more effective marketing, and higher customer satisfaction.

Alignment towards Business Goals:

Amalgamating Business Analysis and Product Management also improve team collaboration and communication. These two functions can ensure that everyone is aligned on business goals, product requirements, and timelines. This can lead to better project outcomes and faster time to market.

More practical use of data:

Another benefit of combining Business Analysis and Product Management is effectively using data. Business Analysts are skilled at collecting, analyzing, and interpreting data, while Product Managers deeply understand market trends and customer needs. These two functions can leverage data to improve product design, pricing, and marketing decisions by working together.

Faster problem-solving:

Amalgamating Business Analysis and Product Management also lead to faster problem-solving. By having a team of experts who can analyze data, identify issues, and recommend solutions, organizations can respond more quickly to changing market conditions or customer needs. This can help companies stay ahead of the competition and achieve their business objectives more effectively.

Better outcomes over outputs:

Finally, combining Business Analysis and Product Management can improve project outcomes. By working together, these two functions can ensure that products are designed to meet customer needs and that projects are delivered on time and within budget. This can lead to improved customer satisfaction, increased revenue, and a stronger competitive position in the market.

The amalgamation of Business Analysis and Product Management can benefit organizations looking to stay ahead in today’s competitive business landscape. By combining these two functions, companies can improve collaboration and communication, better understand customer needs, use data more effectively, and achieve better project outcomes. Whether a small start-up or a large enterprise, an integrated approach to Business Analysis and Product Management can help you achieve your business objectives more effectively.