Tag: Development

Beyond Frameworks: Agile Insights from a BA’s Odyssey

Written by Afaq Qazi on April 18, 2024. Posted in Articles.

Reflecting on my journey from a Junior Business Analyst to a seasoned Business Analyst and eventually evolving into a role where Business Analysis and Product Management intersect, I’ve had the privilege to contribute to organizations as diverse as Boeing, Rolls-Royce, and EPAM, alongside navigating the unique challenges of smaller entities.

This path, spanning over 13 years and multiple domains, has equipped me with a deep understanding of Business Analysis from the grassroots, teaching me the crucial balance between adhering to frameworks and embracing the agility necessary for today’s dynamic business environment. This narrative is an exploration of that journey, emphasizing the transition from rigid methodologies to agile adaptability, and the critical importance of customer focus and stakeholder management.

In the early stages of my career, the allure of frameworks was undeniable. They presented a structured way of understanding Business Analysis and Product Management, offering a semblance of control and predictability in the chaotic realm of project management.

However, as I progressed, the limitations of these frameworks became increasingly apparent. The real-world application of Business Analysis goes beyond the confines of any framework. It demands an acute awareness of the shifting business landscape and the ability to think on one’s feet—a blend of deep analytical thinking and pragmatic street smarts.

This evolution in perspective was mirrored in my approach to project management. Initially, my focus was on mastering the technical aspects: understanding the ‘what’ and ‘why’ to navigate towards solutions and create value for users. Yet, I quickly learned that the essence of effective Business Analysis lies in the ability to communicate, adapt, and understand the broader business context—skills that are foundational yet flourish only with experience and deliberate practice.

Communication emerged as the cornerstone of my professional development. The capacity to engage with a diverse set of stakeholders—customers, engineers, designers, and executives—and synthesize their insights is paramount. It’s a skill that goes beyond mere articulation; it’s about understanding the audience, choosing the right words, and effectively conveying complex ideas in a manner that resonates.

This skill set has been instrumental in navigating the complexities of projects, ensuring alignment across teams, and driving towards common goals with clarity and purpose.

As I embraced the agile methodology, the importance of flexibility became glaringly evident. Agile is not just a buzzword; it’s a mindset that values adaptability, customer-centricity, and continuous improvement.

It challenged me to think differently about project management, to be more iterative in my approach, and to prioritize direct feedback loops with stakeholders and customers. This agility has been crucial in climbing the project ladder, allowing for rapid pivots and adjustments in response to new insights or changing market dynamics.

Customer focus and stakeholder management have been the bedrock of my growth as a Business Analyst. Recognizing the criticality of these aspects, I’ve dedicated myself to becoming adept at navigating the complex web of stakeholder relationships and ensuring that the voice of the customer is always at the forefront of decision-making. This has involved honing my ability to manage expectations, articulate value propositions clearly, and foster an environment of trust and collaboration.

In retrospect, the journey from adhering strictly to frameworks to adopting a more flexible, agile approach has been transformative. It has taught me that while frameworks provide valuable guidance, the essence of Business Analysis and Product Management lies in the ability to adapt, communicate effectively, and maintain a relentless focus on the customer and business objectives.

As I continue to navigate this ever-evolving landscape, these insights will remain central to my approach, guiding my decisions and actions in the pursuit of creating meaningful, impactful solutions.

What’s The Point of Peer Review?

Written by Christina Lovelock on February 15, 2024. Posted in Articles.

When time is tight and the pressure is on, it feels like ‘peer’ review is a luxury we cannot afford, but what’s the cost of this decision?

What Is Peer Review?

Sharing our analysis outputs (whether this is documents, models, presentation slides or feature tickets) with other business analysts before they are shared with any other stakeholders is the essence of peer review. BA peer reviewers should be able to share useful observations and insights about the output, whether or not they have specific business domain knowledge. If something is not clear to a fellow BA, there is a good chance it will not be understood by customers, suppliers, stakeholders and other recipients.

Why is Peer Review Valuable?

Many business analysts have a tendency towards perfectionism, and the longer we work on something without feedback, the more disappointing it is to receive any feedback, however constructive. It is much harder to accept and incorporate feedback on a polished final draft than an early rough draft. We need to share our work early in the process to be able to influence our own thinking and approach, and prevent us making significant errors or omissions.

Why is Peer Review Valuable?

Peer review is valuable from multiple perspectives.

#1 The producer

The person who created the output. We all bring assumptions to our work, whether this is a single piece of acceptance criteria, complex model or large document. The producer gets the benefits of a fresh perspective and the opportunity to catch errors and drive out assumptions. A peer review should be a way to improve quality without any worry of reputational or relationship risk. It also provides the opportunity for increased consistency across BA products and to learn lessons from other business areas.

#2 The peer reviewer

There is always something to gain from seeing how someone else works, whether they have more or less experience than us, and wherever they sit in the organisational hierarchy. So as well as making a valuable contribution to our colleague’s work we are likely to learn something through peer reviewing.

#3 Stakeholders

Any business, dev team or project stakeholders that will also be asked to review/validate/approve the deliverable will benefit greatly if a peer review has already taken place. Some errors and ambiguities will have been addressed, saving them time and increasing their confidence in the quality of the output.

The Review Triangle

This model reminds us that the highest number of errors should be spotted and rectified by the person creating the output, as part of a specific review phase.

Self-Review

The model emphasises the need for self-review, which is a separate activity to creating the analysis output, and involves:

Standards check (adherences to templates, branding and guidelines)
Assumptions check (provide key, glossary etc.)
Accessibility check (e.g. readability, compatibility with assistive tech, alt text for pictures)
Sense check
Error check
Spelling and grammar check.

Moving from a ‘creating’ to ‘reviewing’ mindset can be achieved by taking a break, and switching to reviewing when we return, or moving to a different device as this often forces us to look at something differently.

Peer Review

Peer review is also about adherence to standards, and is valuable even when the reviewer does not have relevant subject matter knowledge. They should be able to identify and challenge assumptions made, spot logic knots and highlight the use of acronyms and jargon. They can also share insights and observations from their own experience, such as level of detail and formats preferred by different internal audiences.

Stakeholder Review

Stakeholders should not be faced with errors that we could have easily caught through self or peer review. This does not mean we should only share perfect and complete outputs, but that we give stakeholders the best chance of spotting significant gaps and fundamental errors by removing low level distractions.

Many stakeholders find it difficult to simply ‘ignore’ spelling and other small errors. This level of error can undermine their confidence in our analysis.

Depending on the number of stakeholders and the complexity of the output, it is often better to do a group review exercise (synchronous) rather than a comments based (asynchronous) review. This is for several reasons:

Confidence everyone has actually seen what is being reviewed/validated/agreed
Prevents multiple stakeholders making the same (or conflicting) observations
Changes can be discussed and agreed.

Conclusion

The benefits of peer review, to individual BAs, the internal BA community and to our stakeholders and customers is significant. Attempting to ‘save time’ by avoiding this activity is a false economy. Organisations that aspire to be a truly ‘learning organisation’ encourage and enable effective peer reviews. Where organisations don’t place emphasis on this, BAs can choose to role model this commitment to quality and learning, and lead by example.

Further reading

Delivering Business Analysis: The BA Service Handbook, D Paul & C Lovelock, 2019

Top 10 Tips For Requirements Gathering

Written by Suchita Panchal on February 8, 2024. Posted in Articles.

When the requirements are NOT clear, a project will not be successful.

Where would you go If you don’t know where to go?

Building or presenting a solution demands knowing the requirements. When you know what the stakeholders require, you can deliver them the right results. Understanding requirements and passing them on to the team is a crucial task.

Successful requirement gathering is all takes to deliver the right solutions. This article presents the top tips for requirements gathering, a beacon for successful deliverables.

Let’s begin by understanding requirement gathering!

What is Requirement Gathering?

Requirement gathering is a process of discovering the specific requirements of a system through users, customers, stakeholders, and other team members. It is also referred to as requirement elicitation. Considering its two main types, business requirements are what an organization will accomplish with the project. On the contrary, technical requirements are how the project should be executed.

Requirements Gathering works as a roadmap while working on a project. It allows team members to focus on the deliverables; thus, developing or presenting the right solutions.

Here are the top 10 tips for successful requirements gathering:

#1. Engage Stakeholders: Involve all relevant stakeholders from the beginning. Identify and engage with key stakeholders who have a vested interest in the project’s success. Their input is critical for understanding needs and expectations.

#2. Define Clear Objectives: Clearly define and document the project’s objectives and goals. This helps in aligning everyone’s understanding and ensures that requirements are gathered to meet these objectives.

#3. Use Various Techniques: Utilize a variety of requirement-gathering techniques such as interviews, surveys, workshops, observations, and prototyping. Different methods can uncover different perspectives and insights.

#4. Ask Open-Ended Questions: Instead of closed-ended questions that elicit yes/no answers, ask open-ended questions to encourage stakeholders to provide detailed information and elaborate on their needs and expectations.

#5. Focus on User Needs: Prioritize user needs and understand the end-users’ perspectives. Their input is crucial in designing solutions that meet their requirements and improve user satisfaction.

#6. Up-to-date Documentation: Accurately document all gathered requirements. Use standardized templates or tools to ensure consistency and clarity in capturing and organizing requirements.

#7. Requirements Validation: Validate the requirements with stakeholders to ensure accuracy, completeness, and feasibility. Verify that the gathered requirements align with the project objectives.

#8. Consider Non-Functional Requirements: Don’t overlook non-functional requirements such as performance, security, scalability, and usability. These requirements are critical for the overall success of the solution.

#9. Effective Change Management: Understand that requirements might evolve throughout the project lifecycle. Implement a robust change management process to handle and document changes effectively.

#10. Transparent Communication: Maintain clear and open communication channels among stakeholders, ensuring everyone is updated on requirement changes, progress, and decisions. Clear communication mitigates misunderstandings and ensures alignment.

These tips can serve as a guide to help ensure a comprehensive and effective approach to gathering requirements, leading to successful project outcomes. Tailoring these approaches to suit the specific context and needs of your project is also essential for achieving the best results.

Crafting a Compelling Business Case: A Practical Guide for Business Analysts

Written by David Vrbanek on February 2, 2024. Posted in Articles.

Developing a business case is akin to telling a compelling story—one that captivates your audience and persuades them to invest time, resources, and support in your idea. As a Business Analyst, mastering the art of creating a persuasive business case prior to crunching the numbers and making the pitch is essential for driving successful projects within your organization. Here are eight major points that will help you navigate the intricate landscape of business case development (i.e. “make the case”).

Basics of Making a Business Case

Let’s kick things off with the foundational principles of constructing a business case. Regardless of the nature of your proposal or the industry you’re in, the process remains surprisingly consistent.

First and foremost, abandon the idea of diving into logical arguments or grappling with intricate numbers right away. Instead, envision yourself as a storyteller, beginning with the identification of a problem or opportunity. Ask yourself: What business need are you trying to address? Once you’ve pinpointed this, it’s time to introduce the characters in your story—stakeholders, beneficiaries, and subject-matter experts.

Stakeholders, often high-ranking decision-makers, hold the power to greenlight or reject your business case. Beneficiaries are those who stand to gain from your proposal, while subject-matter experts provide insights into problem-solving. Collaborate with these individuals to explore various alternatives, considering efficiency, cost-effectiveness, and alignment with your organization’s culture.

Having chosen the best option, create a high-level project plan to estimate the time and resources required. Finally, clearly articulate the value your solution brings, setting the stage for the subsequent number-crunching phase, including ROI, break-even points, payback periods, net present value, and internal rate of return.

Learn How Your Organization Evaluates Business Cases

Understanding how your organization reviews and approves projects is crucial for tailoring your business case effectively. Answer questions such as: Does your company have a formal evaluation process? Is it connected to other processes, and how detailed do stakeholders want the information?

Leverage the knowledge of a colleague familiar with the evaluation process. In large companies, formal templates and specific review times may exist, often tied to annual budgeting. Some organizations use a “tollgate” process, where approval is sought for project phases, allowing gradual commitment of resources.

Smaller organizations follow a similar pattern, albeit with less structure. Identify decision-makers’ authority levels, and if your organization lacks a defined process, seek insights from successful colleagues who navigated similar challenges.

Know Who’s Calling the Shots

Understanding who holds the fate of your project is paramount. Whether it’s an individual or a small committee, knowing your audience allows you to tailor your case to their priorities. Your boss might have insights into the decision-makers, whether it’s the CFO, division head, or a committee representing various organizational facets.

Identify the dominant department, as their goals often carry significant weight in decision-making. Find a champion within that department or committee who can advocate for your proposal. Remember, the goal isn’t just approval but informed decision-making, even if it means rejection.

Once you know the decision-makers, understand their priorities. Senior leaders look for projects aligning with the company’s strategy, emphasizing the importance of ensuring your case dovetails with broader objectives.

Understand the Audience’s Objectives

Aligning your business case with your company’s objectives is pivotal. Begin by identifying these objectives through sources like annual reports, CEO letters, and all-staff communications. Grasp the overarching themes—whether it’s growth, cost-cutting, global expansion, or regional focus.

Those evaluating your case are likely responsible for meeting these objectives. Clearly demonstrate how your proposal contributes directly to these goals. Understand the priorities, values, and decision-making styles of stakeholders by engaging with experts from various functions and consulting your boss.

Remember, stakeholders may not always agree on how to achieve company goals, emphasizing the need to involve experts from diverse functions when building your business case.

Clarify the Need

Before delving into team-building and solution brainstorming, the business need must be crystal clear. Referred to as the “pain point,” it’s the urgent problem or opportunity driving your proposal. It could be a sales force losing bids, service desk requests falling short, or an opportunity for substantial cost savings.

Document the pain point(s) thoroughly, noting the origin, impact, and the solution’s objectives. This documentation serves as the basis for your recommendations, making it easier to present a compelling case to stakeholders later on.

Whether you identify the need yourself or stakeholders present it to you, rigorous research is essential. Document everything, keeping notes on paper or digital files to refer back to when faced with conflicting or partial information.

Build a Cross-Functional Team

Developing a business case is not a solitary endeavor. Relying solely on your perspective risks overlooking crucial aspects. Instead, assemble a cross-functional team comprising individuals from various departments and perspectives.

While you may not have a dedicated team, bring together individuals at different points in the process. Include a finance representative to provide a big-picture view of costs and benefits. Engage beneficiaries to voice their concerns and ensure a holistic problem-solving approach. If the project impacts customers, involve customer-facing representatives like account managers or customer service representatives.

External experts can offer valuable insights, whether sourced from your network, online communities, or vendors. The key is to form a tight team of experts focused on the specific case, respecting the organizational chain of command and securing support from reporting managers.

Consider Alternatives

The brainstorming phase is where your cross-functional team shines. Encourage the exploration of potential solutions, using problem statements as a starting point. Look beyond individual departments, considering how other organizations or departments might have addressed similar needs.

Emphasize that these sessions are working sessions—opportunities to generate options without delving into detailed project plans or specific vendors. Facilitate creative thinking while reminding the team of limitations and constraints. The goal is to consider all viable options before narrowing down to 2-3 choices.

Thought-provoking questions guide this process. Which option costs the least? Is it the fastest to implement? Does it have the fewest risks or bring in the most revenue? Present each option with at least one significant advantage and be ready to share rejected options and the reasons behind their dismissal.

Think Through the High-Level “How”

Paint a vivid picture of how your proposed solution will be implemented within the organization. While not a detailed project plan, this outline provides a realistic basis for estimating costs and benefits. Consider what tasks need to be done before, during, and after the project switch.

Engage subject matter experts and stakeholders in this process. Anticipate potential roadblocks and resource requirements, securing buy-in from involved departments. Validate your proposed solution with your cross-functional team, ensuring feasibility and uncovering any hidden costs or constraints.

This high-level planning stage helps you identify whose support you’ll need and ensures that all costs, including one-time expenses, are accounted for. It sets the stage for detailed financial calculations and further strengthens your business case.

Here’s to crafting a compelling case that resonates with stakeholders!

Back To Basics: Excellent Elicitation

Written by Adrian Reed on May 11, 2023. Posted in Articles.

Elicitation is a core business analysis skill, and one that BAs typically utilize daily. It is easy to fall into the trap of thinking that elicitation is so basic that it doesn’t warrant talking about. Yet, just because it is a core skill doesn’t mean it’s easy, and it certainly doesn’t mean it’s unimportant. Not only this, but elicitation usually involves working with stakeholders, and whenever people are involved there can be inadvertent conflict and contradiction. Achieving clarity is rarely easy! In this article, I’ll address three perspectives of elicitation that you might find useful.

Elicitation As A “Trawling” Activity

In their book Mastering the Requirements Process, James and Suzanne Robertson use the metaphor of trawling to describe elicitation. The idea is, much like a fishing boat with a net trawls for fish, an analyst ‘trawls’ a business area for relevant pieces of information.

Ever since I first heard this metaphor I’ve liked it. Building on the Robertsons’ work and extending the metaphor, we might also say:

Where you trawl matters: If you trawl in an area with no fish, you’ll end up with an empty net. The same is true of requirements—ask the ‘wrong’ people and you’ll get very little.
The type of net matters: I’d imagine that the type and size of fish you are trying to catch will affect the type of net used. There’s a comparison here with elicitation—the techniques need to vary depending on the context and the types of requirements that you’re looking for. Detailed observation might yield very in-depth requirements, so might be considered a ‘small net’. A high-level conversation with an executive might yield high level outcomes and be considered a ‘big net’. Both are important, but it’s important to know which you are looking for.
There will always be stuff to throw back: Sometimes, it’s tempting to plan elicitation activity in a straightforward, linear way. As if you’ll be able to speak to person A, person B, do some observation and then everything is done. Of course, it never works exactly like that, as people will throw in curve-balls, there’ll be discussions which take you in unknown directions and so forth. I suppose this is a bit like trawling for fish: there will always be some fish to throw back if they are too small, too big, or the wrong type. In requirements terms, this shows that elicitation and analysis go hand in hand. As soon as elicitation starts, there will be filtering and prioritization happening.
Ethics should be built in to the process: I gather that fishing boats may throw back fish that are endangered, or are below a certain size. In terms of requirements, there is perhaps a lesson for us as analysts: If we come across a requirement that we believe is unethical, we should question it. This might sound like an odd thing to say, after all, who would raise an unethical requirement? Yet, with proposed technological transformation there might be an underrepresented group that is disproportionately affected, and perhaps this hadn’t been considered. It might be that the requirement owner had never considered the ethical consequences, and is very happy to amend or remove it once they think about the broader unintended consequences.

Elicitation Relies On Stakeholder Analysis

Much as elicitation and analysis are inextricably connected, there is a clear dependency on stakeholder analysis. Sometimes we might be led to believe that stakeholder analysis is a frivolous activity, after all, who has time to sit down and create stakeholder lists and models? Yet, the reality is that it’s one of those activities that will likely save time in the future.

I can still vividly remember a time, very early in my business analysis career, when I was assured that a particular project I was working on didn’t require compliance sign-off. I took this at face value, didn’t do any further stakeholder analysis and went ahead. Cutting a long story short, we got to testing and found that we absolutely did need compliance sign off. That was a scary revelation, but luckily our compliance colleagues were friendly and pragmatic. With some late nights and minor changes we got the project over the line. But for me, it was a lesson learned: Proper stakeholder analysis could have avoided it entirely.

I’m a particular fan of the stakeholder rainbow, and the stakeholder interest intensity index. I discussed a number of stakeholder techniques in a presentation that’s available on YouTube, feel free to check that out if you’d like to know more!

Context And Scope Matter

Finally, it’s worth noting that elicitation which doesn’t consider context and scope is really just a Santa’s wishlist. Imagine asking everyone in an organization “what is it you want?” or “what could save you time?”. You’ll get lots of ideas, many of them actionable, but you won’t get a coherent set of ideas.

This probably sounds so obvious, but it’s an easy trap to fall into. As analysts, it’s easy to be so familiar with the scope and context of a project that we assume everyone knows it. Yet that’s rarely the case, so spending a few moments to outline the core objectives and outcomes can really help.

This also highlights another key point: It’s absolutely crucial to understand the business objectives and outcomes being sought. Trying to elicit and prioritize without knowing the outcomes is virtually impossible. How can anyone say requirement A is in scope (or not), and whether it’s more important than requirement B if there’s no clear agreement over the ultimate outcomes being sought?

Conclusion: Shine The Light On Elicitation

It’s easy, particularly as an experienced practitioner, to let elicitation become second nature. That is completely natural. But perhaps it is worth spending time now and again reflecting on how we elicit and whether it is still effective. Although it might not be a headline-grabbing topic, elicitation is absolutely crucial to what we all do!