Tag: Stakeholder

The Cost of Missing Stakeholders

Written by Jenny Quillian on July 19, 2023. Posted in Articles.

Business Case: Lessons from software implementation which put head office directives before stakeholder needs.

Background

This business lesson was learned at a US non-government organization (NGO) operating refugee camps and support services in East Africa. A few months prior to my arrival the NGO selected an accounting system to be implemented at all local offices. Instructions and software were sent out from the US head office, and my predecessor had been gamely trying to implement the new system but falling behind a little each month. We crossed paths in Nairobi as I was inbound to Mwanza, a dusty town on the shores of Lake Victoria. He was clearly stressed and anxious to be going home. What was I heading into?

NGO’s operate on private donor funding and from US government grants. Money was provided in US dollars and was spent in local shillings. Financial reports are provided in US dollars to the head office and for donor reporting, and in shillings for local authorities. Multi-currency accounting was not the cause of their current issue, but added complexity to the implementation.

The software was installed but a backlog of configuration work and data migration had been created and this was consuming the efforts of the finance office. Production of the donor reports were months behind and the NGO was at risk of losing or disrupting the funding to aid the thousands of refugees in their camps. Payments to local suppliers and workers were also in arrears as time had been consumed by the software change.

The new accounting system was rolled out by the head office to support a strategy for global standardization of accounting and reporting from their international offices. The implementation strategy could be called “out with the old and in with the new”. Use of the old system was abruptly ceased while the new software was installed, and production of the monthly donor reports would be resumed from the new system once the install and data migration was complete. There was no local planning for the initial rollout.

The approach of this paper is to use this business case to illustrate the benefits of applying business analysis tools and techniques to all software projects, regardless of size or location.

Planning– identify stakeholders and business analysis approach.

Always look for all the stakeholders. The NGO head office is a stakeholder in the Mwanza project, and they communicated a business need to achieve global accounting standardization. The funding donors are also stakeholders in the project. The rollout strategy was based on an assumption that the new accounting system was the number one priority for this local office – but donor funds are the life blood of non-profit organizations and any hint of not being able to account for how the money is being spent can cause delays or withdrawals of support. The number one business need for this Finance office was the timely and accurate production of donor reports.

Local workers and suppliers are also stakeholders in the accounting system. Timely reimbursement for labor and materials is needed to maintain the supply of both to run the refugee camps.

It is easy to overlook the need for business analysis in small projects, but this case illustrates the risk of implementing software without some basic analysis of scope and flows. A simple context diagram and stakeholder map would have provided a better perspective for implementation planning.

Requirements – identify all the functional and non-functional requirements.

The requirements given to the local office were:

Install new software
Migrate historical data
Recreate reports

Recognition of additional stakeholders leads to the additional requirements –

Maintain accurate and timely reporting to donors.
Avoid disruption to the delivery of monthly donor reports
Ensure consistency in donor reports
Maintain payments to local vendors and workers
Avoid delays of vendor and worker payments

Strategy – identify the business need, address that need, and align the change strategy within the enterprise.

The business need which dictated the implementation strategy was to achieve global accounting standardization. The missing business need was to maintain continuity of operations during the software change. A new strategy was required that gave equal priority to both needs.

Under the new strategy all work was stopped on the software configuration and data migration until the monthly reports and daily operations were up to date, then these were maintained in parallel during conversion and testing until a clean cutoff was possible. This was achieved within 3 months and there was no disruption to the NGO’s funding or local operations.

Techniques

Create a Context Diagram at the start of the business analysis process then share this early and often with your known stakeholders to help identify what might be missing.

Summary

Identification of all stakeholders is key to successful requirements. Timely identification of all the stakeholders at the start of the project avoids delays and rework when new requirements are identified while development or delivery is in progress.

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…