Tag: Stakeholder

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.

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.

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.

What Do Business Analysts and Rockstars Have in Common?

Written by Jamie Toyne on February 15, 2023. Posted in Articles.

Well, quite a lot actually. I’m not saying we’ve all got the swagger of Liam Gallagher, or the Ziggy Stardust fashion sense of Bowie. Nor, do we all play guitars, or know our way around a recording studio (although some do). And I’d confidently say, none of us are going around with diva-like demands or are smashing up hotel rooms. Most likely we’ll be littering the walls with post-its, hand-written using Sharpies.

But there are many aspects of being a Rockstar, that BAs do share in common. So much so, at Herd Consulting — we refer to ourselves as a Rockstar business analysis consultancy.

Here’s our top 5 reasons to convince you that good business analysis, really is rock ’n’ roll.

You wouldn’t see a Rockstar, ditching their genre. They love what they do. And that’s no different for most BAs. Sure, we could easily go on and become the next CEO of a major global firm, as many do. But they’re still using their inner BA and BA mindset day in, day out. Organizations, and the world around us is constantly evolving in its complexity. That means lots more challenges, and lots more opportunities. With our change know how, curiosity, and BA toolkit — we’re often best placed to take on the role of lead singer in any delivery team, as well as providing the backing rhythm when needed.

Now I’m not suggesting we should charge £100 a ticket to come along to one of our gigs (also sometimes known as workshops, show and tells, or presentations). But the most impactful BAs know who their audience is and engages with them. Equally as importantly, they keep them engaged. Maybe even some of their stakeholders and users, end up becoming fans too.

There’s no point recording the best songs if no-one is ever going to hear it. Similarly, business analysis shouldn’t be confined to just artefacts. It needs to be brought alive, it needs to be seen and heard. Without it, how will it ever challenge thinking, solve a problem, or guide and enable decisions to be made. Business analysts at the top of their game, make an event out of sharing their analysis, they make it easy and memorable to engage with. They provide recommendations or calls to action. Dare I say, it might even be the beginnings of a catchy hit.

Lyrics are a subjective topic, so we’ll steer away from the taxonomy of what good lyrics are, other than to say — the best usually tell a story. As professional business analysts, we’re always telling a story albeit likely with more precision and clarity than a song does. We’re discovering and writing a story (not necessarily just user stories), to guide delivery teams on what it is we’re doing and why we’re doing it. To have a clear specification of what’s required, and what’s not. Ultimately to ensure we’re all thinking about the same thing and are heading to the same destination.

Vinyl, cassettes, CDs, MP3s, streaming services. The world of music is constantly evolving. Remember music video channels? Rockstar’s are always having to keep up with the world of technology, and the changing commercial landscape around them. Business analysis is no different. Given most of us work in Digital or Change environments, we’re often at the forefront of progression and new thinking, whether that be Tech led or not. Therefore, to survive and thrive, we’re having to regularly invest in our knowledge and skills, broadening our experience, and expanding our networks.

Part 2 coming soon…

Encouraging Collaboration and Resolving Conflicts with Mockups

Written by Paul Burgdorf on November 2, 2022. Posted in Articles.

All business analysts have (or will) attend the same meeting with stakeholders so disagreeable that if you put an orange between them, they would immediately disagree on its color. If these stakeholders cannot bridge their disagreement, a great approach is to collaborate with the stakeholders to create lo-fi visual mockups.

When done correctly, BAs can use mockups to engage stakeholders in a collaborative learning exercise that includes the following elements:

Visual elements to depict subjects such as roles, actions, and relationships.
Auditory elements when discussing these topics.
Reading and writing elements when documenting discoveries and agreements.
Kinesthetic elements when modifying the placement and relationships of visual elements.

These are the styles identified in the VARK model of learning. Using this multi-sensory approach in a collaborative learning exercise can be bring together stakeholders, even if they have different learning styles.

Mockups can depict anything related to the business change – software screens, tables and fields in a database, or process flow diagrams. By collaboratively creating these items, BAs can engage stakeholders in a shared journey of discovery. During this journey, BAs can introduce new data points and information to gently transition stakeholders from entrenched “I-know-best” positions to the more neutral territory of shared learning. This additional territory can yield discoveries in terms of requirements and solution approaches. And sometimes, it can identify previously unknown common ground for adversarial stakeholders.

I participated in a real-world example of using mockups in this manner. During an elicitation session, two stakeholders adopted opposing views that involved a simple workflow. Each stakeholder had something of a point – stakeholder #1 argued that the solution should require completing a specific task before continuing; stakeholder #2 argued that finalizing that task later allowed for more flexibility.

I had mockups depicting a workflow for a related and similar process. These mockups were simple slides with screenshots and text boxes calling out the user workflow. I quickly made copies of those mockups to depict each stakeholder’s approach. Each stakeholder was able to instruct me on tweaking their mockup as needed; then, using the mockup as a visual aid, the stakeholder could articulate their approach more effectively. By comparing them side-by-side, it was easier for both stakeholders to see the validity and shortcomings of each. During our discussions, a third approach emerged, which we were quickly able to mockup. The stakeholders negotiated from their combined shared learning experience and agreed that this third approach would satisfy their requirements.

This real-world example of resolving stakeholder conflict with mockups reinforces the importance of the visual:

Stakeholders could more easily understand the relationship between their disparate requirements when mocked up.
Stakeholders could better appreciate alternative user workflows as the mockups clarified it.
Stakeholders could envision and agree upon a compromise solution when mocked up.

The mockups clarified the merits and obstacles of each approach and made the third (compromise) choice obvious. Even if the stakeholders had not agreed on the compromise solution, the depictions provided by the interim mockups would have clarified their point of disagreement and made their conflicting priorities clear.

Even in requirements, a picture is worth a thousand words.