Skip to main content

Tag: Development

What’s The Point of Peer Review?

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.

 

 

Advertisement

 

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

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.

 

Advertisement

 

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

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.

 

Advertisement

 

  • 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

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.

 

Advertisement

 

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!

Best of BATimes: A Checklist For Business Analysis Planning

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

 

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks.  Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work.

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in.  They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

  • The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
  • The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
  • The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
  • The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables.
  • The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on.  Answer questions in the following checklist for yourself.

Project Life Cycle

  • What are the planned stages of this project?
  • What stage are we currently in?
  • What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
  • What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule And Effort Budget

  • How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
  • Is that about what I also estimate it will take?
  • Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders And Relationships

    • What are the key roles is on the project team and who is in them?
      • Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
      • What are the names and titles the persons in these project roles?
    • Are significantly new relationships being are created in this project?
      • Who’s new to each other on this team?
      • Are there local and who’s remote team members?
    • What are peoples’ responsibilities?
      • Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?

 

Advertisement

 

Elicitation Techniques

  • Which elicitation techniques are available to me use?
    • Documentation Reviews – What documentation or prior work products are available to review?
    • Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
    • Observations – Where and what kinds of observations may be needed and how could I arrange for them?
    • System reviews – What system(s) are available to review and for what information?
    • Surveys – Who could I engage in a survey and using what types of questions?
  • What are my own business analysis competencies?
    • Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

  • What specialized tools for elicitation, documentation and modeling are available to me?
    • Collaboration tools, facilities, survey tools?
    • Diagramming or modeling software?
  • What prior business analysis work (e.g., documents, models) that I can draw from?
  • Does my organization offer training in the subject business domain?

Competencies And Knowledge

  • Who on the project team has what expert business domain knowledge?
  • What is my own business domain knowledge?
  • What are my strongest core business analysis competencies?
  • Where can you take advantage the team’s diversity of knowledge and competencies?
  • Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?

Conclusion:

Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned.

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

  1. It will help you to align your own core business analysis competencies to each project, and
  2. You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.

You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.